Schlagwort-Archive: GEM

Linux-Support

Palim palim! Der unregelmäßige SPACOLA-Remake Fortschrittsbericht ist da! Och, keine Sorge, viel Fortschritt gibts nicht. Aber es gibt immerhin was zu sehen. In den vergangenen Monaten habe ich weitestgehend unter Linux Mint weiterentwickelt, und leider ging auch ein nicht unwesentlicher Teil der Zeit dafür drauf, Probleme zu beheben, die das Spiel nur unter Linux hatte. Zum Beispiel habe ich es lange Zeit nicht hinbekommen, dass das GUI-Fenster sowohl unter Windows als auch unter Linux immer exakt die gewünschte Größe hat. Wenn es unter Linux gepasst hat, war es unter Windows falsch. Wenn ich es dann für Windows korrigiert habe, war die Linux-Version plötzlich wieder schief. Wenn das programmatische Resizing des Fensters endlich überall funktionierte, ging dafür die Menüleiste nirgends mehr. Habe ich eine Sache repariert, geht eine andere Funktion kaputt. Es war wie bei einem Teppich, bei dem man eine Unebenheit mit dem Fuß ausbessern will, die sich dann nur immer wieder woanders auftut. Da soll mir nochmal einer sagen, Java sei wirklich plattformunabhängig. Swing ist es jedenfalls schonmal nicht. Ich habe viele graue Haare bekommen bis es endlich perfekt war. Die aktuelle Version funktioniert somit einwandfrei unter Windows und Linux.

Neue Artworks

In der Zwischenzeit habe ich viel mit neuen Artworks experimentiert und dabei kräftig mit GIMP gebastelt. Lange Zeit habe ich darüber gegrübelt, wie ich die Titelgrafiken designen soll, so dass sie sehr nahe am Original bleiben, und trotzdem viel Spielraum für eine Neuinterpretation im Sinne des Remakes erlauben. Mittlerweile habe ich ein mehr oder weniger einheitliches Design für den Fensterhintergrund, für den About-Dialog, für die Webseite und für den Splash-Screen beim Laden entworfen. Ja, das Remake hat jetzt einen eigenen Ladebildschirm, weil das Starten auf manchen Systemen doch schon mal die eine oder andere Sekunde länger dauern kann. Die Grafiken sind natürlich bei weitem nicht perfekt, aber ich glaube, man kann das erstmal so stehen lassen. Der Wiedererkennungswert ist schonmal ganz ordentlich.

Spiel laden und speichern

Die Funktionen zum Laden und Speichern der Spielstände sind jetzt endlich fertig. Genau wie im Original kann der Kaffee-Button genutzt werden, um den aktuellen Spielstand zu speichern. Zusätzlich gibt es außerdem die Möglichkeit, beliebig viele weitere Spielstände zu speichern und auch via Dateiauswahl wieder zu laden. Im Moment bezieht sich das Speichern jedoch nur auf den Zustand zwischen den Levels, nicht direkt IM Spiel. Ob eine solche Funktion noch nachgereicht wird, und ob das jemandem viel hilft, muss ich noch klären. Jedenfalls ist es klasse, dass man nun tatsächlich den Spielfortschritt in eine Datei persistieren und so jederzeit fortsetzen kann. Damit wäre ein wichtiger Punkt von meiner Todo-Liste gestrichen.

GEM-Schriftarten und Highscore-Liste

Die Remake-GUI verwendet jetzt konsequent drei verschiedene Original-TOS/GEM-Systemschriftarten, um so zusätzlichen Wiedererkennungswert zu generieren. Die Atari ST-Schriftarten erkennen Fans sofort. Nicht dass diese Schriftarten besonders hübsch oder gut lesbar wären, aber sie geben einem echten Nostalgiker doch schnell ein warmes Gefühl. Die Highscore-Liste wurde von mir deutlich erweitert. Zusätzlich wird nun der Highscore-Zeitstempel gespeichert, außerdem die Komplettierungsrate des Spiels in Prozent, damit man die Angaben besser vergleichen kann. Außerdem werden jetzt beliebig viele Einträge gespeichert. Im gerenderten Spiel selbst tauchen dann allerdings nur die ersten zehn Einträge auf, und dann auch nur deren Namen und Punktestand – die übrigen Werte werden einfach versteckt, um so nah beim Original zu bleiben wie möglich.

Post-Processing-Filter dank neuer Rendering-Methode

