Schlagwort-Archive: Java-Remake

Exemplarisch wie ich mein SPACOLA-Remake entwickle, eine kleine Anekdote aus meinem Leben als Softwareentwickler: Bei meinen ziellosen Recherchen zur Historie des Atari ST und seiner erstaunlichen, reichhaltigen Public-Domain-Welt stolperte ich über eine kurze Spezifikation des Dateiformats für Bilddateien aus dem sehr beliebten Zeichenprogramm STAD. Der Name ist ein Akronym und steht für ST-aided Design. Das Programm wurde 1986 von Peter Melzer bei den Application Systems Heidelberg veröffentlicht und eröffnete den Nutzern ungeahnte Möglichkeiten – selbst 3D-Modellierung war damit machbar, wenn auch äußerst sperrig und unbequem. Auch meine Wenigkeit verbrachte in den 80ern und 90ern sehr viele Kindheitstage mit dem Malen von lustigen Bildern und Animationen in STAD. Achja, bevor ich darauf angesprochen werde: Ja, rein theoretisch war STAD keine PD-Software, aber wir wissen doch alle wie das damals so lief. Wer kennt nicht die berüchtigte Diskettenwanderung.

Die Bilder konnten in mehreren verschiedenen Formaten abgespeichert werden, darunter unkomprimiert als Doodle, gepackt, oder als DEGAS-Bild (ein weiteres zeitgenössisches und sehr bekanntes ST-Zeichenprogramm). Dabei entwickelte Melzer mit den gepackten .PAC-Bilddateien sein eigenes Bildformat, das die Bildinformationen relativ unspektakulär mittels RLE kodiert und so platzsparend auf der Diskette ablegen kann. Nun, meine Programmierkenntnisse in GFA-BASIC in den 90ern waren leider sehr begrenzt, und so konnte ich seinerzeit nur unkomprimierte Bilder in meine Progrämmchen einlesen, da ich dafür Codebeispiele in meinen Programmierbüchern fand. Im Traum hätte ich nicht daran gedacht, gepackte STAD-Bilder zu laden oder noch verrücktere Bildformate. Ich hatte schlicht keinen Code dafür, und wie andere Entwickler solche Formate in ihren Quellcode einbinden, das war für mich eher schwarze Magie.

Bekanntes Beispielbild „KRUSCH.PAC“ aus STAD. Die einzelnen Fortschritte während der Entwicklung des STAD-PAC-Konverters von oben nach unten. (Rote Bereiche sind nur Hintergrund, wo noch nichts gezeichnet wurde.)

Doch kein Problem ist für einen Haudegen wie mich alt genug um es nicht doch noch zu lösen: Kaum 30 Jahre später will ich es mir beweisen. Ich kann einen STAD-PAC-Konverter entwickeln. Vielleicht nicht mehr unbedingt in GFA-BASIC, aber zumindest in Java, und diesen damit theoretisch für mein Remake-Projekt nutzbar machen. Wofür genau? Das ist mir noch vollkommen unklar, aber wen kümmert es schon. Um eins klarzustellen: Es gibt funktionierenden Cross-Platform-Code in der Wildnis um STAD-Dateien zu laden. Unter anderem der beliebte Bildbetrachter “XnView MP” lädt alle STAD-PAC-Dateien erfolgreich, was mich anfangs extrem überrascht hat, da es doch heutzutage ein mindestens äußerst exotisches und rares Dateiformat ist. Scheint so als wolle der Entwickler dem Anspruch gerecht werden, möglichst viele Dateiformate zu beherrschen. Leider ist ausgerechnet die Software dieses Entwicklers natürlich nicht quelloffen, und daher für Studien nicht verfügbar, doch mit Hilfe der im Internet frei verfügbaren Spezifikationen wollte ich es auf jeden Fall selbst versuchen.

Und so setzte ich mich daran und begann die Spezifikation zu implementieren. Aus meiner Kindheit besitze ich unzählige eigene PAC-Dateien mit Bildchen, ich konnte aber zusätzlich sehr viele Beispieldateien im Netz finden und bei der Entwicklung zum Testen nutzen. Wie die Spezifikation beschreibt, gibt es zwei Sorten von STAD-PAC-Dateien: Die vertikal gepackten, und die horizontal gepackten. Die Implementierung der RLE-Dekodierung war dann auch tatsächlich nicht so schwer, vieles an Vorarbeit zum Bytestream-Handling hatte ich bereits früher erledigt bei der Entwicklung an meinem Shapelist- und Dongleware-PAC-Konverter. Schwierig wird es, wenn man zusätzlich Quellen im Internet findet, die zwar ebenfalls das Bildformat beschreiben, aber leider Fehler enthalten, wie einen falschen Runcount zu verwenden. Merke: Man sollte nicht alles glauben, was im Netz steht.

Schon relativ schnell erkannte ich die erste größere Schwierigkeit: Alle Internetquellen haben die Tatsache gemeinsam, dass sie die RLE-Dekodierung genau dokumentieren, aber bei den unkomprimierten Bilddaten nur noch ganz abstrakt von “use bytes” die Rede ist. Es wird tatsächlich nirgends beschrieben, wie das Bild damit genau gezeichnet werden soll. Der Teil fehlt einfach, so als wäre er entweder unnötig oder komplett trivial. Und selbst wenn die Bezeichnung “vertically packed” es so darstellt, die Pixel fortlaufend von oben nach unten zu zeichnen, ist leider nicht des Rätsels Lösung. Und so verbrachte ich noch eine Handvoll weiterer Stunden damit, die Zeichenroutinen zu debuggen, zu reverse engineeren und inkrementelle Fortschritte zu feiern, bis ich endlich eine fehlerfreie Implementierung in den Händen hielt. Gerne möchte ich das Internet mit meinen mühsam selbst gesammelten Erkenntnissen bereichern und die Spezifikationen um die überall fehlenden Informationen ergänzen:

