Archiv der Kategorie: AxperimentelleArcheologie

Copy&Paste in Assembler – no go

Was in heutigen Programmiersprachen gang und gäbe ist, die Technik Dinge von X nach Y zu kopieren und dort anzupassen, ist in Assembler nicht so einfach möglich. Der Grund: In heutigen Programmiersprachen gibt es keine Sprungmarken mehr, diese müssen aber mühsam angepasst werden Assembler. Es darf ja (ausser bei modernen relativ adressierbaren Assembler) keine zwei gleichlautende Sprungmarken geben. Anders gesagt: Copy&Paste ja, aber zu einem Preis: Generierung von vielen neuen Labels und damit auch jede Menge möglicher Fehler und viel Neu-Testing.

Und dies trifft Videogames besonders, da Videogames geradezu von Bedingungen leben (ifs, loops etc).

Gridrunner (Jeff Minter) – 68000 ATARI ST Assembler:

// {} vs a: b:
// Mehr Subroutinen in Assembler > Frage an die Entwickler
// Vgl dazu die Demoscene

Assembler (C64): Fehler, Rumprobieren, Analyse, Konzeptfehler, neu anfangen?

Schreibe eine Antwort

Warum nur kopiert es die Color- und die Multicolorfarben nicht richtig rein in die entsprechenden Speicherbereiche?

Coding in Assembler ist Hardcore-Arbeit (vergleichbar mit Brainfuck-Coding). Beim Coden entsteht ein Konstrukt, das ausgeführt wird und etwas tut. Tut es das Richtige? All das ist in Assembler noch eine Runde schwieriger, da der Output nicht so simple ist, da die Möglichkeiten klar sind und Heisenbergsche Fehler (Unscharfe Fehler) gerade im unendlich oft vorkommen.

Fail

Funktioniert etwas nicht, probiert man rum, versucht es systematisch mit Ausgaben, Annahmen, Analysen.

Ist alles wie es sollte vom Code her?
Im Code gibt es keine Probleme? Und doch funktioniert es nicht?
Ist es ein Modellfehler? Funktioniert die Grafikrepräsentation anders? Habe ich falsche Vorstellung von der Sprache? Der Maschine?
Gibt es einen Konzeptfehler?
Ein Problem mit überschriebenen Registern? Soll ich neu anfangen?

Die Unsicherheiten mit Assembler – obwohl im Einzelnen so klar – sind gross. Und ja Brainfuck funktioniert tatsächlich ähnlich.

Braucht es einen neuen eigenen BlockEditor für C64 Gamedesign?

Schreibe eine Antwort

Im Rahmen der experimentellen Archeologie kommt die Frage auf: Braucht es neue Tools? Braucht es diese Tools (und wie verfälschen sie das Bild? (Wobei viele C64 Sachen als Demake etwa grafisch vom Amiga enstanden). Andere neue Tools im selben Umfeld TilebasedGraphics ist etwa TILES. Im vorliegenden Fall wird nun doch ein neues Tool entwickelt. Warum? Endlich wieder einmal nicht Assembler programmieren und so entsteht direkt ein Vergleich zu den Bedingungen Mitte der 80er Jahre und es soll ein Block/Tile Editor entwickelt werden, der das Designen direkt integriert, also Echtzeitänderungen möglich gemacht am Tile und im Playfield. Zusätzlich soll das Erstellen von Seamlesstiles vereinfacht werden. Neu sollen auch die Farben in ihrer Farbwahl aus Designperspektive angeordnet werden. Die Nachteile sind aber auch klar: schwer nutzbar in anderen Bereichen. Insofern ist dieser Editor eher auch ein Forschungstool rückwärtsgerichtet, wie hätte ein Hilfsmittel aussehen müssen. Vgl. dazu auch Blob-Editor beim Amiga (Swiss).

Aktuellste Version