Besonders wenn man das Spiel auf Pixelverdoppelung stellt, also in der Auflösung 1280×800 spielen will, bremsen etwaige Post-Processing-Filter das Spiel leider so stark aus, dass es kaum noch Spaß machen kann. Zwar gibt es im Moment mit der Invertieren-Funktion nur einen einzigen Filter, aber ich wollte dort in Zukunft noch mehr Filter-Optionen anbieten, um den Look des Spiels den eigenen Bedürfnissen anzupassen. Nun, meine Idee war es, das Post-Processing immer nur auf die gerenderte Spielgrafik (in niedriger Auflösung) anzuwenden, und erst dann das Ergebnis hochzuskalieren. Würde ich erst hochskalieren und dann die Filter auf die hohe Auflösung anwenden, wäre das logischerweise viel langsamer. Leider machte dieser neue Ansatz es nötig, einige Teile des Renderings umzuschreiben, um die neue Reihenfolge der Arbeitsschritte zu ermöglichen. Zusätzlich implementierte ich eine Filterklasse, die es erlaubt, unbegrenzt viele verschiedene Filter ins Bild „einzuhängen“, um die Grafik zur Laufzeit jederzeit zu ändern. Der neue Code funktioniert wirklich erstaunlich schnell und schön flexibel. Die Änderungen haben sich gelohnt.

Neuer Anvisieren-Algorithmus für Geschütze

Man mag es kaum glauben, aber ich habe wirklich übermäßig viel Zeit in den Algorithmus für das Anvisieren der Geschütze investiert. Ich dachte ursprünglich, es genau richtig hinbekommen zu haben. Dann fiel mir jedoch beim Nachspielen des Originals auf, dass die Geschütze beim ST-Klassiker nie daneben feuern, egal wie schnell und egal wohin der Spieler sich bewegt. Das bedeutete, dass die Geschütze nicht nur den Winkel zum Spieler und dessen Bewegungsgeschwindigkeit in die Berechnung des Vektors einbeziehen, sondern bei bekannter eigener Geschossgeschwindigkeit auch den Abschusswinkel exakt so berechnen, dass die Geschosse den Spieler an einem unbekannten Punkt zielsicher treffen. Am Ende habe ich mir das Problem bestimmt ein dutzend Mal auf einem kartesischen Koordinatensystem skizziert und versucht herzuleiten, wie der Winkel berechnet wird. Ich wusste wie lang der Vektor sein dürfte, ich wusste nur nicht, wo er den anderen Vektor schneiden würde. Am Ende fand ich eine Lösung, indem ich den Spielervektor von der Position des Geschützes aus nahm, einen Kreis mit Radius der erlaubten verbleibenden Vektorlänge um diese neue Koordinate berechnete um die Schnittpunkte mit dem anderen Vektor zu finden. Der Vektor vom Geschütz zu diesen Schnittpunkten muss dann der Abschussvektor sein. Das ist dann zwar eine vergleichsweise teure Berechnung, aber sie funktioniert perfekt.

Levelgenerator-Verbesserungen

Den Levelgenerator habe ich wieder geringfügig verbessert. So funktionieren die Floodfilling-Methoden für Konfigurationen von Stationen, Powerups und schwarzen Löchern jetzt besser und erlauben auch die Übertragung von Parametern, wie aus dem Levelskript vorgegeben. Der Levelgenerator setzt nun korrekt die Deploy-Distanz für Gegner, die Deployment-Rate und die Anzahl gleichzeitig erlaubter Gegner. Außerdem habe ich eine Funktion eingebaut, die ich nur als „Shield-Powerup-Stacking“ bezeichnen kann, die mir im Original sehr merkwürdig vorkam. Ich bin mir immer noch nicht sicher, ob das ein Bug ist, oder ob es beabsichtigt war. Jedenfalls kann der Spieler seine Schutzschild-Option zeitlich deutlich verlängern, wenn er mit aktiviertem Schutzschild noch ein weiteres Schild-Powerup einsammelt. Ich müsste wohl auch noch prüfen, ob dieses „Feature“ in jeder Spacola-Version auftritt, oder nur in einer bestimmten. Jedenfalls ist das nun ebenfalls im Remake perfekt nachgebildet.

So, das waren wieder einige kleine Einblicke in die Entwicklung der vergangenen Monate. Ich bleibe am Ball und arbeite mich langsam voran. Der Quellcode umfasst inzwischen über 40.000 Zeilen und wächst stetig weiter.