Die vertikal gepackten Bilder (mit dem Header “pM86”) werden in Blöcken von je 8×8 Pixeln gezeichnet, wobei die Pixel innerhalb des Blocks zuerst von links nach rechts und von oben nach unten gezeichnet werden, während die Blöcke zuerst von oben nach unten und von links nach rechts gezeichnet werden. Am Ende erhält man ein binäres Vollbild mit (mehr oder weniger) 640×400 Bildpunkten. Die horizontal gepackten Bilder (mit dem Header “pM85”) werden als fortlaufende Pixelsequenz von links nach rechts und von oben nach unten gezeichnet. Vertikal gepackte Bilder sind dabei in einer erstaunlichen Mehrheit vorzufinden, während das horizontal gepackte Format vermutlich älter ist und seltener vorkommt. Immerhin ist das STAD-PAC-Format um mehrere Größenordnungen weniger komplex als das Dongleware-PAC-Format, aber selbst hier musste ich ein wenig experimentieren und basteln.

Das ebenfalls bekannte STAD-Beispielbild „ESCHER1.SEQ“, dargestellt im STAD-PAC-Konverter

Aufgefallen ist mir außerdem, dass viele STAD-PAC-Dateien mehr Zeichenanweisungen im Bytestream enthalten als es zu zeichnende Pixel auf dem Bildschirm gibt. Aus diesem Grund muss meine Implementierung überzählige Runcounts und überflüssige Bytes am Ende der Datei verwerfen, wenn das Bild vorzeitig fertig ist. Das fand ich durchaus ein wenig seltsam und unnötig. Ebenfalls bemerkenswert, dass besagter Bildbetrachter XnView MP die wenigen horizontal gepackten STAD-Dateien zwar korrekt entpackt, aber aus irgendeinem Grund falsch darstellt: Es wird ein Bild erzeugt, das 640×400 Pixel enthält, doch es wird vertikal gestreckt auf 440 Pixel. Und selbst wenn man dieses Bild direkt nach PNG konvertiert, wird es mit diesem seltsamen Streckfaktor (DPI bzw. Pixels per Unit unterschiedlich in Y-Richtung) in den Metadaten der PNG-Datei gespeichert.

Da kann ich doch glatt stolz darauf sein, dass meine Implementierung einen Fehler weniger hat als einer der bekanntesten Bildbetrachter überhaupt. Alles in allem wieder einmal ein schönes, erfolgreiches, produktives Wochenende, an dem ich eine kleine historische Software-Knobelaufgabe lösen konnte. Das SPACOLA-Remake kann nun gepackte STAD-Bilder laden, falls es mal nötig wäre. Zusätzlich habe ich auch wieder die Arbeit an einigen kleineren Aspekten an dem Spiel aufgenommen. Wie das eben so ist, ich muss mich mal wieder in das Thema reinfinden, und dafür eignen sich am besten die einfacheren Aufwärm-Themen.

Ich will jetzt nicht unbedingt behaupten, dass ich fleißig bin, aber wenn ich mal ausnahmsweise nicht faul bin, dann bin ich so richtig nicht faul. Nach einer längeren Abwesenheit und gleichzeitigen Arbeitspause an meinem Spiele-Remake, bin ich nun endlich wieder dran. Mich hat aus irgendeinem mysteriösen Grund plötzlich wieder die Motivation eingeholt, und sofort konnte ich zumindest wieder etliche Kleinigkeiten angehen und Fehler korrigieren. Allerdings habe ich durch Zufall ganz unerwartet einen weiteren Meilenstein bei der Entwicklung erreicht; einen Punkt auf meiner To-Do-Liste, den ich definitiv irgendwann umsetzen wollte, selbst wenn dies einen Nutzen nur theoretischer Natur auf dem Papier bringt.

Was bisher geschah: Einem unfassbar mäßig begabten Entwickler eines Spiele-Remakes, der zwar nicht vom Erfolg seines Projektes überzeugt, aber dafür wenigstens nicht von seinem Ziel abzubringen ist, war es gelungen, die Original-Dateien des Atari ST-Spiels SPACOLA mit Hilfe eines Debuggers zu entpacken und anschließend sogar das undokumentierte Format der Sprite-Dateien zu dechiffrieren und einen eigenen Konverter zu schreiben. Dies sollte ihm endlich einen wichtigen Einblick in die Hintergründe der Unterhaltungssoftware einer längst vergessenen Zivilisation geben. Wie hatten unsere Vorfahren einst Spiele entwickelt? Wurden die Quellcodes damals noch in Keilschrift verfasst? Mussten Benutzer an einer Kurbel drehen, wenn sie ihren Heimcomputer starten wollten? Waren antike Computerprogramme auch nur in schwarzweiß? (In diesem Fall, ja!). Unermüdlich arbeitete der selbsternannte Software-Archäologe weiter an den historischen Dokumenten, um vielleicht irgendwann einmal das perfekte Remake zu erschaffen.

