Schlagwort-Archive: Public Domain

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.

Ein großes Dankeschön an Gerry, meinem geschätzten Mit-Atarianer und Thalion-Veteranen, der mich gerade noch rechtzeitig auf eine auslaufende Ebay-Auktion aufmerksam gemacht hat. Eine solche Rarität findet man wahrscheinlich nur alle paar Jahre mal, daher musste ich sofort zugreifen. Zu Anfang hoffte ich noch, dass ich schon für 6 Euro den Zuschlag bekäme, aber da habe ich nicht mit den anderen Nostalgikern gerechnet, wegen der ich etwas tiefer in die Tasche greifen musste. Am Ende gelang mir der große Coup mit knapp unter 40 Euro. Ja, viel Geld für alten Kram. Wenig Geld für einen echten Fan. Aber wovon spreche ich überhaupt? Ach, es geht eigentlich nur um den ultimativen Atari ST Public Domain Klassiker: Bolo

bolo_bolowerkstatt

Eine meiner aller-aller-aller-ersten Spieleerfahrungen hängt mit dem Breakout-Klon „Bolo“ von 1987 zusammen. Damals war ich wohl gerade so in der Lage, die Maus zu bewegen ohne dass sie vom Tisch fiel, und die Gefahr bestand bei diesem Spiel durchaus. Bolo – das etwas andere Ball(er)spiel – dürfte man eigentlich kaum Klon nennen, weil es das Original-Spielkonzept um so wahnsinnig viele Elemente erweitert, dass es die Idee auf ein völlig anderes Niveau hebt. Ich kann nicht betonen, wieviele unglaublich spannende (und auch frustrierende) Stunden ich damit erleben durfte. Dieses Spiel hat mich schon sehr früh geprägt, meine Ansprüche und Erwartungen an die Spielewelt entscheidend beeinflusst. Selbstredend hat sich seitdem viel getan, aber ich erwarte auch heute noch, dass eine große Portion Spielwitz eingebracht und viel Liebe zum Detail bei der Entwicklung von Spielen an den Tag gelegt wird, genau so wie das Meinolf Schneider vor etwa 27 Jahren getan hat, als er Bolo im Jahr 1986 zunächst für den auf dem 68000er von Motorola basierenden (wenig bekannten) Gepard Computer entwickelte, und dann für den damals brandneuen Atari ST veröffentlichte.

Die größte Besonderheit von Bolo war die beeindruckende Vielzahl an verschiedensten Steinen, die sehr geniale Physiksimulation, die den Spieler am Schläger den Widerstand beim Anschlagen beinahe spüren ließ, das Gewicht des (unterschiedlich großen) Balles, die dynamische Schwerkraft, die Menge an Levels und die wundervollsten grafischen Effekte, wenn es z.B. explosive Steine in alle Richtungen zerfetzt. Mir fallen nicht genug Superlative ein, um dieses Spiel ausreichend zu würdigen. Über den als Megaghost bezeichneten Antagonisten kann ich leider nicht das Geringste erzählen, denn Bolo war mir leider zu schwer. Wenn man 50 Levels am Stück erfolgreich durchgespielt hat, soll er wohl erscheinen. Einmal hatte ich knapp 20 Levels geschafft. Die klobige Atarimaus, deren Kugel ständig im Gehäuse hängenblieb, hat mir die Schwerstarbeit im Kampf gegen die Schwerkraft kaum abnehmen können.

Als Meinolf Schneider noch für das Label der Application Systems Heidelberg entwickelte, nannte er sich Dr. Mausklick, so wie das auch den Rückseiten der Plastikhüllen zu entnehmen ist. Ich bin begeistert wie gut erhalten die beiden Schachteln sind, sogar der Sticker wurde noch nicht verwendet, und das DIN A2-Poster mit den Levelbildern wurde offenbar auch noch nicht aufgehängt. In der zweiten Schachtel steckt die „Bolo Werkstatt“, also der Leveleditor, einschließlich gedruckter Kurzanleitung. Die Hülle ist dabei exakt dieselbe wie beim Spiel, mit einem zusätzlichen aufgeklebten „Werkstatt“-Schriftzug. Und als wäre das nicht schon toll genug, sind selbst die Preisetiketten noch auf der Packung, die beide Produkte mit 69,00 DM auszeichnen. Dieser fantastische Neuzugang geht direkt in meine virtuelle Vitrine.

Ich nehme mir mal die Freiheit, hier ein kleines Gameplay-Video von YouTube einzufügen, um das Spiel zu demonstrieren. Man sollte allerdings einschränkend dazu erwähnen, dass der Spieler hier nicht allzu talentiert ist. Außerdem zeigt das Video nur äußerst wenig von der Vielfalt, die die Levels bieten können.

[youtube]http://youtu.be/NTG3CAD-s_4[/youtube]

