Dies ist eine Durchsicht der von Imp89/Impression89 entwickelten Software im Bereich Demos und Games. Dabei wird auf die Games/Demos eingegangen und versucht diese zu kontextualisieren. Es zeigt sich dabei die Abhängigkeit von der Hardware gut, da gerade der Bruch vom ATARI ST zum ATARI STE spür- und erlebbar ist (Scrolling, Blitter, Digisound). Dabei zeigen sich schon Trends und Ideen, die später bei Imp89 auf dem Macintosh dann weitergeführt wurde.
Software
Das meiste der im Folgenden besprochen Software befindet sich noch auf Disketten im GameLab. Die Digitalisierung weg von den digitalen 3.25 Zoll ATARI ST Disketten ist heute einigermassen schwierig.
Entweder möchte man sie direkt lesen von einem heutigen Laufwerk (nicht alle Disketten sind in Standardformat leider aber damals wollte man alles aus den Disks rausquetschen also mussten es mehr als 720kb sein) oder man muss sie rüberkopieren auf Flash Files. In Anbetracht der anderen Arbeiten ist dies bis heute nicht passiert mit einigen Ausnahmen. Die meiste Software ist als PRG oder dann auch als Assemblerfile .s erhalten geblieben. Der Assembler ist jeweils auf den Disketten drauf und ist GENST2 alias DevPac2. Mehr dazu hier: https://en.wikipedia.org/wiki/HiSoft_Systems
// ToDo: „Digitalisierung“ der Disketten und Upload
ATARI ST
Zur Entwicklung hier siehe andere BlogEinträge. Kurz zusammengefasst kann man aber den Entwicklungsweg von Imp89 wie folgt beschreiben:
- Atari Basic > Listingspiel
- GFA Basic > leider auch nicht wirklich möglich ein Action-Game zu machen
- STOS (könnte auch 4 sein) leider auch nicht möglich Games zu machen (vgl. dazu https://vintagecomputing.ch/?browseid=8931)
- C > leider auch nicht wirklich möglich State-of-the-Art Games zu machen
- Assembler!
oder als Bild mit Büchern
ATARI ST und Assembler
Die Umgebung sah etwa so aus. Alle Bilder auf einem modernen Display aber an einem Orginal Computer mit den Orginal Disketten von Damals.
Das Kompillieren so:
Oder ganz in Action. Dabei ist klar, anders als heute muss zur Ausführung das OS nicht hochgestartet werden, es läuft direkt in demselben Speicher. Damit war es konkret einfacher, schnell auch etwas kleines zu testen als heute auf Emulatoren!
Im Fall hier sieht man einen Auszug aus dem SourceCode. Gut erkennbar ist, dass hier der Font geladen wird, der später dann verwendet wird für diese Scrollschrift. Wobei es so ausschaut, als würde in 8Pixeln gesprungen beim ScrollText – also kein Shifting oder so (weiches Scrolling). Es ist eher ein Hüpfen an den Bitplanes entlang, was viel einfacher ist.
Die Bitplanes sind auf dem Atari ST 4*2 Bytes. Also sind 16 Farben bei 320×200 auf 4 * 2 bytes verteilt. Je 2X8 Bits. Mehr dazu gibt es in einem anderen BlogEintrag.
Prinzipiell gab es fast kein Knowhow, wie man solche Dinge (wie etwa Games) konkret macht. Und das, das es in Heftchen gab, war schwer Nachvollziehbar, wenn man keine Ahnung hatte. Gutes Beispiel ist folgender Text Die Hexer vom Dienst – Die Magie hinter den Computern https://research.swissdigitization.ch/?p=1981 . Dieser war damals für mich schwer verständlich. Siehe dazu auch Knowhow&Community: Ich (1989), der Lamer (2025) (Imp89/Impression) https://www.gamelab.ch/?p=10709 In diesem Sinn war die Assembler Entwicklung ein langsames Herantasten mit ganz vielen Schnippseln. Ausprobieren und wieder revidieren. Nehmen, was funktioniert und damit irgendwas bauen. Wie gesagt, der Atari ST verfügte über keine Sprites, kein Hardwarescrolling und keine Digitalsound. Alles musste hier selbst gemacht werden. Anders gesagt: Alles war quasi Software. Nur gab es keine bekannten Softwarelibraries für Games. Ein Umfeld, das sich damit auskannte fehlte mir auch vollständig. Siehe dazu auch Einordnung am Ende des Artikels.
Praxis-Probleme
Eines der grössten Probleme, nahm man die Diskette raus und schob eine neue ins Laufwerk, etwa weil man darauf gleich speichern wollte, überschrieb das Betriebssystem einfach das Fat/Inhaltsverzeichnis. Danach war alles zerhackt auf der Disk und musste per Stückchen wieder zusammengesetzt werden. Und ich sei dabei öfters ausgerastet und hätte den Computer verprügelt.
Mein Bruder wollte irgendwann eine Harddisk kaufen (er tat es dann auch) und ich fand das überflüssig. Und er meinte: da kommt aber das Problem mit den Disks auch nicht mehr vor.
„Fundstücke“
Auf den Disks findet man auch noch Texte, die offensichtlich mit dem Assembler Editor geschrieben wurden, denn sie enden mit .s (AssemblerEndung von File)
Atari ST – ohne Nachfolger – fehlende Artefakte
Da der Atari ST ohne wirklichen Nachfolger blieb und es keine wirklichen Austauschformate gab, der sich verbreitete, wurden auch keine dieser Arbeiten aktiv übertragen auf eine neue Generation. Der Homecomputer wurde quasi zur Grabstädte vom Wirken damals. Wäre interessant zu sehen, was passiert wäre, wenn die Homecomputer sich weiterentwickelt hätten. [ Auch in Sachen Spiele, würden wir dann diese alten Games mit neuen Versionen kennen wie es bei den Konsolen die Super Marios etc ? So aber ist fast nichts and Tradierung des Stoffes von Homecomputergames geblieben. leider ]
Hier wäre ein Vergleich mit PC-Entwicklern oder Macintosh-entwicklern interessant. Ist da mehr gelieben?
// ToDo: Vergleich
Disks
In diesem Sinn habe ich die spärlich und teilweise falsch beschrifteten Disks durchgesehen und nach PRGs oder auch .s Dateien gesucht. Und da noch einige Dinge gefunden. Diese sind hier aufgeführt.
Programmierexperimente und Prototypen
Und so finden sich dann mehr als erwaret Experiment oder Prototypen von Demos oder Games. Hier zeigt sich: Man erinnert sich wirklich nur selektiv und gewisse Dinge wurden erstaunlicherweise dann doch gemacht, aber nicht erinnert.
Game: Fülle den Kessel (nicht wiederfindbar)
Das erste (noch erinnerte) Assembler Game war ein Kessel, den man mit Hin- und Herbewegen des Joysticks füllen konnte. Dabei gab es zwei Versionen des Kessels und bei jedem Hin- und Her wurde eine Zeile des vollen Kessels darüber kopiert. Funktionierte damit ähnlich wie alle die Decathlon-likes.
Step-Scroll Demo
Das oben aufgeführte Demo auch nochmals hier.
Einfache Demo mit Titel und Scrolling (?)
Die Demo hat enen Titel. Darunter gibt es eine ziemlich grosse Schrift, die Stufenlos scrollt. Das heisst, dass die Buchstaben tatsächlich durch die Bitplanes geshiftet werden. Dabei ist klar: Auf dem Atari ST macht das alles der 68k-Prozessor, da es gar kein Hardwarscrolling gibt.
Hier vermutlich eine Vorversion dieser Demo. Das zeigt auch, dass man sich langsam der Demo genähert hat: Ohne „Logo“
Seltsame Files, vermutlich zum Testen
Ironischer Text.
Demo: Logo Auflösung
Das Logo von Imp89 löst sich langsam auf.
// ToDo: Screenshot machen
Demo: Raster
Relativ einfach zu machen, waren Wireframegrafiken, da der ATARI ST (anders als der Amiga) ROM Funktionen hatte und da gab es eine Line-Funktion.
Hier scrollt diese Landschaft von Hinten nach vorne. Die Herausforderung hier natürlich, wie macht man das alles ohne Floats. Die 16/32Bitter hatten keine FloatingPointUnits (also wo man Floating Points rechnen konnte). Das musste alles selbst gerechnet oder eher per List/Tabelle simuliert werden. Ähnliches hatte ich damals auch auf einem Mac in Pascal im Gymnasium gemacht in Pascal.
Game: Galaga
Ein Galaga Prototyp. Eine Spiel also das nicht scrollen muss und deswegen gleich einfach realisiebar wäre wie auf dem Amiga. Wobei hier auch die Probleme der Atari ST Programmierung klar werden. Da es keine Sprites gibt, muss viel Management selbst gemacht werden. Die Hintergründe müssen jeweils gelöscht werden, dann das Sprite darauf gerechnet werden. Dies ist hier offensichtlich noch nicht implementiert.
Dennoch wird hier ein GALAGA angekündigt .-)
Finde-Raus-Game
Ein Spiel, das einem Amiga Game nachempfungen war, das ich davor gespielt habe bei meinem Kollegen. Es war alles winzig. Hier ein Spiel, das dasselbe macht. Siehe das Labyrinth links. Eventuell gab es auch eine Vergrösserung rechts. So sieht es zumindestens aus. von dem Spiel gibt noch Bilder. Wie weit es schon funktioniert hat: ToDo
TECTO
Tecto ist ein kleines „Ball-Spiel“. Der Titelscreen ist auch gleich der Menuscreen und der erste Level. All in One.
Dabei ist die Spielmechanik auch beschrieben: „COLLECT ALL SKULLS“. Es geht also in diesem OneScreen-Action-Puzzler darum, die Sculls einzusammeln. anschliesend muss man ins OUT springen und der nächste Level beginnt.
Dabei und das wird im Spiel klar, muss der Ball beschleunigt und abgebremst werden. Es gibt soweit ersichtlich 4-5 Levels. Dabei gibt es auch neue Platten die beschleunigen oder Platten die entstehen.
Das Spiel orientiert sich vermutlich an RockNRoll oder Spielen wie Spindizzy. Mehr dazu hier: Digital Twins in Games der frühen 80/90er Jahren oder Rollende Kugeln [Notiz] https://research.swissdigitization.ch/?p=5972 .
Dabei gibt es Hinsweise auf dei Grösse des Spiels: „TECTO – ANOTHER 10KBYTE GAME“
Credits fürs Testspielen: TESTPLAYING: SIMON ETC
Credits für die Grafik: GRAFIX BY IMP89
Grüsse an einen Kollegen (entwickelte damals ein Tetris auf dem PC): GREETINGS TO PRESOLE
Dank an die Grossen der Spielbranche: THANKS TO FTL BITMAP BROTHERS
Zur Idee – nichts neues: IDEA VERY OLD
Credits fürs Coding: CODING BY IMP89
Spielmechanik: COLLET ALL SKULLS
Motto: CARPE DIEM
Kein Sound: SOUND MR SILENCE
Meta: LIFE IS A STAGE
Abschluss: ENJOY that.
Leider stürzt das Spiel nach dem 4 oder 5 Level dann ab.
// ToDo: Video, BugFix
3D-Demo mit Editor
Die Mega-Demo von RedSector mit dem Helicopter aus Bällen machte 1989 auf sich aufmerksam und ja so etwas zu machen, wäre natürlich auch interessant.
// RedSector-MegaDemo mit den Ball Figuren siehe auch https://youtu.be/L_6dFgGHdNo?si=ePAVdXFUXinVaz4T&t=1044
Da diese Figuren aber in 3D recht komplex sind, entstand ein kleiner Editor zum Erstellen mit Animationsmöglichkeiten.
Anbei sieht man den eingeblendeten Text während der Demo. Hier ist das Modell sehr simpel: Ein Ball.
Der Editor. Hier können Bälle gesetzt, verschoben und animiert werden.
Komplexere Modelle sehen dann so aus in der Animation. Der Editor ist viel zu wenig auf ein Grid-Design ausgerichtet und die Punkte müssen mühsam in Position gebracht werden.
Der Hintergrund in Neochrome
Dabei kam aber auch wiederum nie eine Demo heraus. Wo hätte man sie auch vertreiben sollen? Auf eine BBS hochladen? Demoparties in der Umgebung waren mir nicht bekannt.
ATARI STE 1991+
Irgendwann kauften wir dann auch noch einen Atari STE (mehr dazu hier https://de.wikipedia.org/wiki/Atari_1040_STE). Dieser hatte alles, was dem ST fehlte: Farben, Scrolling, sicher einen Blitter und DigitalSound.
Allerdings war hier der Zug schon lange abgefahren und so entstanden noch einige Demos und Games, die nie veröffentlich wurden. Mehr aber auch nicht.
// ToDo: Wann wurde der Atari STE angeschafft? 92+?
Unbekanntes Game oder Title/Menu zum nachfolgenden ShootEmUp (Atari STE)?
Hier sieht man nun die Szene in Action. Mehrfach scrolling / Parallaxscrolling wie man es aus dieser Zeit kennt. Unklar ist die Palme oder warum das Buch. Warum ein Buch? Sind das auf dem Buch Planeten (auf denen man spielet?)?
Game: Scrolling ShootEmUp (Atari STE)
Ein ShootEmUp-Spiel für den Atari STE. Der Screen scrollt nach oben. Dabei zeigte sich wie einfach dies alles sein konnte, wenn das Ganze einfach von der Hardware „kosten“frei erledgit wurde. Das war ein ganz neues Gefühl und brachte den Atari wieder in die Nähe des Amigas in Sachen Aufwand und Ertrag.
Viele Dinge bliebe allerdings auch gleich, so wurden die Welten weiterhin per Grid erstellt und so ging viel Zeit in das Design von Gridbasierten Welten.
Hier vermutlich die gridbasierten Tiles für das obige Spiel.Dabei sieht man auch hier, wie versucht wird aus verschiedenen Teilen eine Basis für einen Setzkasten zu kreieren, um möglichst variable Welten getalten zu können.
Und weiter auch Gegner
Das rote Gebilde ähnelt stark einem Level in Salamander, wo man das Terrain zerschiessen konnte. Dieses aber gleichzeitig wuchs.
Das Spiel besass einen Leveleditor/Tileeditor. Folgender Level wurde mit dem Tileeditor vor Wochen erstellt.
Das Spiel hatte – in der Erinnerung – aber noch eine falsche Idee von der Konstruktion. Soweit ich mich erinner hatten die Blöcke eine bestimmte Farbe um den Block, mit dem man abfragen konnte, ob man den Hintergrund berührt. Hier wurde die Idee von einer Collision-Detection simuliert. In Echt verwendeten die meisten Spiele einfach RechteckKollisionen.
Die Kollsion Avatar vs Enemies funktioniert denn auch nicht damit.
Coder Alltag: Bomben
Die Fehlermeldungen des Atari ST waren nicht kryptisch, sie waren eine Chiffre. Die Anzahl der Bomben sagte etwas über den Fehler aus. Leider konnten da auch welche dazukommen.
Racer (Atari STE)
Ein einfacher Racer oder eher Top-Down-Jump&Run cross a Demo. Es ähnelt TECTO (und damit auch RockNRoll) ist nun aber per Scrolling spielbar.
Interessanterweise ist das Menu eine Art Demo. Der Ball folgt den Pfeilen.
Bricht man daraus aus, dann geht es gegen oben los. Man muss die „Dioden“ in diesem sehr technischen Setting einsammeln. Das ist technisch alles viel viel einfacher als es früher gewesen wäre, da hier das Scrolling einfach funktioniert.
Sokoban (Atari STE)
Sokoban ist ein Game mit einem Titelscreen, eine Level und digitaler Musik.
Das erste und einzige Level? ist viel zu schnell. Man wuscht einfach mit dem Avatar durch. Das Spiel ist aber prinzipiell spielbar. Allerdings wird auch schnell klar, das alles zwar wie in Sokoban funktioniert. Dass aber die zu besetzenden Felder überschrieben werden visuell. Und es lässt sich vermuten, dass die Mechanik zum erkennen der Felder und damit dem Lösen der Levels noch nicht vorhanden ist.
Dennoch zeigt das Spiel eine gewisse Komplexität und zeigt auch auf, wieviel allein der digitale Sound so ausmacht.
EMT BBS Promotion Demo (ATARI ST, 1993)
Die Reichweite des STs war immer noch das grosse Ding. Darum entstand diese Demo auch als Atari ST Demo, es ging ja um Reichweite.
Einordnung
Abschliessend hier noch eine kleine Einordnung