Teil 3 meines fortlaufenden Hintergrundberichts: Es war eigentlich reiner Zufall als ich im Internet auf die Reverse-Engineering-Erkenntnisse von Jeremy Sawicki aus dem Jahr 2003 stieß. Der hatte diverse OXYD-Spiele in ihren Farbversionen für den IBM-PC erfolgreich analysiert und deren Formatspezifikationen offengelegt, darunter das Levelformat, die Grafik- und Sounddateien. Seine Dokumentation war unter anderem nützlich bei der Entwicklung des freien OXYD-Klons Enigma. Als ich mir die Angaben zum Grafikformat genauer ansah, erkannte ich plötzlich viele Gemeinsamkeiten zu den PAC-Dateien, die in den alten Monochromversionen der frühen Dongleware-Klassiker Verwendung fanden. Diese Dateien enthielten binäre Vollbildgrafiken für die Spiele seit Esprit (1989) und bis mindestens OXYD2 (1991).

Ich hatte mich natürlich längst selbst mehrfach daran versucht, das seltsame Dateiformat zu dekodieren, zuletzt auf Grund meiner Erfolge beim Konvertieren der Sprite-Dateien, doch das PAC-Format widersetzte sich meinen Annäherungsversuchen konsequent. Bis auf einige sehr offensichtliche Headerinformationen konnte ich kaum sinnvolle Werte herauslesen, und meine einzigen Erkenntnisse über das Kompressionsverfahren bestanden darin, dass das Bild in Blöcke unterteilt wird, und die Pixelinformationen grundsätzlich durch ein XOR-Verfahren invertiert von oben nach unten beschrieben werden. Durch Manipulieren der Dateien im Hexeditor und anschließendem Beobachten der Auswirkungen in OXYD, stellte ich erstaunt fest, dass die Dateistruktur eine sehr eigenwillige sein musste, weil oft komplett unvorhersehbare und unintuitive Artefakte im Bild dadurch enstanden. Als ich keinerlei Gesetzmäßigkeiten ausmachen konnte, gab ich mein Vorhaben desillusioniert auf.

Seit heute weiß ich endlich sehr genau, was das große Problem war. Von Sawickis Arbeit angespornt, begann ich endlich an der Entwicklung eines eigenen Konverters, den ich letztlich in mein Remake einbauen wollte, so wie bereits getan beim Konverter für Sprite-Dateien. Ich studierte die Formatspezifikationen und implementierte die Dekompressions- und Zeichenroutinen. Ohne nun zu sehr ins Detail zu gehen (wer alles wissen möchte, kann die Originalseite lesen), besteht jede Packed-Bitplane-Datei aus einem Header, einem Bitstream und einem Bytestream. Der Bitstream beschreibt dabei die gesamte Struktur des Bildes, sowie Angaben über die Kompressionsmethodik, und der Bytestream enthält die tatsächlichen Pixeldaten, die entsprechend gezeichnet werden müssen.

Jedes Bild hat die Auflösung von 640×400 Bildpunkten und ist in Blöcken von je 16×16 Pixeln aufgeteilt. Der Bitstream beschreibt dabei, wie das Bild nacheinander in Reihen von Blöcken, Blöcken, Blockquadranten und Reihen von Pixeln in immer kleinere Häppchen aufgespalten wird, wobei jedes Element entweder übersprungen oder gezeichnet werden kann. Müssen Pixel gezeichnet werden, so wird ein Byte aus dem Bytestream gelesen und dessen Bits als Pixel interpretiert, abhängig von einer der Pixelreihen darüber, die miteinander XOR-verknüpft werden, also je nachdem ob ein Bit gekippt wird oder nicht. Die Formatspezifikation von Sawicki ist dabei technisch betrachtet soweit korrekt, aber leider an mehreren Stellen etwas unpräzise formuliert, so dass ich mehrere Fehler machte, deren Behebung mich viel Zeit gekostet hat.

Das Titelbild „TITLE.PAC“: Die einzelnen Fortschritte während der Entwicklung des PAC-Konverters von oben nach unten. (Rote Bereiche sind nur Hintergrund, wo noch nichts gezeichnet wurde.)

Während der Entwicklung fiel mir jedoch auf, dass Sawicki eines der Features des proprietären Dongleware-Formats definitiv nicht kannte: Neben dem Invert-Flag, das festlegt, ob das fertige Bild noch invertiert werden muss, gab es in meinem Archiv eine einzelne Datei, die ein undokumentiertes Flag setzt. Zum Glück konnte ich am Output des Konverters bereits erkennen, was dem Bild fehlte: Es musste ein Dithered Pattern („Schachbrettmuster“) mittels XOR über das gesamte fertige Bild gezeichnet werden, um die ursprüngliche Grafik wiederherzustellen. Dieser Modus wird wohl zwar nur sehr selten angewandt, aber mein Konverter unterstützt dieses Feature nun ebenfalls. Im Endeffekt war es mir in geschätzt sechs bis sieben Stunden gelungen, eine Implementierung abzuliefern, die sämtliche 16 PAC-Dateien, die ich aus vier Spielen gesammelt hatte, fehlerfrei einzulesen und anzuzeigen vermochte.

