READ dec(a$)
Das geht leider nicht, weil READ keine Funktion ist.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
READ dec(a$)
Das geht leider nicht, weil READ keine Funktion ist.
Das Nachladen müsste nicht besonders schnell gehen, weil immer die nächste Tafel während des Vortrags vorgeladen werden kann.
Aber Sachen wie Jiffydos oder Ultraload sind - glaube ich - doch recht hilfreich. Schon alleine, weil man evtl. etwas Zeitpuffer haben kann. Oder MF2.0, lädt unschlagbar schnell ohne Hardwareeingriff und mit eingeschaltetem Bildschirm.
Freuen unss drauf. Wie gesagt, auch nicht FL er hier können sich mal zum testen
anmelden.
Ich freu mich darauf für Euch, für mich nur leider ein paar Meter zu weit weg
..und hier kommt die neueste Cartridge von Matthias:
Entweder bin ich blind oder es steht nicht dabei... ist das wieder nur auf das 469er zugeschnitten?
Aber alles noch besser als seine wenige Jahre alten Visual-Studio-Projekte nicht mehr öffnen zu können, weil die "kostenlose" Lizenz abgelaufen ist
Kann ich so nicht bestätigen.... ich kann auch heute noch meine Projekte aus VS2005 öffnen.
Ich mag halt die recht einfache Lesbarkeit von VB. Mit Java habe ich auch schon mal Zeug gemacht, aber da ich beruflich hauptsächlich Datenbank-Zeugs programmiere, bevorzuge ich .Net (C# ist für mich genauso schrecklich lesbar wie Java übrigens), denn schon alleine die Parameter sind um Längen komfortabler als mit Java. Wobei sich da inzwischen ja so Einges getan haben kann, das ist ja auch schon ein paar Jahre her.
Und nachdem ich ja vom 6502 Assembler komme, sind für mich die meisten Sprachen einfach nur schrecklich zu lesen, so nebenbei
Wenn Du Java magst, schau Dir mal TornadoVM an.
Ich glaube, oobdoo hat die gleiche Leidenschaft wie ich, und die nennt sich VB.Net.
Wobei ich mich immer frage, was schneller ist... Java oder ein Z80
Ob OpenCL oder CUDA ist mir im Grunde egal, wenn ich denn nur gute Beispiele finden würde wie ich das nutzbar machen könnte.
Also wenn Du da was Ordentliches findest, das interessiert mich auch. Ich wollte mich schon lange mal mit der GPGPU beschäftigen.
Dann ist das hier das richtige für dich:
Hey, das ist ja korrekt Danke! Und auch noch die Mixed-Galaga-Version
Das ist völlig in Ordnung so, da es a) weder für Leute gedacht ist, die dieses Spiel nicht auf echter Hardware spielen und/oder b) keine Zeit haben.
Das ist ja das Problem... wenn ich im WinVice schon wahnsinnig werde, bis es los geht, habe ich schon keine Lust mehr zu spielen. Kann man bei den 29 Vorspännen nicht was einsparen?
Das Spiel läuft auf Vice und wie CapFuture1975 sagt, ein Transwarp File
Bei Dir läufts? Na gut, dann wird bei mir wohl das Problem sein, dass ich es nicht mit Org-Rom gestartet habe.
Oha, ja klar:
Schade, dass das so ein typisches Ding ist, was man nur 1x startet, weil es ewig dauert, bis man endlich mal los legen kann :-/ (Und das File, was zuerst in dem Image ist, crasht im WinVice)
Davon lese ich zum ersten mal etwas.
Die TaskFactory ist gar nicht so übel, nur komischerweise wenig bekannt. Ist auf jeden Fall auch wert, sich mal (kurz) mit zu beschäftigen. Damit kann man auch schöne Nebenläufigkeiten machen.
Ich vermute Du meinst damit Zwischenergebnisse? Da bin ich gerade dran am basteln, damit ich die Berechnungszeit verkürzen kann.
Nein, race condition = zur Laufzeit. Da gibt es zum Teil minimalste Fehler, an die man erst mal gar nicht denkt. Ich hatte da auch mal ein Problem, das ich parallel lösen wollte (und dann auch gelöst habe). Da hatte ich das Problem, dass ich in der Theorie aus einer Queue Zeugs wieder entnommen habe (.Dequeue). Im Single Thread lief das geil, aber lahm (weil rechenintensiv). Also: her mit allen Kernen, die die Kiste hat Nur hatte ich nicht bedacht, dass die Queue nicht threadsicher ist (das Pendant ist ConcurrentQueue). Also kam es zur race condition zu Doppelberechnungen, deren Grund ich mir erst mal nicht erklären konnte. War das verständlich erklärt? Damit hab ich nämlich gerne mal meine lieben Probleme...
Ich bleibe erstmal bei meinen Prozessen. Das ist zwar ein Rumexperimentierprojekt, aber noch mehr Zeit ins Threading wollte ich nicht reinstecken.
Experimentieren ist immer gut Das war bei mir auch die einzige Methode, wie ich für mich damals die beste Lösung gefunden hatte. BTW, die TaskFactory ist auch nicht zu verachten. Aber kann man letztlich auch mit Threading vergleichen - rein vom Erstellen her.
...und dann hat man was gefunden, dann funken die race conditions dazwischen und es geht doch nicht Hach ja, ich hab damals geflucht wie blöde, aber das Experimentieren mit allen möglichen Arten von Multithreading war, im Nachhinein betrachtet, eigentlich schon ganz lustig. Schade, dass ich eher selten zeitkritische Dinge code, die davon profitieren.
oobdoo Ich hab einfach mal bissl bei Euch mitgelesen. Ich lass einfach mal meinen Senf dazu da.
Backgroundworker ist nicht schlecht, bei 16 Freds allerdings schwer handelbar.
Von parallel.for halte ich inzwischen gar nicht mehr so viel, das nutzt nur was, wenn die Freds etwas rechnen und voraussichtlich relativ gleich fertig werden. Damit sind wir in der Tat schon wieder möglicherweise bei der GPGPU...
Was ich noch ins Feld bringen möchte (weil ich nicht weiß, wie Du es umgesetzt hast), denn ich hatte das mal so gelöst: eine List(of Thread) machen, die 16 Threads starten und ab in die Liste. Und dann regelmäßig prüfen, ob alle fertig sind.
hier könnte was bestellt werden
Was? Wo? Wie? Ein Bestellbutton? Leider unsichtbar
Mach doch eine Umfrage draus? Aber bitte Choplifter als Antwortmöglichkeit nicht vergessen...
Wenn man Platz und Zeit zu verschenken hat - warum nicht?
Wenn man ganz sicher aussschließen kann, dass das Carry gesetzt wird, kann man es ja mal versuchen. Ein
INX
BNE
setzt aber das Carry, wenn x=0 wird. Im Zweifel wird halt 2 statt 1 addiert...
Das CLC muss man übrigens nur ganz zu Beginn machen.
Sollte man vor dem ADC eigentlich immer machen.
Wie erhöhe ich den Accumulator ?
Im Gegensatz zu X (INX) oder Y (INY) musst Du das ein bischen anders machen:
CLC
ADC #1
Da wollte sich einer über Simons' Basic lustig machen ("Absturz sicher")
Das ist doch ok Über GoDotBasic machen die sich ja schließlich nicht lustig