Eine Besonderheit des Hintzen & Verwohlt -Klassikers „Shocker II – Das Haus der Spiele“ war, dass es hiervon eine hochaufgelöste Farbversion für den Atari TT und Atari Falcon gab, diese bekam ich jedoch mangels passender Hardware nie zu sehen. Einzig in einem Atari-Magazin (vermutlich in einer der letzten Ausgaben des TOS-Magazins anno 1993) war einmal ein Farb-Screenshot abgedruckt. Die ST-Fans kannten bis dahin nur die üblichen Farbspiele in 320×200 Pixeln, die zwar wunderbar bunt, aber dafür oft viel zu grobpixelig waren, um viele kleine Details gut erkennbar darzustellen. Wer ein niedrig aufgelöstes OXYD gesehen hat, weiß wovon ich rede. Mit den höheren Auflösungen des Atari TT und Atari Falcon 030 unter gleichzeitiger Unterstützung für 16 oder mehr Farben änderte sich dies leider erst zum Ende der Atari-Ära hin. Entsprechend wenige Spiele nutzten die erweiterten technischen Möglichkeiten aus – vermutlich auch, weil der TT und Falcon sich im Vergleich zum ST und STE nicht gut verkauften.

Als Fan der hochaufgelösten Monochromgrafik des ST habe ich mich daher immer mit dem STE-Emulator Steem begnügt, der mir viele Funktionen bietet, die andere Emulatoren nicht haben, etwa jederzeit Speicherabbilder erstellen, laden und auslesen zu können, oder die Emulation beliebig langsamer, schneller oder Frame-by-Frame ablaufen zu lassen. Mit dem Steem Debugger kann man den Speicher sogar in Echtzeit modifizieren und den Programmablauf oder Programminhalte verändern. Leider stammt die letzte offizielle Steem-Version aus dem Jahr 2004, also noch aus der Zeit in der ich mein Abitur gemacht habe. Inzwischen wird Steem wenigstens inoffiziell von Fans weiterentwickelt. Doch auf Grund der relativ langen Zeit, die schon vergangen ist, scheint Hatari heute der wesentlich fortgeschrittenere Emulator zu sein. Zumal Hatari längst auch den Atari TT und Atari Falcon emulieren kann, was für mich praktisch ist, um auch Dinge zu sehen, die ich nicht aus eigener Erfahrung kenne.

Seit mehreren Jahren versuchte ich nun, beispielsweise die hochaufgelösten Farbversionen von Shocker II oder Oxyd Magnum in Hatari zu starten, schon alleine um Screenshots für meine Levelgalerien und Spielemuseen anzulegen, doch offenbar hätte ich dazu das Handbuch des Atari Falcon lesen müssen, denn ich hatte keine Ahnung, wie man das Gerät in den hochaufgelösten Bildschirmmodus umschalten konnte. In Hatari lässt sich ganz komfortabel per Mausklick ein VGA-Monitor mit der Auflösung 640×480 „anschließen“, doch das Falcon-TOS bootete trotzdem immer nur in der niedrigen Auflösung. Eine Option für höhere Auflösungen gab es nicht, oder wenn es sie gab, war sie aus irgendeinem Grund ausgegraut. Entsprechend ließen sich auch die Spiele nicht starten, bzw. stürzten direkt mit mehreren Bomben ab. Mehrfach fragte ich bei bekannten Atari-Fans per E-Mail an, ob sie eine Idee hätten, wie man Shocker II starten könnte. Niemand wusste Rat.

Schließlich musste mir Frank, ein weiterer Dongleware-Enthusiast und „Esprit“-Experte, aushelfen, der sich ganz beiläufig bei mir über die Farbversion von Shocker II erkundigte. Dank seiner Anleitung gelang es mir endlich, den Desktop in der hohen Auflösung zu genießen. Wie sich herausstellte, war ich jahrelang auf der falschen Fährte: Ich war auf der Suche nach einer Option für höhere Auflösungen, dabei war die Auflösung eigentlich schon richtig. Ich musste nur noch die Zeilenverdoppelung ausschalten und die Anzahl Spalten von 40 auf 80 erhöhen, also auf genau den Wert, den ich aus dem monochromen GEM kenne. Das sind beides leider äußerst kryptische Optionen für das, was sie bewirken sollten: Horizontale und vertikale Pixelverdoppelung. Daher wurden auf dem Monitor nur 320×200 Pixel dargestellt. Und plötzlich erschienen mir der GEM und sogar Shocker II in ihrer vollen Farbpracht:

shocker2falcon

Danke nochmals an Frank für den genialen Tipp. Jetzt kann ich die wunderbare Welt der Falcon-Programme und -Spiele entdecken und meine Webseite ein wenig mit bunten Screenshots aufhübschen. Es geht natürlich nichts über schön schattierte Monochromgrafik, aber auch aufwändig gepixelte Farbsprites in der VGA-Auflösung haben ihren eigenen Charme, besonders wenn der Grafikstil im Endeffekt derselbe bleibt.