Ohne das hilfreiche Dokument wäre ich immer noch nicht schlauer, und sonst einen Konverter zu schreiben, hätte ich wahrscheinlich nur geschafft wenn ich viele Wochen und Monate in mühsames Debugging der Spiele investiert hätte. Ob ich mir diese Zeit jemals hätte nehmen wollen, sei mal dahingestellt. Nun bin ich umso glücklicher über diese angenehme Abkürzung, die ich nehmen konnte. Der Konverter ist fertig und bereits ins Remake eingebaut. Dadurch bin ich jetzt endlich in der Lage, auch die originalen Grafikdateien in unveränderter Form im Remake einzulesen und zu verwenden. Das macht – wie eingangs im Absatz beschrieben – für den Spieler absolut keinen Unterschied, für mich als Entwickler mit Perfektionsdrang aber einen gewaltigen.

Mein SPACOLA-Remake kann nun die ursprünglichen Sounddateien, die Sprites und die Grafikdateien korrekt lesen. An der Interpretation der originalen Leveldaten arbeite ich mich weiterhin Schritt für Schritt voran, sie werden aber immerhin schon komplett eingelesen. Alles was jetzt noch vollständig fehlt: Die Musikdaten im SMS Synthesizer-Format von Jürgen Piscol. Ob ich dieses Kapitel jemals abschließen werde, lässt sich im Moment noch nicht einmal sagen. Andererseits, wer weiß schon, ob sich nicht doch wieder jemand findet, der zufällig eine detaillierte Analyse des Formats in Schriftform für mich zur Einsicht hat. Dann könnte nämlich alles ganz schnell gehen.

Das „Boss Is Coming“-Bild aus OXYD2, dargestellt im PAC-Konverter, zeigt den Datenbank-Manager „Phoenix“ von den Application Systems Heidelberg

Und falls sich nun jemand fragt, wieviele PAC-Dateien in SPACOLA Eclipse denn nun eingelesen und angezeigt werden können: Es sind ganze vier Dateien! Erstens, das Titelbild beim Laden des Spiels. Zweitens, das typische HUD mit dem Radar auf der rechten Seite. Drittens, der Rentenbescheid zum Ausdrucken nach Abschluss des letzten Levels. Die vierte und letzte PAC-Datei ist tatsächlich ein ungenutztes Bild, das die Kontaktadresse des Dongleware-Verlages enthält. Vermutlich wurde es in einer früheren Version des Spiels verwendet, und dann durch ganz normalen Text in der Dongleware-Schriftart ersetzt. Alle diese vier Originaldateien werde ich nun ins Remake einbauen und in irgendeiner Weise nutzen, damit sich der ganze Entwicklungsaufwand auch gelohnt hat.

Was bisher geschah: Einem erfolglosen Remake-Entwickler ist es trotz aller Widrigkeiten schließlich doch noch gelungen, alle Originaldateien von SPACOLA mit Hilfe eines Debuggers in einem Atari ST-Emulator zu extrahieren. Doch das sollte noch lange nicht das Ende seiner abenteuerlichen Reise in die Heimcomputer-Vergangenheit des späten 20. Jahrhunderts sein, denn die antiken Hieroglyphen in den Originaldaten mussten erst noch aufwändig von einem gewieften Software-Archäologen entziffert und entschlüsselt werden. Dies ist seine haarsträubende Geschichte.

Da saß ich nun also, mit einem ganzen Haufen alter, unlesbarer Sprite-Dateien aus dem Spiel SPACOLA, ohne irgendeinen Hinweis, was ich damit anfangen könnte, und welche sagenhaften Geheimnisse diese historischen Dokumente letztlich bargen. Lediglich aus den perfekt erhaltenen Dateinamen ließ sich ungefähr ersehen, welche Sprites genau darin zu finden seien. Mein geschätzter Mit-Atarianer und Blogleser Gerry hatte mich glücklicherweise bereits Jahre zuvor mit einem wichtigen Zeitschriftenartikel aus der guten alten „ST Computer“ versorgt, in dem Meinolf Schneider höchstpersönlich im Jahr 1990 über die Entwicklung von Bolo und Esprit berichtet. Dieser Artikel erwies sich als pures Gold und enthielt so einige hochinteressante Einblicke und Fakten, die mir als Entwickler wiederum bedeutende Implementierungsdetails verrieten. Unter anderem beschrieb Meinolf darin einzelne Aspekte seines eigenen Sprite-Formats, den sogenannten „Shapelists“. Wie das Format aufgebaut war, war daraus zwar leider noch lange nicht ersichtlich, aber dafür andere wichtige Eigenarten, die später von Vorteil sein sollten.

Der Hex-Editor HxD zeigt eine SHL-Datei

Das Hilfsmittel Nummer eins war wiederum der Hex-Editor, mit dem ich mir die Dateien Byte für Byte quasi unter der Lupe ansehen konnte. Bei genauerem Hinsehen erkannte ich, dass diese Dateien immer aus mehreren „Blöcken“ bzw. Abschnitten bestehen, nämlich aus mindestens zwei, so wie im Falle der kleinsten Datei „SPI_MINE.SHL“. Diese spezielle Datei sollte mir schließlich zur Lösung des Rätsels dienen, da ich hierüber zum Glück ausreichend wusste. Da sie nachweislich aus genau zwei Blöcken besteht, wusste ich nun ziemlich sicher, dass nur die zwei einzelnen Sprites der beiden Sprengminen des Originals darin enthalten sein konnten. Ich wusste wie diese Sprites genau aussehen, wie groß sie sind, und am allerwichtigsten, dass diese Sprites zu einem großen Teil symmetrisch sind. Meine Chance bestand also darin, in den Shapelists nach genau diesen Symmetrien Ausschau zu halten. Würde ich eine Symmetrie im Bytemuster der Datei wiedererkennen, hätte ich schon einen äußerst wichtigen Ansatz gefunden.