Für das grenzenlose Glück fehlt mir jetzt eigentlich nur noch ein originalverpacktes Esprit für den Atari ST, also dem Vorgänger von OXYD. Falls jemand zufällig darüber stolpert, oder sein eigenes Exemplar für einen guten Preis verkaufen möchte – bitte nicht zögern, E-Mail an mich. Im Idealfall ist noch alles so in der Verpackung wie es verkauft wurde, aber ich nehme auch weniger guterhaltene Spiele. Ich bin mal gespannt, was sich in den kommenden Monaten und Jahren noch so an Gelegenheiten ergeben wird. Vielleicht komme ich ja wirklich noch dazu, einen kleinen Dongleware-Schrein aufzustellen.

Anlässlich des 25-jährigen Jubiläums des bekannten Atari ST-Klassikers Ballerburg (das ich leider ganz knapp verpasst habe), wurde Version 0.25 des SDL-Ports Ballerburg SDL für Linux veröffentlicht. Der Port basiert auf dem Original Lattice-C-Quellcode von Eckhard Kruse, der ihn vor einigen Jahren freigegeben hat. Kruse, der u.a. auch das Musik- und Grafik-Demo „Gruseldemo“ auf dem ST programmiert hat, ist seit 2008 Informatikdozent an der BA Mannheim. Seiner Webseite ist außerdem zu entnehmen, dass er in Heidelberg wohnt, also praktisch nur ein Steinwurf von mir entfernt.

Ballerburg ist damals in der PD-Szene des ST eingeschlagen wie eine Bombe. Es gab kaum einen ST-Benutzer, der dieses kleine aber extrem süchtigmachende Spiel nicht kannte. Auch heute verursacht das Stichwort „Ballerburg“ unter ehemaligen Atarianern leuchtende Augen. Ich selbst habe (zu der Zeit noch in der Grundschule) regelmäßig mit teilweise bis zu vier Schulfreunden komplette Nachmittage gebannt vor dem Schwarzweiß-Monitor verbracht, und eine Burg nach der anderen durch gezielte Kanonenschüsse abgerissen. Aber auch alleine konnte man mit dem Spiel sehr viel Spaß haben, denn schließlich gab es intelligente Computergegner mit solch wohlklingenden Namen wie „Brubbel“ oder „Tölpel“. Kult erlangte das Spiel außerdem für den König, der jeder Burg innewohnte, und den der Spieler in jeder Situation um Rat fragen konnte. Manchmal gab er dem Spieler tatsächlich sinnvolle Tipps, wie die Empfehlung, Fördertürme zu bauen. Oft jedoch kam nur generisches Blabla heraus, das man dann demütig zur Kenntnis nehmen durfte.

1989 erschien noch eine verbesserte Version von Ballerburg, deren sichtbarste Änderung die Einführung von Spieltabellen war, falls man (wie ich) mal in der Situation war, komplette Ballerburg-Turniere ausrichten zu wollen. So hatte man auf einer übersichtlichen Tabelle immer genau im Blick, wer gerade mit den meisten gewonnenen Burgenkämpfen an der Spitze stand. Als ich 12 oder 13 war, habe ich zusammen mit einem Freund die Definitionsdatei für die Ballerburg-Burgen analysiert, da uns (irgendwie) das Taschengeld fehlte um dem Autor die angebrachte Spende von 20 DM zukommen zu lassen – als Dankeschön hätte es einen Burgen-Editor und den Quelltext des Spiels gegeben. Es hat aber nur 2-3 Stunden gedauert bis wir das Speicherformat verstanden hatten, dann konnten wir auf Millimeterpapier unsere eigenen Burgen vorzeichnen und anschließend ins Spiel einfügen.

Eckhard Kruse hat das Spiel innerhalb eines Monats in der 12. Klasse des Gymnasiums geschrieben, im Alter von etwa 17 Jahren, was an sich schon sehr bemerkenswert ist. Der Programmierer hat noch immer eine nennenswerte Fangemeinde. Seit kurzem gibt es sogar für iOS eine Ballerburg-App. Ich bin wahrlich kein Fan von Apple, aber diese Anwendung muss ich erwähnen, weil sie wirklich SEHR nah am Original und scheinbar gut gemacht ist. Ein wenig traurig finde ich allerdings, dass der fleißige iOS-App-Entwickler sich nicht zu schade ist, die Hand dafür aufzuhalten (womit Apple daran noch kräftig mitverdient). Aber so ist eben die Apple-Gefolgschaft: Wenn es nichts kostet, kann es nichts wert sein. Gerade weil das Original nämlich bewusst Public Domain war, finde ich das ein wenig unpassend. Wahrscheinlich mache ich mich mal wieder lächerlich, wenn ich um Gleichberechtigung und eine Android-Umsetzung bitte, meinetwegen mit Werbeeinblendungen, wie das heute gern gemacht wird.

Wo wir bei Umsetzung sind: Ich hätte nix dagegen, wenn jemand die neuen Ballerburg SDL-Sourcen für Windows kompilieren täte. Mir fehlt dafür Werkzeug und Erfahrung.