spacolaalpha039

Uff, ganz schön staubig hier auf meiner Webseite. In drei Wochen keinen einzigen Beitrag geschrieben, nicht einmal einen ganz kleinen. Und wer hat Schuld? Die Politik selbstverständlich! Solange in Deutschland der Konsens ist, dass 55 Stunden als Wochenende ausreichen, werde ich immer an Zeitnot leiden. Ich finde, zwischen Freitag und Samstag und zwischen Samstag und Sonntag müsste jeweils ein Entkaterungstag eingefügt werden, denn sonst verbringt man mitunter das halbe Wochenende ungenutzt mit einem Eimer neben dem Bett und hofft, dass sich das Zimmer endlich aufhört zu drehen.

Ich weiß, ich müsste viel mehr daran arbeiten, praktisch den ganzen November habe ich es komplett ruhen lassen. Es gibt endlich wieder Neuigkeiten von meinem kleinen Spaßprojekt SPACOLA Eclipse: Ein paar Stunden meines Wochenendes hat es gekostet, und mit Version 0.39 wird das Spiel endlich multilingual. Nun hat man im Menü die Wahl zwischen Deutsch und Englisch, und die Sprache lässt sich (fast) jederzeit ändern. Die Ingame-Texte werden dabei ausgetauscht und sogar die Swing-GUI ändert sämtliche ihrer Beschriftungen ganz fix per Mausklick. Damit habe ich doch tatsächlich einen der ersten Feature Requests von zwei nicht-deutschsprachigen Dongleware-Fans erfüllt, die die Originaltexte leider kaum verstehen können und sich zumindest eine englische Version gewünscht hatten.

Nun ist es dank vieler kleiner und einiger großer Änderungen sehr leicht möglich, mit einem einfachen Texteditor zusätzliche weitere Übersetzungen für das Spiel zu schreiben, vorausgesetzt jedoch, sie kommen mit dem lateinischen Alphabet aus oder können in dieses überführt werden. Der Dongleware- sowie der GEM-Font, der in meinem Remake verwendet wird, kennt leider nur diese Zeichen. Viele weitere Stunden Pixelei in GIMP wären nötig, um weitere Buchstaben hinzuzufügen, was ich mir vorerst sparen möchte. Wer will, darf sich diese Arbeit natürlich gerne auch selbst machen. Freiwillige vor, die Rohmaterialien zum Basteln gibts auf Anfrage.

Es gibt jetzt ein kleines „Module“-Menü, in dem man vorerst nur den GEM-Texteditor starten kann. Dieser wird neuerdings in der Spiel-Engine ausgeführt und muss nicht mehr umständlich per Debug-Einstellung gestartet werden. Damit lassen sich später einmal zusätzliche Module wie einen Leveleditor, eine Gesamt-Levelkarte oder einen Skript-Editor während des Spiels aufrufen um in Echtzeit Änderungen vorzunehmen. Auch für den geplanten Multiplayer-Modus böte sich hier Platz für interessante Extras.

Wird bald eine downloadbare Testversion veröffentlicht? Noch nicht. Nur Geduld. Leider kann ich hier keinen „Early Access“ anbieten, wie das bei Indie-Spielen ja neuerdings üblich ist, außer jemand bezahlt mich fürs Entwickeln. Oder möchte doch jemand spenden? Bevor es zum ersten Beta-Release kommt, will ich noch den LevelConfig-Parser und den Levelgenerator fertigstellen, die die Originalkonfiguration der Atari ST-Vorlage einlesen und interpretieren können. Wenn das mal steht, werden die Levels endlich nicht mehr vollständig per Zufallsgenerator erstellt, sondern nach den Bauplänen der 64 Ur-Levels. Im Moment bin ich bei knapp 17000 Zeilen bzw. 810 Kbyte Quellcode angelangt, verteilt auf 143 Klassen.

In den kommenden Tagen wird es eine neue Video-Preview geben, die den aktuellen Entwicklungsstand demonstriert. In diesem werde ich auch die vielen kleinen Gameplay-Änderungen zeigen, die ich hier nicht extra erwähnt habe. Der Weihnachtsurlaub ist nicht mehr weit, dann kann ich mich mal wieder mehr um das ganze Thema kümmern.

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.