Als ich einige Hexwerte (in Big Endian Bytereihenfolge) in der Shapelist in Dezimal umgerechnet hatte, fand ich so unter anderem die Dateigröße und die einzelnen Spritegrößen wieder, und so konnte ich sogar ausmachen, welches Sprite in welchem Block gespeichert ist. Ich konzentrierte mich also auf den kleineren ersten Block. Es dauerte nicht lange und ich hatte einen Teil ausgemacht, der symmetrisch aussah, und so folgerte ich, dass genau hier die Pixelinformationen begraben sein mussten. Bei einer Monochromgrafik war es zwar durchaus naheliegend, aber ich brauchte trotzdem einige Minuten, um darauf zu kommen, dass hier jedes Byte genau eine Reihe von 8 Pixeln darstellen konnte. Mit Hilfe des Windows-Taschenrechners ließ ich mir die Hex-Werte binär anzeigen, und so malte ich die gesetzten Bits auf ein Pixelgrid. Tatsächlich erkannte ich schon kurz darauf etwas, das zumindest teilweise nach den invertierten Umrissen der linken Hälfte des erwarteten Minen-Sprites aussah. Das war für mich erneut ein entscheidender Durchbruch. Ab hier war ich sicher, ich könne die Shapelists lesen.

In der Folge stellten sich mir bei der Analyse einige wichtige Merkmale des Dateiformats heraus: Die Sprites waren immer kodiert in „Scheibchen“ zu je 8 Pixeln Breite mit variabler Höhe. Zudem gab es pro Sprite meist zwei Schichten: Einen Hintergrund mit Transparenzinformationen, und einen Vordergrund. Manchmal gab es auch nur eine Schicht ohne Transparenz. Anschließend begann der nächste Block, der das nächste Sprite enthielt. Große Teile der Datei verstand ich bis dahin noch nicht, daher entschied ich mich zunächst, diese zu ignorieren, denn ich begann gleichzeitig damit, einen Konverter zu entwickeln, der SHL-Dateien laden und diese in ein anderes Grafikformat übersetzen konnte. Nach ein oder zwei Stunden hatte ich meinen Code schon soweit, dass er die beiden Minen aus der Originaldatei perfekt auf dem Bildschirm anzeigte. Ich wähnte mich bereits am Ziel, als ich zur Kontrolle eine andere SHL-Datei laden wollte, und der Konverter mit diversen Fehlern abbrach. Mit dem Format dieser Datei konnte er nichts anfangen, und so musste ich erneut mit dem Hex-Editor ran.

Ein monochromes Minen-Sprite aus der Shapelist mit Transparenzdaten in GIMP geladen

Ich entdeckte, dass Shapelists bisweilen mehrere „Versionen“ desselben Sprites beinhalteten, aber den Grund kannte ich nicht, bis sich herausstellte, dass jede folgende Sprite-Version im Grunde nur um jeweils einen Pixel nach rechts verschoben war. Die Lösung lieferte besagter ST-Computer-Artikel, in dem Meinolf erläuterte, dass er alle acht Möglichkeiten zur horizontalen Positionierung einer Grafik vorberechnete. Dies war nötig, weil er die Sprites direkt in den Grafikspeicher des Bildschirms kopierte, was natürlich nur in ganzen Bytes möglich war. Er schreibt hierzu genauer: „Will man die Figur auf eine beliebige horizontale Position darstellen, müssen die einzelnen Bits, die ja Bildpunkte repräsentierten, innerhalb eines Bytes verschoben werden. Und dies kann bei vielen zu zeichnenden Figuren für eine 72Hz-Animation zu langwierig sein.„. Diese bit-geshifteten Versionen sind in den Shapelists also allesamt enthalten. Ich entdeckte außerdem, dass die Shapelists im Header immer alle Offsets enthalten, die verwendet werden können, um direkt zum Beginn eines Blocks zu springen.

Nachdem ich meinen Konverter angepasst hatte und er flexibler mit dem Shapelist-Format umgehen konnte, erlaubte mir das bereits, einige Dutzend SHL-Dateien fehlerfrei zu laden, während so manche andere Datei jedoch noch Darstellungsprobleme hatte. Auch dies konnte ich wiederum korrigieren, so dass ich das SHL-Format dadurch immer besser zu verstehen lernte. Am Ende war mein Konverter problemlos in der Lage, alle Shapelists aus Bolo, Esprit, OXYD und Spacola zu laden. Die Shapelists aus OXYD 2 könnte er vermutlich auch konvertieren, aber diese müsste ich dazu natürlich erst mühsam aus dem Spiel holen. Eine letzte Erkenntnis konnte ich schließlich noch gewinnen: Zu jedem Sprite sind in der Shapelist die genauen horizontalen und vertikalen Pixeloffsets gespeichert, also die Zahlenwerte, um wieviele Pixel das Sprite relativ zur Position des entsprechenden Spielobjekts verschoben gezeichnet werden soll – im einfachsten Fall muss man das Sprite nämlich über dem Objekt zentrieren.

Ein Zusammenschnitt mehrerer konvertierter Shapelist-Inhalte aus Bolo (1987), Esprit (1989), und SPACOLA (1991)