Das Internet ist eine gigantische Schatzkiste. Das konnte ich in den letzten Jahren bei vielen Gelegenheiten immer wieder feststellen. Dieses Mal konnte ich eine ganz besondere Rarität ergattern, die ich schon seit meiner Kindheit haben will. Noch dazu stellte sich heraus, dass besagte Rarität in einem außergewöhnlich guten Zustand ist, praktisch kaum benutzt. Meine Sammlung wird damit endlich komplett, nach lächerlichen 21 Jahren.

Eigentlich bin ich überhaupt kein Sammler und Raritätenjäger, ich habe gar nicht das Geld oder den Platz, um mir eine entsprechende Sammlung aufzubauen, und so mancher hat sein ganzes Haus voller Spielerelikte, Konsolen, Handhelds, ungeöffneter Originalversionen, Handbücher, alter Homecomputer, und was weiß ich noch alles. Ich bin aber in gewisser Hinsicht etwas ähnliches, nämlich Verfechter der Informationsfreiheit und Informationserhaltung, ganz im speziellen im Bereich alter Spiele bzw. historischer Software, auch für Systeme, die längst nicht mehr existieren. Sehr gerne beschäftige ich mich darunter mit den auf dem Atari ST bekannten Kugel- oder Murmelspielen von Meinolf Schneider (OXYD-Reihe), sowie von Martin Hintzen und Jürgen Verwohlt (Thriller- und Shocker-Reihe). Mit diesen Spielen verbinde ich eine sehr spannende und angenehme Kindheit. Ich war eines von jenen Kindern, die keinen Nintendo hatten, aber dafür alle möglichen Computer – zum Glück, denn mit Computern kann man doch soviel mehr machen als mit Spielekonsolen.

Gerade vor wenigen Tagen führte ich ein einstündiges Telefoninterview mit Martin Hintzen über seine aktive Zeit als Spieleentwickler für den Atari ST. Ich konnte ihm so einige Interna über seine Spiele, und nebenbei so manche interessante Anekdote entlocken. Das ist einer der Gründe, warum ich derzeit wieder in einem richtigen Atari-Fieber bin. Nun ist es mir – wider Erwarten – tatsächlich gelungen, etwas zu erwerben, was inzwischen kaum noch zu bekommen ist: ein Exemplar von „Das Oxyd 2 Buch„. Daneben habe ich mir jeweils ein zusätzliches Exemplar von „Das OXYD-Buch“ und dem „Spacola Sternenatlas“ bestellt, schon alleine weil meine alten Exemplare etwas abgegriffen sind (um es mal harmlos auszudrücken). Die Bücher waren teilweise deutlich teurer als der ursprüngliche Verkaufspreis, aber das konnte mich nicht abhalten, diese seltene Gelegenheit zu nutzen. Jetzt besitze ich alle drei Dongleware-Bücher für den Atari ST. Oh Internet, gelobet und gepreiset seiest du.

Wer die Spiele nicht kennt und sich jetzt fragt, welche interessanten Geschichten in diesen Büchern stehen könnten, den muss ich enttäuschen. Die Bücher bestehen aus zwei Teilen: Zum einen fungieren sie als Handbuch für das jeweilige Spiel, zum anderen bestehen die Bücher zu 90% nur aus Kopierschutzcodes, also seitenweise Kolonnen aus Ziffern und Buchstaben, die man eingeben musste, wenn das Spiel danach fragte. Mehr ist das nicht. Warum also für so einen alten unnützen Krempel soviel Geld ausgeben? Genau. Weil halt. Aus zwei Gründen ist es absolut unsinnig, diese Bücher heute noch zu kaufen: 1. Es gibt gecrackte bzw. kopierschutzfreie Versionen der OXYD-Spiele im Netz. 2. Es gibt Enigma, einen freien OXYD-Klon für alle möglichen modernen Betriebssysteme. So, und auf der anderen Seite trifft das auf Spacola schonmal nicht zu, denn davon gibt es meines Wissens keine gecrackte Version. Wie auch, die „Codeabfrage“ ist derart intelligent mit dem Gameplay verknüpft, dass man sich das Spielen ohne Buch schon rein prinzipiell sparen kann. Zum anderen ist es einfach die Nostalgie an diesen Büchern, die mich reizt. Außerdem haben sie einen gewissen Seltenheitswert, denn die Zielgruppe war relativ klein und entsprechend wenige Exemplare sind jeweils in Umlauf gekommen, vermutlich nur wenige tausend Stück.

Und was mache ich mit meiner Beute nun? Keine Ahnung. Tag und Nacht bewundern. Einscannen und als PDF aufbereiten. Von der Staubschicht befreien, einschweißen und in einer Glasvitrine ausstellen. Wenn ich eine hätte. Wahrscheinlich kommen sie einfach nur ins Regal. So richtig habe ich mir das noch nicht überlegt.