Schlagwort-Archive: GIMP

spacolaeclipse047

Gestern auf den Tag genau vor fünf Jahren tippte ich die ersten 50 Quellcodezeilen von etwas, das ein paar weiße Pixel auf einem schwarzen Hintergrund bewegte. Heute sind es ziemlich genau 28.500 Zeilen mehr, und es sind leider immer noch weiße Pixel auf schwarzem Hintergrund. So ein Pech aber auch. Nein, heute ist es ein Spiel, das einem originalgetreuen SPACOLA-Remake tatsächlich sehr nahe kommt. Originaltreue ist mir am wichtigsten. Ich verändere nur Details, die mir sinnvoll erscheinen und sich nicht vermeiden lassen. Jede zusätzliche Änderung, jedes weitere witzige Extra wird immer optional sein. Im Moment arbeite ich mich recht fleißig durch die vielen offenen Punkte, und darauf möchte ich in diesem Update-Artikel zu sprechen kommen.

Levelparser/Levelgenerator und Kampagnenmodus

Der Parser für die Levelkonfiguration mit dem Levelgenerator sind weitgehend fertig. Der Parser liest die Original-Levelskripte ein, teilt die Anweisungen im Skript in Tokens und Parameter ein und „interpretiert“ diese, indem er dem Levelgenerator Anweisungen gibt, wie das nächste Level aufgebaut werden muss. Das funktioniert schon perfekt für Level 1. Ab Level 2 aufwärts werden allerdings weitere Befehle eingeführt, die ich erst noch verstehen und vor allem einbauen muss. Damit ist der Kampagnenmodus jetzt theoretisch vorhanden und benutzbar, und wird auch mit jedem weiteren umgesetzten Befehl besser.

Spielen ohne Spacola Sternenatlas

Zwei Änderungen, die nötig sind um das Spiel ohne Buch sinnvoll spielen zu können, habe ich nun umgesetzt. Im Levelauswahl-Bildschirm kann man mit dem Mauszeiger über die Levels fahren und rechts im Statusfenster wird jetzt das darin befindliche erste Sektor-Powerup eingeblendet. Dieses musste man sonst aus dem Buch herauslesen. Ohne das Buch hätte man aber keine Möglichkeit mehr, diese an sich wichtige taktische Entscheidung noch zu treffen, darum hilft das Remake hier nach. Die zweite Änderung, die mir wichtiger ist: Wie soll der Spieler erfahren, wohin es die Waren auszuliefern gilt? Im Jahre 1991 hatte ich dazu das Buch mit der richtigen Seite aufgeschlagen an der oberen Kante unter die Tastatur geklemmt, um die Tabelle immer sofort griffbereit zu haben. Mit dem Finger konnte ich so Zeile und Spalte entlangfahren und schon ging es los. Ohne das Buch muss ich den Zielsektor logischerweise direkt rechts einblenden, was auch der Fall ist. Aber um die Sache spannender zu gestalten, experimentiere ich im Moment damit, dem Spieler den Zielsektor nur zeitverzögert zu verraten, so dass man sich erst noch ein paar Sekunden alleine mit der Spielwelt befassen muss, ehe man sich auf die Reise macht. Derzeit sieht es so aus, dass rechts in der Leiste eine Art „Dekodierung“ angezeigt wird, die nacheinander die X- und Y-Koordinate „entschlüsselt“. Das wäre meine Idee, wie man diesen Aspekt sci-fi-mäßig ohne Buch umsetzen könnte, ohne es noch simpler zu machen.

Alle Powerups fertig

Das „Kantinenruf“-Powerup wurde kürzlich von mir implementiert, und auch das Abfeuern von Lenkraketen funktioniert jetzt einwandfrei. Es sieht sogar schon recht witzig aus, wie die kleinen Lenkraketen zielsicher die Gegnerschiffe verfolgen und alles explodiert. Inzwischen kann ich also stolz vermelden: Alle 12 Original-Powerups sind funktional! Mit der Taste F12 kann man im Spiel neuerdings jederzeit Screenshots abspeichern lassen. War nicht wichtig, aber kam mir irgendwie selbstverständlich vor, dass der Client sowas können sollte. Außerdem merkt der Client sich jetzt endlich alle Einstellungen, die der Spieler vornimmt. So werden etwa Grafikeinstellungen in eine CFG-Datei persistiert und beim Programmstart geladen. Im Cheatmenü gibt es ein neues Untermenü für alle verfügbaren Powerups, die man hier einzeln anwählen kann. Das macht das Testen etwas einfacher.

Richtungspfeil und Testversions-Hinweise

Einen weiteren Cheat habe ich diese Woche verwirklicht: Einen Richtungspfeil am Bildschirmrand ähnlich wie in GTA, der immer den kürzesten Weg zu einem frei wählbaren Spielobjekt anzeigt, also z.B. die Zielstation. Sobald das Objekt sich dann mal tatsächlich auf dem Bildschirm befindet, zeigt der Pfeil auch direkt darauf. Dieser Pfeil wird in der klassischen Kampagne natürlich nicht enthalten sein, da er das Spiel zu sehr vereinfacht, aber ich fand es gut, dass ich sowas mal verfügbar habe für alle Fälle. Analog zu den Spezialhinweisen in der TOS-Demo von SPACOLA habe ich (pixelgenau positioniert versteht sich) auch in mein Remake einige Hinweise bezüglich seiner Unvollständigkeit hinterlegt. Das könnte man als erste Vorbereitung für einen öffentlichen Beta-Release werten, der definitiv in nächster Zeit nötig sein wird, wenn die Entwicklung in diesem Tempo weitergeht.

Präzise Messungen beim Schießverhalten

Das Schießverhalten des Spielerschiffes ist nun sehr viel näher am Original. Durch witzige Messmethoden habe ich versucht, herzuleiten, welche Parameter im Original verwendet werden. Hierzu muss ich Screenshots des Originals anfertigen, und dann die Distanz in Pixeln messen, die die abgefeuerten Schüsse in einer zuvor gezählten Anzahl an Frames zurückgelegt haben. Bei den 72 Hertz, die der Atari ST darstellt (wobei SPACOLA im Gegensatz zu OXYD nur jedes zweite Bild zeichnet, also eigentlich 36 fps), kann ich dann eine Umrechnung in Pixel pro Zeiteinheit als Schussgeschwindigkeit vornehmen, die ich im Remake wiederum verwende, um sie auf die gewählte Zielframerate aufzuteilen. Auch die Schussfrequenz bei Dauerfeuer konnte ich so mit Hilfe von Screenshots messen. Wenn beim Messen dann mal keine ganz krumme Zahl herauskam, wusste ich, dass ich auf der richtigen Spur bin. Die Herumrechnerei führt dazu, dass im Remake endlich deutlich authentischere Werte verwendet werden. Hierbei ist mir auch aufgefallen, dass das Weitschuss-Powerup anders als im Handbuch behauptet, die Schussgeschwindigkeit nicht erhöht, sondern die Kugeln nur weiter fliegen lässt.

Grafikbearbeitung abgeschlossen

In den vergangenen zwei Monaten habe ich die Original-Designvorlagen von SPACOLA wirklich ausgiebig analysiert, in stunden- und tagelanger Fleißarbeit ausgeschnitten, mit meinen eigenen Dateien etwa bezüglich Transparenz, Rotation und Reihenfolge verglichen und dadurch unzählige kleine und große Korrekturen an hunderten von Sprites vornehmen können. Dieser Prozess ist jetzt zu 99,9% abgeschlossen, und damit fallen die teilweise recht lästigen Pixeldoktoreien mit GIMP weg, und ich kann mich endlich vollkommen auf den Code konzentrieren. Mann, das wird ein Spaß. Aber der schwierigste und wichtigste Teil von allen kommt ja erst noch: Die Gegner-Intelligenz so wie im Original hinbekommen.

Richtig, im Dezember hatte ich bereits zwei Beiträge zur Remake-Thematik veröffentlicht, aber ich muss meine kreative Zeit auskosten solange sie noch nachwirkt. Ich bin erstaunlicherweise noch nicht in den Entwicklungs-Winterschlaf gefallen, so wie sonst bei mir durchaus üblich. Im Gegenteil. Der kalte Januar ist noch lange nicht vorbei, und das Changelog für diesen Monat ist bereits das aktivste seit Bestehen des Projekts. Solange meine Motivation weiter ungebrochen ist, wollte ich etwaige Fans daran teilhaben lassen, denn die nächste faule Phase ist so sicher wie das Amen in der Kirche.

Den Schwerpunkt legte ich im Januar auf das Beischleppen von Ressourcendateien, damit ich wenigstens diesen Arbeitsschritt vielleicht irgendwann einmal endgültig abhaken könnte. In den vergangenen Wochen spielte ich daher viel SPACOLA – also die Originalversion. Inzwischen bin ich bei Level 57 von 64 angelangt. Auf dem Weg dorthin kamen hunderte von Screenshots zusammen, die ich mit Hilfe von GIMP bearbeitete. Weit über 120 Sprites sind seit Version 0.39 vom Dezember hinzugekommen, außerdem mindestens acht neue Soundeffekte. Was die Original-Sounds angeht, dürfte ich so ziemlich fertig sein. Viele neue Gegnertypen sind nun im Remake zumindest „enthalten“ (ohne ihre entsprechende KI).

Momentan stehe ich vor einem zusätzlichen Problem. Etwa ein Drittel der Gegner wird im Handbuch des Spiels dokumentiert. Bei einem weiteren Drittel kann ich mir deren Namen aus den internen Dateien des Spiels halbwegs zusammenreimen. Beim letzten Drittel der Gegner habe ich keine Ahnung, wie diese heißen könnten, ich kenne höchstens ihre Anfangsbuchstaben. Hier bin ich nun angelangt, so dass ich jetzt namenlose Spritesets habe, die ich so nicht ins Remake einbauen kann. Überhaupt, wenn ich schon beim Thema Handbuch bin: Ich bin unsicher, nach welchen Kriterien die Entwickler sich entschlossen, Gegner im Handbuch zu erwähnen, und andere wiederum auszulassen. So werden beispielsweise die mit Lenkraketen bewaffneten Cargoliners im Handbuch beschrieben, die sogar erst tief in der zweiten Hälfte des Spiels auftauchen, aber die tödlichen Peashooters (intern: „Pigs“), mit denen man es quasi ab der ersten Spielsekunde zu tun bekommt, werden gar nicht erwähnt. Diese gehören eigentlich zu den frustrierendsten Gegnern im Spiel, da sie sehr gut zielen.

Im letzten Drittel des Spiels bekommt man es mit zwei sehr exotischen „Gegnern“ zu tun: Der Defender, sowie die Kaulquappe aus dem OXYD-Vorgänger Esprit. Als ich noch ein Kind war, hatte ich mit dem hohen Schwierigkeitsgrad wirklich zu kämpfen. Sich den zahlreichen schwerbewaffneten Gegnern zu stellen, hatte oft ein frühes Gameover zur Folge, weshalb ich viele Levels nur bewältigen konnte, indem ich ziellos herumballerte und wie ein Irrer im Affenzahn zum Ausgang flog. Stehenbleiben war keine Option. Sobald ein Gegner auf dem Bildschirm auftauchte, hieß es schießen oder abgeschossen werden, weshalb ich auch keine nähere Bekanntschaft mit dem Defender oder der Kaulquappe machen konnte. Vor kurzem ist mir aufgefallen, dass diese Schiffe dem Spieler gegenüber gar nicht so feindlich auftreten. Der Name des Defenders trifft es ganz gut: Er umkreist den Spieler, und rammt sämtliche Piraten aus dem Weg. Zu Anfang fand ich das ganz nett. Nach einer Weile bemerkte ich aber, dass der Pilot des Defenders vielleicht auf den einen oder anderen Schnaps hätte verzichten sollen: Es kommt zu oft vor, dass er versehentlich den Spieler rammt und zerstört. Absicht oder nicht, sowas nervt ein wenig.

Die Kaulquappe ist jedoch durch und durch ein äußerst nützlicher Helfer. Sie fliegt los, sammelt verlorengegangene Waren ein, und bringt sie dem Spieler zurück. Ich war ziemlich baff als ich dieses Verhalten entdeckte. Dummerweise ist die Kaulquappe ein häufiger Kollateralschaden bei hitzigen Feuergefechten, so dass man auf diesen Vorzug schon sehr früh wieder verzichten muss. Ich schätze das ist Absicht. Was ich nun an SPACOLA extrem schade finde: Obwohl sich die beiden Entwickler des Originals so sehr Gedanken um ihr Spiel gemacht hatten, dass sie sogar hilfreiche Figuren einbauten, wird der Spieler nicht nur im Handbuch darüber völlig im Dunkeln gelassen, er bekommt nicht einmal während des Spiels die Zeit, diese Figuren kennenzulernen. Ich habe SPACOLA mit meinen 7 oder 8 Jahren vielleicht 5 mal durchgespielt, aber erst heute erfahren, dass es nicht nur Feinde im Spiel gibt. Nun, ich habe mit dem Remake jetzt sogar mal die Gelegenheit, ein paar vorsichtige Anpassungen vorzunehmen.

Ein kleines neues Feature, das es im Originalspiel nicht gibt: Mit TAB kann man zur Zeit die Kamera umschalten, so dass man z.B. zwischen eigenem Spielerschiff und Raumstation wechseln kann. Ist eigentlich nur ein Test, um zu sehen, was ich noch alles machen könnte. In die Einspielerkampagne des Hauptspiels wird diese Funktion definitiv keinen Einzug finden, aber im Multiplayer-Modus wird das absolut nötig sein, um seine Mitspieler im Auge zu behalten, bzw. um als Zuschauer nach dem Gameover wenigstens noch einen guten Blick auf das Geschehen zu haben.

Thema Multiplayer: Die ersten Vorbereitungen hierzu habe ich jetzt einfach mal getroffen. Spielen kann man so noch nicht, aber es gibt jetzt zumindest technisch die Möglichkeit, als Server zu hosten und auf Mitspieler zu warten, und die Clients können sich schon übers Netzwerk beim Server anmelden. Sogar entsprechende Performance-Tests habe ich schon durchgeführt, so wird mit dem Anmelden der Clients permanent der Ping gemessen, und einen Timeout-Mechanismus, der verlorengegangene Clients vom Server wirft, gibts auch schon. Ich schätze, in einer der nächsten Versionen werden sich Spieler im Multiplayermodus zumindest gegenseitig sehen können.

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.

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.

Wer mich hier dreist der Schreibfaulheit beschuldigen will, dem sei hiermit Folgendes entgegnet: Ihr habt vollkommen recht! Die Wochen sind leider deutlich zu lang, dafür sind die Wochenenden viel zu kurz. Selbst der extrem kurze Urlaub hat nicht ausgereicht. Alles was ich mir vornehme zu erledigen, bleibt im Moment solange liegen bis es anfängt sich irgendwie von selbst zu erledigen, oder bis darauf Haare wachsen. Aber mein Genöle hilft niemandem, darum hier ein kleiner Füllbeitrag, bis sich meine Finger wieder anfangen in Bewegung zu setzen. Einen Anfang habe ich gemacht: Meine Entwicklungsumgebung ist immerhin seit langem mal wieder offen.

Die freie Grafikbearbeitungs-Suite GIMP ziehe ich jedem Adobe Photoshop vor, schon aus monetären und ideellen Gründen. Aber dass GIMP im Leistungsumfang seinem teuren kommerziellen Vorbild in nichts nachsteht (lassen wir den Profi-Bildbearbeitungsbereich jetzt mal elegant außen vor, in dem sich sicher keine 3% der Bevölkerung bewegen) ist natürlich auch ein überzeugendes Argument, sich mal mit GIMP zu befassen. Ich bin vor langer Zeit umgestiegen und bereue nichts.

Manchmal kommt einem GIMP allerdings recht dramatisch vor. So wie vor einigen Tagen, als ich daran dachte, einige unfertige Werke schließen zu wollen, die ich seit längerem ungespeichert geöffnet hatte. Zum Glück machte GIMP mich noch rechtzeitig mit einer Meldung darauf aufmerksam, dass ich wirklich sehr viel Arbeit in dieses Bild investiert hatte. Wäre doch zu schade um die ganze vergeudete Zeit:

141stunden

Ironischerweise durfte ich heute dafür feststellen, was passiert, wenn man ein (noch nicht gespeichertes) Bild in GIMP geöffnet hat, während man im Windows-Explorer eine Datei mittels „Öffnen mit“ -> „GNU Image Manipulation Program“ laden will: Das bereits offene GIMP beendet sich schlagartig(*), und es öffnet sich sofort ein neues, in dem nur die ausgewählte Datei geladen wird. Das zuvor offene Bild geht dabei leider verloren. Und diesmal ganz ohne dramatische Meldung mit Gelegenheit zum Speichern. Ja, ich hab mich sehr gefreut als alles weg war.

(*) Nachtrag vom 31.05.: Irgendwie konnte ich das erwähnte Verhalten in einem zweiten Versuch nicht mehr nachstellen. Scheint so als hätte ich gestern einfach Pech gehabt und GIMP zum abstürzen gebracht. Wäre auch nicht das erste Mal. Jetzt verhält sich die Funktion genau so wie man es erwarten würde.