Besagten Shapelist-Konverter habe ich mittlerweile nativ in das Remake SPACOLA ECLIPSE integriert, und das Spiel lädt folglich nicht nur die Original-Sounddateien, sondern inzwischen auch schon einige der Original-Spritedateien. Die Transition hin zu Shapelists ist aktuell noch im Gange und wird auch noch einige Monate andauern, aber der Vorteil ist für mich eindeutig: Absolute Originaltreue ohne unnötige Kompromisse. Durch die Verwendung von Shapelists werden all meine bisherigen Unsicherheiten verschwinden, ob ich dieses oder jenes Sprite auch wirklich pixelgenau und fehlerfrei gezeichnet habe, und ich kann meine geringe Aufmerksamkeit wieder anderen, deutlich wichtigeren Dingen widmen. Zum Beispiel dem Spiel.

Mit der Programmierung meines kleinen SPACOLA-Remakes habe ich übrigens heute vor exakt 10 Jahren begonnen. In dieser Zeit wuchs das Hobby-Projekt auf 54.300 Codezeilen in 326 Quelldateien an, und umfasst zusätzlich knapp 1500 Grafikdateien und 64 Audiodateien. Für volle 10 Jahre Entwicklungszeit ist das wahrlich nicht so viel, aber schneller bekomme ich es nicht hin. Ich habe eben mein ganz eigenes Tempo, das sowohl von motivierten als auch von faulen Phasen mitbestimmt wird. Dafür steckt trotzdem eine ganze Menge Herzblut, Schweiß und Erfahrung in meinem Werk. Wann das Spiel fertig oder wenigstens mal spielbar sein wird, steht weiterhin in den Sternen. Aber wer meine vielen kleinen Fortschritte bis heute fleißig verfolgt hat, und die Hoffnung immer noch nicht aufgegeben hat, den werde ich vielleicht in den kommenden Wochen doch noch ein bisschen überraschen können.

To be concluded…

Ein Besucher meines Blogs hat mir vor einigen Wochen die absolut berechtigte Frage gestellt, ob die Entwicklung an meinem kleinen SPACOLA-Remake-Projekt denn inzwischen eingestellt wurde. Ich möchte diese Gelegenheit für ein ehrlich gemeintes Lebenszeichen und wieder einmal ein wenig Selbstkritik nutzen. Ich bin zudem dankbar für jedes bisschen Aufmerksamkeit, das mir immer wieder einzelne Leser des Blogs schenken, die sich für das Projekt interessieren. Das zeigt mir zumindest, dass ich die Arbeit nicht alleine für mich mache (obwohl das natürlich nach wie vor der Hauptgrund ist).

Die gute Nachricht: Nein, die Entwicklung an dem Spiel ist definitiv NICHT eingestellt. Ja, ich arbeite Monat für Monat daran weiter. The show must go on.
Die schlechte Nachricht: Ich arbeite sehr langsam, und meine Motivation schwankt leider von Woche zu Woche. Es tut mir leid, so ist es eben. Manchmal hänge ich mich so richtig rein und kann mich kaum bremsen. Manchmal kriege ich aber auch wochenlang mal so überhaupt nichts gebacken. Das ärgert mich dann meist selbst, so dass ich versuche, Strategien zu entwickeln, um wieder in das Thema hineinzufinden.

Ein Release von SPACOLA ECLIPSE liegt also eher in ferner als in naher Zukunft. Das mag enttäuschend sein, aber das heißt nicht, dass ich aufhöre. Und es heißt vor allem nicht, dass ich zwischenzeitlich nichts gemacht habe, denn kleine Fortschritte gibt es ständig. Das möchte ich heute mit diesem Beitrag zeigen. Vor allem die Farbversion des Remakes hat in den letzten Wochen erneut Fahrt aufgenommen. Und da Bilder bekanntlich mehr sagen als 1000 Worte, möchte ich einfach mal drei aktuelle Impressionen der neuesten Work-In-Progress-Version 0.85 zeigen.

Work-In-Progress-Version 0.85 im verbesserten „SPACOLOR“-Spielmodus

Ich habe versucht, einen Screenshot zu erstellen von einer möglichst hektischen und actionhaltigen Szene, auf der viele Elemente gleichzeitig zu sehen sind. Das komplette HUD ist quasi fertig. Wie zu erkennen ist, sind die Stationsgeschütze noch nicht koloriert, aber vieles andere schon. Außerdem sorgen die vielen Explosions- und Antriebs-Partikel schon für eine Menge Bewegung und Gewusel auf dem Bildschirm. Um meinen neuen Lenkraketen-Code zu testen, habe ich die Stationsgeschütze so eingestellt, dass sie eine größere Anzahl Lenkraketen auf den Spieler abfeuern, anstelle kleinerer Geschosse. Die gefährlichen Stationsgeschütze eingeschlossen, sind hier immerhin drei Gegnertypen zu sehen, die allesamt Jagd auf den Spieler machen. Der kann in der Szene allerdings mit seinem Schutzschild (noch) dagegen halten kann. Mehrere Lenkraketen werden demnächst von allen Seiten einschlagen, was die Situation sicherlich nicht verbessert.

Level-Auswahl-Bildschirm vor jeder Runde

