Schlagwort-Archive: Artworks

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.

Der erste Vormittag des ersten Urlaubstages ist schon fast vorbei, da wollte ich die vielen montagmorgendlichen Stunden, denen ich bereits jetzt nachtrauere, nicht gänzlich unproduktiv stehen lassen. Um mal wieder so richtig gepflegt abzuhängen und gar nichts zu tun, war doch eigentlich schon das vergangene Wochenende da. Es ist jetzt an der Zeit, mal wieder einen Gang hochzuschalten und Dinge abzuarbeiten. Mal davon abgesehen, dass ich nach fast einem Jahr nun einen Kleiderschrank bestellt habe (Adios, Umzugskartons!), sowie ein wenig Hardware für mein zukünftiges neues generalüberholtes Homeoffice, habe ich in den letzten Tagen fast jeden Abend zumindest einige wenige Codezeilen in mein kleines Spieleprojekt investiert. Das am wenigsten Uninteressante dürfte die Tatsache sein, dass ich inzwischen sämtliche Artworks des SPACOLA Sternenatlas „restauriert“ habe.

spacolaguide1

Dazu habe ich alle entsprechenden Buchseiten mit relativ hoher Auflösung eingescannt und die Zeichnungen ausgeschnitten. Darunter waren fünf große Illustrationen von Wolfgang Keller aus Karlsruhe (der zusammen mit seiner Frau Gaby Keller bei den diversen OXYD-Spielen unter den Landschaftsgestaltern bzw. Betatestern gelistet wird), als auch zwölf kleinere Abbildungen, die die einzelnen Powerups darstellen. Zusätzlich habe ich 18 Sprites (Gegner etc.) aus dem Buch eingescannt, die aber allesamt direkt im Spiel vorkommen, und daher nicht von mir grafisch bereinigt werden müssen. Mir ist allerdings aufgefallen, dass im Handbuch die Seitenleiste gezeigt wird, wie sie wohl in einer früheren Version des Spiels ausgesehen haben muss: Die Powerup- und Status-Anzeige fehlt hier völlig, die Extraleben werden dafür in doppelte Breite angezeigt. Mein größtes Interesse galt aber den Zeichnungen.

Das Problem waren hauptsächlich das leicht angegilbte Papier, und die Tatsache, dass die Buchseiten beim Scannen deutlich durchscheinen, so konnte man etwa Text spiegelverkehrt lesen, der eigentlich auf der Rückseite steht. Zum Glück bin ich heute nicht mehr ganz hilflos im Umgang mit GIMP. Schlüssel zum Erfolg war der vorsichtige Einsatz des selektiven Gauß’schen Weichzeichners, der unscharfen Maskierung, und zuletzt die Anwendung von Schwellwerten, um alle Farbtöne zwischen Schwarz und Weiß auszuschalten. Das Ergebnis waren einige einwandfreie Schwarzweißgrafiken. Die Tatsache, dass das Bild nun nicht mehr aus Millionen Graustufen und endlos weichen Übergängen bestand, äußerte sich auch extrem deutlich am Platzbedarf der PNG-Datei: Aus 6,42 MByte wurden so 106 KByte. Das sind kaum 2 Prozent der ursprünglichen Dateigröße. Wohlgemerkt ohne die Auflösung zu verringern oder die Qualität zu reduzieren.

spacolaguide2

Selbstverständlich war genau das aber nun der nächste logische Schritt, denn die Auflösung war mit 2700×1700 Pixeln viel zu hoch. Die Vorlage der Originalbilder war meines Erachtens gerade mal 640 Pixel breit, also die übliche ST-Monochrom-Auflösung. Die bereinigten Scans musste ich daher völlig ohne Interpolation (denn sonst wären wieder weiche Übergänge berechnet worden) auf ein Viertel verkleinern. Pixelidentisch würde es so niemals werden, das war mir klar, aber wenn man die rohen Scans zum Vergleich hernimmt, kommen die pixeligen Kanten schon recht nah. Bei den Zeichnungen ist das ganz gut gelungen, bei den Piktogrammen der Powerups leider nicht so gut.

Und wieso der Aufwand überhaupt? Ganz klar: Die Strichzeichnungen, die ich so hervorbringe, will niemand sehen. Ich würde die Bilder gerne auch ins Remake einbringen, zum Beispiel in einer integrierten Hilfedatei bzw. Online-Anleitung. Das Handbuch selbst habe ich ja schon vor Monaten komplett abgeschrieben, weswegen ich auch den Text in modifizierter Form verwenden könnte. Nicht dass ich für irgendwas davon schon die Erlaubnis hätte, aber man weiß ja nie was kommt. Das Cover des Sternenatlas habe ich ebenfalls schon vor Monaten aufwändig digitalisiert und vollständig restauriert, schon allein weil ich nichts von dem (wenigen) Material ungenutzt lassen möchte. Einzelne Schriftzüge kann man hinterher immer noch problemlos ändern.