Als die 90er noch verdammt jung waren (und ich eigentlich auch), da entstand gerade das TOS-Magazin für den Atari ST. Jeden Monat sollte es erscheinen, mit beiliegender Diskette, mit Demos der aktuellsten Programme und Spiele. Am Kiosk lag das Heftchen für schlappe 14,90 DM bereit. Zu dieser Zeit war „Cadaver“ von den Bitmap Brothers gerade brandneu und eines dieser Beilage-Demos. Den ersten paar Ausgaben des Magazins steuerte Meinolf Schneider sechs Gimmicks – also Spaßprogramme – bei, die er eigens dafür programmierte, während er gleichzeitig an OXYD arbeitete. Für jede Ausgabe schrieb er einen kleinen (Modula 2-)Programmierkurs, worin er beschrieb, wie er das entsprechende Gimmick realisierte. Daneben gab es oft sogar den kompletten Quellcode zu bewundern. Mit einem kleinen Rückblick auf seine witzigen TOS-Gimmicks möchte ich hier einem wichtigen Teil meines Lebens ein Denkmal setzen: Der Teil der dafür verantwortlich ist, was ich heute mache.

1. Physical – Schwerkraft für den Mauszeiger
„Physical“ war ein kleines Programm, das den Mauszeiger den Gesetzen der Schwerkraft unterwarf. Einmal gestartet, zog es den Zeiger an den unteren Bildschirmrand und es kostete einige Kraft, ihn wieder nach oben zu ziehen. Insider kannten diesen Effekt aus einigen OXYD-Levels, wo die Kugel sich ebenfalls der Schwerkraft beugte. Mit bestimmten Tasten konnte der Benutzer bei diesem Gimmick außerdem die Schwerkraft etwas modifizieren oder z.B. Schwerelosigkeit simulieren.

2. Django war hier!
Hiermit verlieh Meinolf Schneider dem gelangweilten ST-User wenigstens für einige Augenblicke eine kleine Portion Action. Wer dieses Programm startete, musste den Mauszeiger nur für einige Minuten ruhen lassen. Die nächste Mausbewegung konnte dann allerdings tödlich sein: Der Bildschirm wurde urplötzlich von Django beschossen und krachte dann effektvoll zu Boden. Bei aufgedrehten Boxen garantiert ein Adrenalin-Schock.

3. Fly-Ex – Der Fliegenkiller
Mit diesem kleinen Programm verwandelte sich der Mauszeiger bei einem Rechtsklick in eine Fliegenklatsche. Der passende Störenfried ließ dann auch nicht lange auf sich warten. Mit einem nervenden Surren setzten sich Fliegen auf den Bildschirm und knabberten diesen an. Jede plattgemachte Fliege wurde am oberen Bildschirmrand mitgezählt.

4. Magic – Zauberhafter Desktop
Ein eher bescheidenes Gimmick, das dem Mauszeiger einen gewissen magischen Glanz verpasste, der den Mauszeiger verfolgte. Bei jeder Bewegung der Maus gab es glänzende Sterne zu sehen. Derselbe Effekt wurde im Intro des Macintosh-Emulators „Aladin“ verwendet.

5. Trashy – Der Kobold im Mülleimer
Meines Erachtens das witzigste Gimmick von allen. Der TOS-Papierkorb wurde zum Spielplatz eines verrückten kleinen Kobolds, der entweder durch Klopfen auf sich aufmerksam machte, lachend aus der Tonne blickte oder mit dem ganzen Papierkorb über den Desktop hüpfte. Kaum zu glauben, wieviele Stunden ich mit so einem simplen Accessory Spaß hatte.

6. Snow – TOS-Winterlandschaft für Atarianer
Zuletzt nochmal ein relativ aufwändiges Gimmick, das den gesamten Desktop in den tiefsten Winter verfrachtete. Unser geliebter ST schien plötzlich einzuschneien. Glücklicherweise gab uns Herr Schneider gleich das passende Utensil mit: ein Eiskratzer, mit dem der Desktop mühsam freigekratzt werden musste. Tatsächlich hab ich das Programm damals so lange laufen lassen, bis der Desktop bis oben hin mit Schnee voll war.

Das TOS-Magazin wurde leider schon im Spätsommer 1993 wieder eingestellt. Damals wurde der Atari ST (bzw. seine Nachfolger Atari TT und Atari Falcon) gerade vom Markt gedrängt, während der Amiga noch eisern gegen den immer stärker werdenden PC kämpfte. Klingt wie aus einem spaßigen Film, war aber eigentlich eine traurige Sache.

Ich schätze, ich werde in Zukunft noch weitere Artikel zu dem Thema schreiben.