Am Anfang des Spiels kann man stets nur ein einziges Level auswählen. Die schwierigeren Sonnensysteme werden dann nach und nach zugänglich, sobald man in der Galaxie ein wenig Geld verdient hat. Das gesamte Spiel mit allen Menüs ist inzwischen in Farbe verfügbar, darunter natürlich auch die Schriftarten, die Mauszeiger, das Level-Auswahl-Panel, und alle Schaltflächen. Am unteren Rand analog zur TOS-Demo des Ur-SPACOLA prangt ein kleiner Hinweis bezüglich der Unfertigkeit des Remakes. Authentizität und Originaltreue ist bei der Entwicklung immer ein entscheidendes Grundprinzip. Jeder einzelne Pixel muss immer genau dort sitzen, wo er im Original auch platziert worden wäre. Hierzu nehme ich mir viel Zeit, um Screenshots zu vergleichen und Abstände zu messen.

Künstlerische Freiheiten nehme ich mir ausschließlich dort, wo sie absolut sinnvoll und vor allem nötig sind. So ist zum Beispiel der gesamte Metallic-Look der Farboberfläche eine alte Idee von mir, die ich schließlich möglichst perfekt mit dem Original-Design in Einklang bringen wollte. Selbst den Farbverlauf des Remake-Schriftzugs habe ich nicht einfach irgendwie aus dem Ärmel geschüttelt, sondern es basiert auf einem Design von der alten Dongleware-Webseite, wo es bereits eine frühe eingefärbte Fassung zu bewundern gab.

Der gute alte „SPACoLASSIC“-Spielmodus mit handgepixelter Monochromgrafik

Selbstverständlich lässt sich das Spiel auch komplett in der Originalgrafik spielen, bei der alles soweit unangetastet bleibt (verständlicherweise bis auf Details im Intro). Für Fans und Puristen gibt es dann „nur“ Monochrom-Sprites bei limitierten 36 Bildern pro Sekunde, und keinerlei Partikeleffekte oder sonstige neue Spielereien. Das Gameplay bleibt allerdings identisch.

Wer wissen möchte, an welchen Details ich mich da eigentlich so aufhalte, der möge gerne weiterlesen: Im Remake gibt es inzwischen ein Weapon-Interface, das es allen Schiffen im Spiel (Spieler, Mitspieler und Feinde) dynamisch ermöglicht, quasi auf Befehl eine andere Waffe zu aktivieren, seien es die Spieler-Standardwaffe, Lenkraketen, Laserwaffen, zwei Arten von Turret-Waffen, Minen, oder beispielsweise schlagkräftige Kanonenkugeln. Darüber hinaus habe ich eine AimHelper-Klasse geschrieben, die alle im Spiel bekannten Arten von Anvisier-Techniken der Gegner wiederverwendbar implementiert und mühelos auf alle möglichen Spielobjekte anwenden lässt. Wie präzise oder wie schlecht ein feindliches Schiff zielt, kann ich so dynamisch ohne Quellcode-Änderungen bestimmen. Damit kann sogar der Spieler eine Art „Aimbot“ bekommen, wenn man denn möchte. Das wäre jedenfalls eine Idee für ein zusätzliches Powerup.

Im Dezember habe ich übrigens das SPACOLA-Codebuch abgetippt. Nein, nicht die Koordinaten. Die gibt es schon in digitaler Form und sind im Remake auch zu 100% enthalten. Die Rede ist von den Powerups, also die Extras, die als kleine Symbole neben den Koordinaten im Buch abgedruckt sind. Mein innerer Perfektionist wollte partout nicht damit leben, dass dieser Teil des „Sternenatlas“ nicht im Remake nutzbar sein wird. Also habe ich angefangen, die Extras mühsam abzutippen, wo sich allerdings nach zwei Buchseiten bereits zeigte, dass ich so niemals fertig werden würde. Also habe ich mir ein kleines Progrämmchen geschrieben, das mir die Eingabe der Zeichen erleichtert: Ich musste quasi nur noch das jeweils passende Symbol anklicken und das Ergebnis wird direkt in eine CSV-Datei geschrieben.

Aber im Endeffekt bleibt alles Handarbeit. Es geht hier schließlich um 154 Buchseiten á 3 Blöcke pro Seite á 64 Symbole. Summa summarum sind das 29568 Symbole. Also 29568 Netto-Mausklicks. Und dann ist da noch gar nicht eingerechnet, dass ich mich recht oft verklickt oder verlesen habe, und einige Seiten im Buch von so schlechter Druckqualität sind, dass man praktisch nur noch raten kann, was da steht. Zum Glück gibt es eine Methode um zu validieren, ob die Eingabe stimmt, sonst wär die Fehlerquote einfach zu hoch. Und ja, es hat einige Tage gedauert, aber am Ende war ich mit allem fertig. Somit kann ich nun stolz behaupten, dass das Remake nicht nur sämtliche Koordinatenangaben akkurat wiederverwendet, die im Sternenatlas abgedruckt sind, sondern auch alle Powerups in die Levelkarten einbindet, so wie es im Originalspiel war.

Und wann wird SPACOLA ECLIPSE endlich fertig … oder wenigstens mal spielbar? Tja, keine Ahnung. „When it’s done“ ist ja mittlerweile ein geflügeltes Wort in der Spielebranche, das immer wieder gerne gewählt wird und auch sehr gut passt. Ich weiß nicht wann es fertig wird. Aber ich weiß, dass ich weitermache. Und so langsam fügen sich die vielen kleinen Puzzleteile immerhin zu einem erkennbaren Bild zusammen. Vielleicht dauert es gar nicht mehr so lange, bis das erste komplett spielbare Level veröffentlicht wird.

Monatelang gab es zu meinem Hobbyprojekt SPACOLA Eclipse keine Neuigkeiten. Hauptsächlich deshalb, weil ich lange Zeit nicht mehr daran gearbeitet habe. Nun möchte ich einen winzigen Statusbericht abliefern, der zeigen soll, dass ich im neuen Jahr nicht gänzlich untätig war. Die wichtigste Frage, die es vorab zu beantworten gilt: Gibt es spielrelevante neue Features? Nein, leider nicht. Okay, was habe ich sonst gemacht? Viele neue Artworks entworfen, den kompletten Audiocode modularisiert (einfach austauschbar gemacht), viele Grafiken angepasst, neue Sounds hinzugefügt, ein automatisches Build-Script gebaut, einige spürbare Vereinfachungen unter der Haube, einige hartkodierte Stellen dynamischer gestaltet, solchen Kram eben. Mein Code-Metrics-Plugin zeigt mir, dass ich die 10.000 Zeilen jetzt mehr oder weniger voll habe.

spacolatextedit

Die sichtbarste Änderung wird sein, dass ich zusätzlich zu den bisherigen beiden Schriftarten nun auch einen echten GEM-Font in das Projekt eingefügt habe, den man im Spiel jetzt verwenden kann. Um die neue Funktion zu demonstrieren, habe ich in relativ kurzer Zeit einen kleinen Texteditor gebaut, der den üblichen Editoren auf dem Atari ST nachempfunden ist. Als Bonus gibt der kleine GEM-Texteditor denselben witzigen Click-Sound wie beim guten alten ST von sich, wenn eine Taste gedrückt wird. Und wenn der Click schon dabei ist, dann darf der System Beep-Sound („Bing!“) nicht fehlen, (also CHR$(7), falls sich jemand damit auskennt), wenn man z.B. schon am Textanfang ist, und Backspace drückt. War interessant zu sehen, mit wie wenig Code man grundlegende Textverarbeitungsfunktionen wie Cursorpositionierung, Backspace, Zeilenwechsel etc. hinbekommt, damit es halbwegs gut funktioniert. Aus Spaß an der Freude hab ich den Texteditor dann gleich als Tool ins Spiel eingebaut. Möglicherweise kann man damit später einmal in Echtzeit Levelscripte oder sowas editieren, und das dann sogar auf grafisch authentische Weise.

Für die neuen Artworks habe ich viele neue Schriften generiert, die ich aus dem Spacola Sternenatlas mit hoher DPI eingescannt und in stundenlanger Arbeit pixelgenau rekonstruiert habe. Darauf aufbauend habe ich dann einige neue Designs für mögliche Schriftzüge gebastelt, obwohl da noch viel Platz für Verbesserungen ist. Wo ich dann schonmal dabei war, habe ich gleich das komplette Cover des Sternenatlas mit GIMP digital in hoher Auflösung rekonstruiert. Jede Schrift habe ich möglichst detailgetreu nachgebildet und mich an alle Abstände, Positionen und Größen gehalten. So habe ich jetzt praktisch eine perfekte Vorlage für ein Buch- und Disketten-Cover, sogar bereits mit Rücksicht auf Modifikationen bezüglich des Remakes.

Spacola_Disks1Übrigens fand ich inzwischen meine beiden Spacola-Disketten für den Atari ST in einer Plastiktüte, mit abgegriffenem, vergilbtem Etikett. Eine der Disketten hatte ich leider vor Jahren mit einem Kugelschreiber beschriftet, was mich heute ein wenig ärgert. Zum Glück konnte ich das Label der Diskette nach dem Scannen relativ gut retouchieren, aber der Makel am Original bleibt. Nunja, die vielgenutzten Datenträger waren Mitte der 90er von meinem Diskettenlaufwerk schon nicht mehr 100% lesbar, heute – bald 20 Jahre später – wird darauf sicher nichts mehr zu finden sein.

Daneben tauchte auch mein eigener alter Spacola Sternenatlas in einem verstaubten Karton auf. Den jahrelangen Gebrauch in Kinderhänden sah man dem Buch deutlich an. Ich gab mein Allermöglichstes, den Einband mit etwas angefeuchteten Tüchern von kleinsten Kritzeleien, vom Gilb und sonstigem Schmutz zu reinigen, ohne noch mehr Schaden zu verursachen. Außerdem musste ich dutzende kleinerer und größerer Eselsohren von Hand aus den Seiten entknicken, und das Buch gegenüber der Falz seitdem mit Gewichten beschweren, in der Hoffnung, dass sich die neue Form festigt. Inzwischen sieht es deutlich sauberer, wenn auch längst nicht mehr alpinaweiß aus, aber es ist vorzeigbar geworden. Zur Demonstration eignen sich meine beiden hinzugekauften Atlanten freilich sehr viel besser, denn diese sind in einem absolut makellosen Zustand.

Zum Abschluss bleibt mir nur zu sagen, dass ich wirklich die Hoffnung habe, diese neugewonnene Begeisterung für mein Spieleprojekt über das Jahr aufrechterhalten zu können und dass ich schon bald neue Features vorzeigen kann. Mein Ziel ist es, diesmal am Ball zu bleiben und regelmäßig kleine Neuerungen zu implementieren, ohne dass mal wieder alles monatelang auf Eis liegt. Schließlich würde ich gerne Ende des Jahres eine spielbare Version anbieten können, aber warten wir es mal ab.