In meinem Forschungsprojekt über die Technikkulturen der BASIC-Programmierung untersuche ich unter anderem die Rezeption des Spieles »Breakout«, das zuerst 1975 als Arcade-Spiel von Atari veröffentlicht wurde und zwei Jahre später von dessen Erbauer Steve Wozniak noch einmal in BASIC für seinen jüngst entwickelten 8-Bit-Computer »Apple //« programmiert wurde.
Seit Wozniaks BASIC-Breakout sind unzählige Versionen des Spiels von Profis und Hobbyisten in BASIC für so gut wie jede Homecomputer-Plattform entwickelt worden. In meinem Projekt wähle ich zehn dieser historischen Implementierungen aus, die ich im Detail untersuche. Neben den stilitischen Merkmalen interessiert mich auch die Gestaltung der audio-visuellen Oberflächen der Spiele. Gerade in Puncto Grafik unterschieden sich die Homecomputer der 1980er Jahre sehr voneinander.
Pseudo-Grafik
Die am häufigsten anzutreffende Grafik-Art bei den »Breakout«-Implementierungen ist die so genannte Pseudo-Grafik. Hierfür werden Zeichen des eingebauten Zeichensatzes verwendet, die entweder direkt für die Spielgrafik verwendet werden können oder durch Redefinition von Zeichensatz-Elementen umgestaltet und an die Bedürfnisse angepasst werden.
Das Prinzip basiert auf der Tatsache, dass Zeichensätze in den ROMs der Computer als Bitmuster abgelegt sind, wobei jedes Zeichen 8 Byte belegt. Diese 8 Byte lassen sich als 8 Zeilen zu jeweils 8 Bit darstellen, so dass sich jedes Zeichen des Zeichensatzes in einer 8×8-Bit-Matrix abgelegt wird, die sogar einige stilitische Freiheiten ermöglicht (wenn man einmal einzelne Buchstaben der Zeichensätze von Homecomputer anschaut, wird dies augenfällig).

(https://bit.ly/42kGGk7)
»Smashout«
Eines der »Breakout«-Programme, die diese Art der Grafik nutzen, ist das 43 BASIC-Zeilen lange Spiel »Smashout«, das der australische Autor und Programmierer Tim Hartnell 1983 in dem Buch »Dymanic Games for your ZX Spectrum« veröffentlicht hat. Das Buch erschien auch auf Holländisch und Spanisch. Die spanische Version liegt mir als PDF vor. (In der englischen PDF fehlen leider ein paar Seiten – unter anderem die, auf denen der »Smashout«-Code abgedruckt ist.) Außerdem existiert im Netz ein Tape-Image, auf dem alle BASIC-Programme aus dem Buch abgespeichert sind, so dass man sie nicht noch einmal eintippen muss (was beim Spectrum wegen der tokenisierten Befehlstasten einigermaßen mühselig ist). Man kann die Programme direkt in den Emulator (oder über eine SD-Karte und ein passendes Modul in den Spectrum) laden. Ich habe für meine Untersuchung zunächst den Emulator »Fuse« (Mac-Version) verwendet.
Pixel-Fehler
Bei der Analyse des Codes ist mir ein Detail aufgefallen, bei dem es sich um einen »Desgn-Fehler« handeln könnte. Für das Spiel werden zwei Zeichen des Zeichensatzes neu definiert. Der Buchstabe »A« wird zu einem Mauerstein; der Buchstabe »B« zum rautenförmigen Spielball des Spiels. Ein Mauerstein des Spiels (so, wie er im im Buch abgedruckten Code definiert ist), sieht im laufenden Programm so aus:

Innerhalb der Mauer ergibt sich daraus das konsistente Bild von versetzt gemauerten Ziegeln:

Hier fällt nun auf, das die Ziegelsteine zwei verschiedene Designs haben, die sich dadurch unterscheiden, dass bei einem Ziegelstein ein kleiner Strich nach unten ragt, der bei dem anderen nicht zu sehen ist. Dies erklärt sich aus dem Bitmuster, das der Pseudo-Grafik zugrunde liegt. Es wird in der BASIC-Zeile 210 definiert. (In Zeile 215 wird die Grafik für den rautenförmigen Ball definiert):
210 DATA BIN 1110111,BIN 11110111,BIN 11110111,0,BIN 11111110,BIN 11111110,BIN 11111110,0
215 DATA BIN 1000,BIN 11100,BIN 111110,BIN 111110,BIN 11100,BIN 1000,0
Ordnet man die Binär-Zahlen aus Zeile 210 untereinander, sehen sie wie folgt aus:
1110111
11110111
11110111
0
11111110
11111110
11111110
11111110
0
Jede 0 in der Bitmap wird später als schwarzes Pixel gesetzt, jede 1 wird als andersfarbiges Pixel gesetztl. Wie bei Dezimalzahlen ist es nicht notwendig, führenden Nullen explizit zu schreiben. In Zeile 215 wurde dieses Prinzip angewendet, um Speicherplatz zu sparen (dort steht beispielsweise »1000« statt »00001000«). Die erste Binärzahl aus Zeile 210 wird vom Interpreter des Computers daher auch als 01110111 gelesen. Mit weggelassenen vorangestellten Nullen aufgefüllt, sieht die Bitmap so aus:
01110111
11110111
11110111
00000000
11111110
11111110
11111110
11111110
00000000
Die in der ersten Zeile vorangestellte 0 und wird dann als schwarzes Pixel gesetzt – und genau dieses ist jener so unschön in die Grafik ragende Punkt.
Debugging – De-Pixeling – 40 Jahre später
Der Fehler hätte bereits bei Drucklegung des Buches entdeckt werden können, hat man unterhalb des BASIC-Listings doch ein Screenshot platziert, das trotz seiner schlechten Qualität den enervierenden Pixel deutlich erkennen lässt:

Ich habe das fehlende Bit, bei dem es sich um das linke und somit – bezeichnenderweise – »most significant bit« handelt, dort nun eingefügt. Damit sieht die Grafik nun so aus:

Es ist nur ein Bit – nach Shannon der kleinst-mögliche Unterschied, den man machen kann – das hier 40 Jahre lang gefehlt hat. Aber es zeigt sich, dass selbst ein einziges Bit einen großen Unterschied machen kann, wenn es uns als Pixel optisch quasi ins Gesicht springt und unser Gestaltempfinden verletzt.
Bei meiner Hintergrundrecherche zum Code bin ich auf den Wikipedia-Eintrag zu Tim Hartnell gestoßen. Hatte ich zuvor noch gehofft, ihn vielleicht mit ein paar Fragen zu seinem Programm kontaktieren zu können, musste ich im Eintrag lesen, dass er bereits 1991, im Alter von nur 40 Jahren, gestorben ist. Damit könnte diese kleine Korrektur einer seiner Arbeiten auch als Hommage an ihn gesehen werden.
Zitation
Stefan Höltgen, »Das wichtigste Bit«, in: Gerastertes Wissen, 2. Juni 2023, URL: https://pixel.hypotheses.org/2155. Abrufdatum: 28. September 2023.