Digital Experimental Archeology in Action: Atari ST – Draw Small Text [20 Min]

Das Recording ist Realtime aufgenommen worden anhand einem konkreten Problem im DevProzess der GameEngine und des Spiels (Port vom Amiga) HolyCube (Orginal C64 Game).

zeigt meine persönliche Arbeitsoberfläche. Diese besteht aus:

0. MacOS X
1. Compiler in der Shell
2. Editor (Sublime)
3. Atari Emulator: Hatari
4. eigenes GrafikTool für Tile-Design

Das anstehende Problem hier: Die Textroutine für kleine Texte (drawSmallText) scheint überhaupt nicht zu funktionieren. Dahinter liegt das Problem der Routine drawSmallBlock. Das normale System in der Engine ist 16×16 Pixel gross. Für die Darstellung von kleineren Texten (Lauftext) wurde zusätzlich ein 8×8 Font erarbeitet. Die Blöcke sind alle nacheinander abgelegt in 2 Bytes (16Pixel) * 16 Linien.

Dieser 8×8 Font findet sich im Tiledesign-tool in den Blöcken 2+.

Der Screen des Atari ST ist aufgebaut nach Linien. Eine Linie besteht aus jeweils 16 Pixeln in 2 Bytes*4 Ebenen. Die Bitplane-Anordnung ähnelt damit mehr dem C64 als dem Amiga, wo die Bitplanes pro Wert auf 4 verschiedene Bereich verteilt ist.

ATARI ST – ein 16 Pixel Block (20 Pro Linie)

%10010000 00000000 +
%01010000 00000000 +
%00110000 00000000 +
%0011000 00000000 +

Ergibt Total 16 mögliche Farben :
1*1
1*2
1*4
1*8
1+2+4+8 = 15
1|2|4|8|15

Dadurch ergibt sich das Problem, jeweils nur 1 Byte * 4 (8Pixel) von einem Ort in den anderen zu kopieren. Dann zum nächsten. Im Screen liegen dann anders als im Blockbereich. Diese Bytes dann eine Zeilenlänge auseinander – also 160 Bytes.

Wie im folgenden zu sehen ist, sollte ein 0 gezeichnet werden 20 mal in der obersten Linie, doch nichts passiert.

Im Video oben sieht man nun den Prozess.

00. Checken des Effekts (Erwartung gegen Realisierung)
0. Analyse des Problem
1. Änderung des Codes
2. Compilierung
3. Oeffnen des Emulators (gemeinesamer Ordner in C von Atari ST und MacOS)
4. Starten des Programms (nur 2x mal korrektes Starten – keine Ahnung warum nicht mehr)

Debugging

Im obigen Prozess wird versucht herauszufinden, was ist das Problem. Schnell wird klar, das Problem liegt in der Routine drawSmallBlock. Dies ist ersichtlich an den Verschiebungen innerhalb des Screens.

Sichtbar

Mehrere Durchläufe den Bildschirmaufbau zu verstehen und anzupassen. Einige Fehler mit Byte (0-255) statt Word (0-65537) oder LongWord (0-…). Hier sieht man vorallem „Konzentrationsproblem“ oder anders gesagt, Probleme damit, dass eben alles nur Speicher ist. Auch der Screen und sein Inhalt.

Langsames Herantasten.

Schwierigkeit besteht im Verstehen des techn. Bildschirmaufbaus (Memory-Pixel) und das korrekt Verschieben und Rechnen von Memory/Screen Daten.

Irgendwann gelingt es.

// ToDo: feingliedriges Erklären, was passiert und was gedacht wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert