Sind wir nicht bald fertig? Eigentlich hätte das ein kurzes Intermezzo für zwischendurch werden sollen und kein Marathon. Tja, selbst schuld, wenn man sich solche verrückten Projekte aussucht! 😛
Wo waren wir stehengeblieben? Ach ja, wir wollten einen Deutschpatch für Pokémon Picross erstellen. Nachdem wir die Texte bereits erledigt haben, müssen wir jetzt „nur noch“ die Grafiken im Spiel modifizieren. Das klingt leichter als es ist, denn leider gibt es dafür keinen einheitlichen Prozess. Und ihr dachtet, beim letzten Mal war es abgefahren? Heute setzen wir nochmal einen drauf! 😛
Vielleicht die gute Nachricht zuerst: Ein paar der Grafiken können über unseren Buildprozess, mit welchem wir auch die Texte modifiziert haben, in das Spiel eingepflegt werden. Das trifft letztendlich auf alle im Ordner „graphics“ befindlichen PNG-Dateien zu:
So wird aus der „PAR TIME“ mit etwas Pixelei…
…und einem anschließend weiteren Buildvorgang schnell die „PAR ZEIT“:
Wir drehen die Uhr mal ein paar Stunden weiter und tun so, als hätte ich bereits alle Grafiken, die sich über diesen „einfachen Weg“ (das Setzen von einzelnen Pixeln zur Modifizierung einer Grafik ist noch vergleichsweise leicht zu dem, was noch kommt) umbauen lassen, abgeändert. Doch leider gibt es noch einige Stellen im Spiel, in denen die englische Sprache noch zu finden ist. Ein guter Beweis ist z.B. das Hauptmenü:
Diese Grafiken können leider nicht so einfach verändert werden. Das liegt daran, dass sie nicht im „Klartext“ (bzw. in binärer Form) innerhalb der ROM-Datei vorliegen, sondern komprimiert gespeichert sind. Um Platz zu sparen, wurden früher häufiger die Grafiken in Game Boy Spielen mit proprietären Algorithmen komprimiert. Mit dem Tool „YY-CHR“, welches ROM-Dateien nativ öffnen und deren Inhalt visualisieren (und sogar verändern) kann, lässt sich das gut zeigen:
Für uns ist die Komprimierung ein Problem, denn wenn man den entsprechenden Algorithmus nicht kennt, fällt es schwer, diese Grafiken zu extrahieren, bzw. neue Grafiken zu komprimieren, um sie dann im Spiel zu verpflanzen. Doch auch hier hat der Hackersteller der englischen Version vorgesorgt und zumindest die wichtigsten komprimierten Grafiken dekomprimiert. Sie liegen als PNG-Dateien im Ordner „compressed“:
Beim Buildvorgang werden diese Dateien dann in Binärdaten umgewandelt und vom Komprimierungsalgorithmus zusammengepackt. Klingt gut, oder? Mit einem Grafikprogramm können wir so z.B. das Hauptmenü nach unserem Gusto bearbeiten. So richtig einfach und vor allem schnell geht das aber trotzdem nicht, denn obwohl die Grafiken schon entkomprimiert sind, liegen sie in den meisten Fällen nicht zusammenhängend, sondern nur als „zerschnipselte“ acht mal acht Pixel kleine Grafikblöcke (genannt „Tiles“) vor.
Not so fun Fact: Ich habe einen Blick auf den Komprimierungsalgorithmus, welcher aus der PNG-Datei eine binäre Version der Grafik macht und diese anschließend in ein für das Spiel verständliches Format zusammenpackt, geworfen – glaubt mir, das wollt ihr nicht sehen! 😀
Über die Art und Weise, wie der Game Boy aus einzelnen Tiles Grafiken erzeugt, könnte man ganze Abhandlungen schreiben, darum fasse ich mich möglichst kurz. Letztendlich sind diese Tiles nur eine Art „zerschnittenes Malbuch“, aus welchem sich der Game Boy dann mit Hilfe einer „Tilemap“ (beschreibt die Anordnung der einzelnen Tiles auf dem Bildschirm) sowie einer „Palette“ (gibt die Farben vor, wie die Pixel einer Tile koloriert werden sollen) eine vierfarbige, zusammenhängende Pixelgrafik erzeugt. Man kann es sich wie einzelne, weiße Puzzlestücke vorstellen, die nach Belieben zusammengebaut und erst dann nach dem Prinzip „Malen nach Zahlen“ mit Farbe versehen werden.
Fun Fact: Ein Vorteil dieser Tiles ist, dass sie im Vergleich zu ganzen Grafiken schneller geladen und immer wieder (in unterschiedlichster Kombination) verwendet werden können. Dadurch spart man einiges an Speicherplatz. Ebenso ist die Modifizierung von einzelnen Pixeln deutlich rechenintensiver als das Verändern ganzer Tiles. Der Game Boy spart sich durch die Verwendung von Tiles also auch noch etwas Prozessorzeit, wodurch ein Spiel schneller läuft und die zur Verfügung stehende Rechenpower dann z.B. zur Ausgabe von Sound (Steuerung des Soundchips) verwendet werden kann.
So viel zur Theorie. Und was bedeutet das jetzt für unsere Hauptmenü-Grafik? Konkret heißt das, dass hier gar keine Farben gespeichert sind und wir nur das Layout der Grafiken verändern können. Um sich den Prozess etwas leichter zu gestalten, macht es Sinn, einzelne Tiles erst in einer für Menschen verständlichen Form anzuordnen, bevor man sie abändert. Anschließend müssen sie wieder in ihre Ausgangsform innerhalb der Grafik umgebaut werden. Ganz schön aufwändig!
Besonders den Pokédex zu pixeln war sehr viel Arbeit, weil die einzelnen Namen der Taschenmonster nicht etwa aus Text bestehen, sondern der gesamte Dex als einzelne Grafikdatei in das Spiel importiert wird. Immerhin – besser als die einzelnen Tiles händisch zusammensetzen zu müssen! 😀
Und wieder drehen wir die Uhr ein paar Stunden weiter und tun mal so, als hätte ich bereits alle komprimierten Grafiken, die sich über diesen Weg verändern lassen, modifiziert. Beim Testen sind mir dann aber einige Stellen aufgefallen, an denen immer noch englische Texte zu finden sind, wie z.B. hier in einem Untermenü des Pokédex, wenn das Bild eines Pokémons geladen wird:
Wie kann das sein? Nun, im Endeffekt sind das Grafiken, die zwar in der ROM-Datei vorhanden sind, vom Ersteller des englischsprachigen Hacks allerdings nicht zum Austausch vorgesehen wurden. Das kann z.B. dann der Fall sein, wenn sie (auch in der japanischen Version) bereits in englisch waren, oder wenn sie schlicht und einfach vergessen wurden. Trotzdem möchte ich natürlich auch diese Stellen ins Deutsche übersetzen. Hier bleibt uns nichts anderes übrig, als mit Werkzeugen wie z.B. „YY-CHR“ oder dem „Tile Layer Pro“ selbst Hand an die ROM-Datei zu legen,…
…die Position der zu ändernden Tiles mühsam herauszusuchen und dann durch Veränderungen einzelner Pixel die Buchstaben anzupassen. Einfacher gesagt, als getan, denn einerseits sind ein paar dieser Grafiken extrem zerschnipselt und andererseits kommen sie zu allem Überfluss auch mehrfach innerhalb der ROM vor (um z.B. verschiedene Grafikmodi für Game Boy, Game Boy Color oder Super Game Boy zu unterstützen) und so müssen wir diese kryptischen Änderungen gleich an mehreren Stellen durchführen.
Fun Fact: Ich habe euch im Bild die Stelle, an der wir die Worte „NOW LOADING“ durch „LADEN“ ersetzen müssen mal rot markiert. Vielleicht könnt ihr euch so vorstellen, wie schwierig es ist, die Buchstaben zu bearbeiten, wenn man nur jeweils 8 x 8 Pixel große Bereiche sieht! 😀
Puh – was für ein Aufwand! Und das alles nur, um ein paar Buchstaben zu ändern. Immerhin hat es funktioniert:
Not so fun Fact: Natürlich gab es noch zig weitere Stellen, an denen händisch in der ROM-Datei herum gepixelt werden musste. Keine Angst, ich erspare euch die Details! ^^
Aber jetzt haben wir doch sicherlich alle Stellen, an denen noch etwas übersetzt werden muss, erwischt oder? Tja, leider nicht, denn nun kommen wir zum absoluten „Endgegner“ was Grafiken in unserer Pokémon Picross ROM-Datei angeht. Ein Beispiel dafür ist einer der ersten Screens im Spiel, in welchem man einen Spielstand auswählt:
Die hier gezeigten englischen Wörter finden sich auf den ersten Blick weder im Buildprozess (als Text, Grafik oder gepackte Grafik), noch innerhalb der ROM-Datei wieder. Konkret heißt das, dass es sich auch hier um komprimierte Grafiken handeln muss. Da der Ersteller der englischen Übersetzung sie nicht für den Austausch vorgesehen hat, ist auch nicht klar, wo sich diese Grafiken in der ROM befinden. Das ist schlecht, denn aus Sicht eines „Außenstehenden“ (also uns) wirkt so eine ROM wie ein riesiger binärer Blob ohne klar erkenntliche Struktur:
Und selbst, wenn wir es irgendwie schaffen würden, die Grafiken aus der ROM zu exportieren (und zu dekomprimieren) ist nicht sichergestellt, dass wir sie nach Veränderung wieder importieren können, da der vom Ersteller des englischen Hacks programmierte Komprimierungsalgorithmus leider etwas von der originalen Komprimierung abweicht. Im dümmsten Fall zerschießt man sich so eine im ROM hinter der Grafik liegende Stelle, wodurch man das Spiel letztendlich komplett schrottet. Woher ich das weiß? Ich habe einige Zeit mit dem Versuch verbracht, genau das zu tun! 😛
Und jetzt? Nach mehreren Stunden ohne Ergebnis habe ich mich nochmal auf die Suche nach Informationen zu dem Spiel in die Untiefen des Internets begeben. Dabei bin ich auf eine Disassemblierung der originalen ROM-Datei gestoßen. Hier haben sich ein paar sehr fähige Entwickler die Mühe gemacht, die originale ROM komplett zu zerpflücken und sämtliche Assets zu exportieren. Konkret heißt das, dass wir Zugriff auf den Assembler-Code sowie nahezu alle Grafiken haben und damit theoretisch sogar selbst die originale ROM-Datei nachbauen können.
Das hört sich gut an. Vielleicht können wir über diesen Weg die paar letzten, englischen Grafiken anpassen und uns dann mit Hilfe des disassemblierten Codes eine komplette ROM-Datei bauen. Damit das klappt, brauchen wir erst mal eine Linux-Umgebung. Puh, es ist ja nicht so, als hätte ich schon zig verschiedene Programme unter Windows im Einsatz, aber das Projekt ist eh schon so krass ausgeufert, da kommt es auf das zusätzliche Linux-System nun auch nicht mehr drauf an! 😀
Fun Fact: Schon klar – theoretisch müsste man das auch unter Windows zum Laufen bekommen, aber wenn ich ehrlich bin, habe ich keine Lust, die ganzen Anweisungen und Parameter (z.B. MAKE-Datei) entsprechend umzubauen. Irgendwann ist die Geduld einfach am Ende! xD
Linux Mint kommt uns in der VirtualBox zu Hilfe. In bester Linux-Manier mussten auch hier etliche Bibliotheken (z.B. rbgds oder superfamiconv) heruntergeladen und installiert, Berechtigungen vergeben und Dateien angepasst werden, bevor irgendwas funktioniert hat, aber schlussendlich können wir jetzt die ROM-Datei von Grund auf neu zusammenbauen,…
…sodass sie in einem Emulator läuft. Echt geil! 🙂
Das ermöglicht es uns, die Grafiken im Verzeichnis „gfx“ anzupassen. Leider gibt es auch hier noch einige richtig fiese Fallen, in die man tappen kann. Für ein paar der Grafiken benötigen wir z.B. ein Programm, welches mit graustufigen Bitmaps (2 Bits pro Pixel) umgehen kann. Das in Artikel 334 verwendete Usenti kann das leider nicht und so greifen wir auf „GIMP“ zurück.
Und selbst das Speichern einer geänderten PNG-Datei (nachdem man stundenlang irgendwelche Pixel verschoben hat) birgt dann noch ungeahnte Risiken. So muss man penibel darauf achten, sämtliche Korrekturparameter sowie die Kompression komplett zu deaktivieren, ansonsten kann die Grafik später vom proprietären Komprimierungsalgorithmus nicht gepackt werden, ist zu groß und zerstört damit andere Stellen innerhalb unserer ROM-Datei. Was für ein Mist. Ich habe das nur durch Herumprobieren herausgefunden! xD Was lernen wir daraus? PNG ist eben nicht gleich PNG! 😉
Kann mir mal jemand sagen, was wir eigentlich tun wollten? Stimmt – den Spielstandbildschirm übersetzen, da war ja was. Gut, dass das endlich erledigt ist! 🙂
Zum letzten Mal drehen wir die Uhr für heute etwas weiter und tun so, als hätte ich alle noch nicht übersetzten komprimierten Grafiken identifiziert, ausgebessert und daraus in der Linux-VM eine neue ROM-Datei erstellt. Also sind wir fertig? Nicht ganz, denn es gibt noch zwei Grafiken im Spiel, die wir anpassen müssen: Die beiden mit „BACK“ und „NEXT“ beschrifteten Pfeile, die auf dem Karten-Übersichtsbildschirm zu sehen sind:
Ich habe es ums Verrecken nicht geschafft, die Grafiken über den Buildprozess oder die Assemblierung auf der Linux-VM zu verändern. So richtig klar ist mir nicht, wo, bzw. wie sich die beiden Mistviecher verstecken. Es hilft alles nichts, wir müssen wohl zur Holzhammer-Methode greifen und mit dem Debugger (samt VRAM-Viewer) des BGB-Emulators durch das Spiel springen. Anhand der Laderoutinen, welche die komprimierten Grafiken entpacken und in den Arbeitsspeicher des Game Boys laden, können wir die Position der Pfeile (samt hexadezimalen Werten als Grafikdaten) im Speicher lokalisieren. Ich weiß – das klingt nicht nur abgefahren, sondern das ist es leider auch. Ich habe zwar ein paar Markierungen eingefügt, aber es würde mich nicht wundern, wenn man das folgende Bild nicht mehr wirklich versteht. Sorry dafür! 🙁
Die gefundenen Stellen müssen wir dann nur noch über eine binäre Suche in der ROM-Datei finden und anpassen. Auch das ist leichter gesagt als getan, denn die einzelnen Tiles sind ja komprimiert und so ist nicht klar, mit welchen Werten man eine Veränderung erzeugen kann. Ich gebe es nur ungern zu, aber im Endeffekt habe ich die entsprechenden Binärwerte nur durch ewiges Herumprobieren rausbekommen. Nicht schön, aber für mehr reicht meine Hirnleistung wohl leider nicht aus! 😀
Fun Fact: Da ich keine kurzen, deutschen Worte für „Next“ und „Back“ gefunden habe, habe ich mich dazu entschieden, den Schriftzug auf den Pfeilen einfach vollständig zu entfernen.
Uff, jetzt sind wir aber endgültig durch, oder? Nun ja… Fast! 😛 Durch unseren „Kampf an drei Fronten“ sind mehrere Dateien mit den unterschiedlichsten Änderungen entstanden:
Irgendwie müssen wir den ganzen Senf jetzt noch zusammen bringen. Wie das geht, erfahren wir beim nächsten Mal. He, was schaut ihr denn so böse? Ich weiß – voll gemein, so kurz vor dem Ziel nochmal einen Break zu machen. Tja, so ist das Leben! 😛
In diesem Sinne – bis die Tage, ciao!