Wie viele sicher wissen, arbeitet Kaioshin an einer Übersetzung zu Dragon Quest Monsters Caravan Heart für GBA. Die Übersetzung ist schon fertig, und alles andere geht auch gut voran. In absehbarer Zeit sollte auch eine Testversion drin sein!

Ich habe ihm - nicht ganz uneigennützig - in letzter Zeit ein Wenig dabei geholfen (kleinere Sachen), so dass der angepeilte Termin wahrscheinlicher eingehalten werden kann. Freut euch also auf die Übersetzung! Ich kann sagen, dass es dazu allen Grund gibt.

Rauszufinden das zu ändern wird eine schwierige Angelegenheit, ich weiß also leider nicht wie lange es dauert. Aber: Es findet sich garantiert irgendwann etwas. So weit wie ich gekommen bin, da gebe ich nicht hierbei auf.

Und noch etwas erfreuliches, etwas, was mir seit Wochen Sorgen bereitet hat: Es gibt jetzt keine unerklärlichen Abstürze im Spiel mehr! Ich hab es bei meinen Kompressionsroutinen versäumt, am Ende noch ein paar Nullen hinzuzufügen, die das Spiel aber braucht um zu funktionieren. Das ist jetzt allerdings Geschichte! Dazu vielen Dank an Sephiroth 1311 von SadNES cITy, der mir den Code dazu zugänglich gemacht hat.

… können die Übersetzungsarbeiten jetzt anfangen! Nach fast sieben Monaten Arbeit (allerdings mit vieelen Pausen) ist es endlich so weit, dass der Text ins Deutsche übersetzt, oder besser gesagt, lokalisiert werden kann. Es war viel Arbeit, und noch immer funktioniert vieles nicht - darum werde ich mich dann weiterhin kümmern - aber, ich bin unendlich froh, dass sich jetzt endlich etwas tun kann. Denn dann war es die Mühe wert.

Ansonsten habe ich noch andere kleine Sachen erarbeitet. Zum Beispiel, wie man bei den Kampfdialogen neue Textzeilen hinzufügt, oder wie man dort die Fenster vergrößert. Leichter gesagt als getan, muss man da leider sagen.

Wir überlegen in nächster Zeit eventuell einen kleinen Demo-Patch rauszubringen, bei dem z.B. nur der Prolog übersetzt ist. Eine kleine, handfeste Demonstration, dass sich noch etwas tut. Wäre ja gar nicht mal so übel, oder?

Also habe ich Tales of Phantasia dazu verwendet. Es hat ziemlich lange gedauert, was aber - wie nicht selten - an ein paar dummen, vermeidbaren Fehlern lag. Das erste Hindernis bei der Komprimierung war, dass der ASM Code wahnsinnig unübersichtlich und unoptimiert war. Man hätte sicher problemlos etwa 10-20% Code wegkürzen können. Das nächste Problem war, dass das Spiel auf eine Art arbeitet, die ich bisher noch nicht behandelt hatte.

Statt wie die meisten Spiele einfach auf die schon dekomprimierten Daten zuzugreifen, hat es im Hintergrund einen 4kb großen Buffer, der immer auf dem neuesten Stand gehalten wird. Zusätzlich wird dieser Buffer vor dem Start mit einigen Werten initialisiert. Ansonsten war es eigentlich eine ziemlich gewöhnliche LZSS (und RLE) Komprimierung. Es wird immer die Buffer Position angegeben, und das war es dann.

Was mich aber zwei Tage gekostet hat, war ein einziger, winziger Aussetzer. Bei MIPS Assembly gibt es die Anweisung “SLTI rd,rs,imm”. Ausgeschrieben heißt das, “Set Lower Than Immediate destination register, source register, immediate”. Wenn rs kleiner als imm ist, dann wird rd auf 1 gesetzt, ansonsten auf 0. Im Spiel war es die Anweisung “SLTI v0,t1,0100″. Zuerst habe ich es mit “if x > 0×100″ übersetzt, und das war der fatale Fehler.

Denn wenn rs und imm identisch sind, dann wird rd auch auf 0 gesetzt. Dieser kleine Fehler hat mich zwei Tage beschäftigt, aber was soll’s. Es geht inzwischen! Falls jemand interesse an dem Dekompressionscode hat, etwas weil er selber an einem Tales-Spiel arbeiten will, - einfach einen Kommentar schreiben.

Jahrelang habe ich alles durch simples versuchen gemacht, “Was passiert wenn ich das hier ändere?”, und es war teilweise eine frustrierende Zeit. Besonders als es später an die Komprimierungen ging wurde es nur frustrierender. Bei solchen Sachen (und anderen natürlich auch) ist der Debugger des Rom-Hackers bester Freund. Ich kann mir einfach nicht mehr vorstellen, ohne einen Debugger zu arbeiten. Hier einige der Aspekt, die den Debugger so unerlässlich machen:

Das einfachste und zugleich effektivste was ein Debugger zu bieten hat sind Breakpoints. Das heißt, dass das Programm (in diesem Fall das emulierte Spiel) angehalten wird, wenn bestimmte Kriterien getroffen werden. Meistens ist das eines der Folgenden:

• Execute. Die Ausführung wird angehalten, wenn ein bestimmter Codeabschnitt ausgeführt wird
• Write. Es wird dann angehalten, wenn an eine bestimmte Stelle im Speicher geschrieben wird
• Read. Wenn von einer bestimmten Stelle gelesen wird, wird die Ausführung unterbrochen

Fortgeschrittene Debugger haben noch mehr, aber das sind die Grundlegendsten. Alle drei Kriterien sind unerlässlich, und alle drei werden sehr häufig gebraucht. Man nutzt sie etwa, um zu erfahren von wo etwas geladen wird (Read), welcher Codeabschnitt an eine bestimmte Stelle schreibt (Write) oder welchen Wert eine Variable hat, wenn ein Abschnitt durchlaufen wird (Execute).

Und das bringt uns auch gleich zum nächsten Feature. In fast allen Debuggern ist es möglich, den Code Schritt für Schritt auszuführen, und jeweils das Verhalten und die Werte der Register zu beobachten. Dieses Feature ist vital, wenn man zum Beispiel eine Komprimierungsroutine verstehen will, oder einfach wissen möchte, wie das Spiel bestimmte Werte berechnet.

Ein weiteres fortgeschrittenes Feature ist das direkte Bearbeiten des Codes innerhalb des Debuggers. Es gibt einfach keinen besseren Weg etwas zu verstehen, als es gezielt zu zerstören. Wenn man etwas ändert, und das Spiel dadurch sein Verhalten auch ändert, dann hat man eine richtige Stelle gefunden. Das innerhalb des Debuggers zu machen ist unglaublich nützlich, aber bei weitem nicht alle Debugger erlauben es. Zu diesem Feature zählt auch, dass man die Werte der Register frei ändern kann - ebenfalls unglaublich nützlich, nur auf tieferer Ebene.

Wenige Debugger erlauben das ändern des Codes beim Ausführen - aber fast alle erlauben das Loggen (”Tracen”) des Codes in eine Textdatei. Es wird jede ausgeführte Anweisung geschrieben, so dass man schrittweise alles nachvollziehen kann.

Vorausgesetzt, dass man mit dem jeweiligen Assembler-Dialekt vertraut ist, kann man mit Debuggern so unendlich viel erreichen. Man mag es anfangs nicht glauben, aber die Möglichkeiten sind schier unbegrenzt. Ein besonders nennenswerter Debugger ist no$gba, der einen wundervollen Einstieg bietet, und mit zu den besten Debuggern überhaupt zählt.

Auf der einen Seite steht La Pucelle. Ein Spiel aus der beliebten Strategie RPG Reihe von Nippon Ichi. Dieses Spiel ist so ziemlich der Traum jedes Übersetzers. Es hat ein eigenes Dateisystem, aber das einfachste das ich bisher gesehen habe. Sogar Dateinamen hat es! Ein nicht zu verkennender Luxus. Die Texte sind allesamt unkomprimiert, die Grafiken ebenfalls, und insgesamt besteht das Spiel aus nur 150mb Daten. Und sogar noch besser - es funktioniert tadellos mit PCSX2!

Auf der anderen Seite stehen dann Spiele wie Tales of the Abyss. Auf den ersten Blick erscheint es einfach - ein mehr oder weniger bekanntes Dateisystem, Dateinamen, und sogar gut aufgeteilt. Bis hierhin klingt es schön, aber wenn man weiter guckt wendet sich das Blatt.

Dann wird man mit unendlich vielen Sub-Archiven konfrontiert, allesamt namenlos (scheint ein Trend zu sein), mit multiplen Komprimierungen, und einem nicht ganz einfachem RAM-Aufbau. Denn wenn man denkt, dass man einfach in einem SaveState im RAM gucken könnte, wie eine Datei dekomprimiert aussieht, dann wird man herbe enttäuscht. Das Spiel wertet die Dateien umgehend aus und verteilt sie im RAM - während es die original dekomprimierte Datei einfach löscht. An den 10 Kopien der komprimierten Datei scheint es sich jedoch nicht zu stören.

So unterschiedlich können Spiele des selben Systems sein. Dank der sehr guten Emulation von PCSX2 ist vieles einfacher geworden, aber bis der Debugger besser ist (oder überhaupt funktioniert) wird es noch schwer bleiben. Viel gearbeitet wird deshalb nicht an PS2 Spielen, aber was man sieht - das ist vielversprechend! Besonders das Tales of Destiny 2 Projekt von Phantasian Productions lässt einem das Wasser im Munde zusammenlaufen.

Unter einem Speicherleck versteht man, dass man reservierten Speicher dem System nicht wieder zurückgibt, so dass es also nicht weiß, dass der Speicher wieder nutzbar wäre. Das passiert ziemlich schnell, und kostet bei kleineren Sachen auch nicht viel (wobei man es natürlich auf jeden Fall vermeiden sollte), aber bei größeren Sachen kann sowas ein ernst zunehmendes Problem darstellen. Vor allem, da man sowas auch nicht leicht findet. Wäre es ein Runtime Error gäbe es kein Problem, aber da es keiner ist, kriegt man davon überhaupt nichts mit.

Und genau da kommt Deleaker ins Spiel. Das Programm bzw Add-In läuft im Hintergrund und überwacht das Programm. Wenn es dann beendet wird, überprüft Deleaker ob es irgendwelche Speicherlecks gibt, zum Beispiel Speicher der mit malloc() gesichert wurde, oder einfach ein Datei-Handle, und listet es einem praktisch unterteilt auf - und gibt sogar die Stelle an, an dem der Speicher reserviert wurde! Jeder der schon einmal mit solchen Problemen gekämpft hat wird erkennen, was für eine unglaublich nützliche Hilfe Deleaker darstellt!

Man kann es auf zweierlei Weisen nutzen. Einmal als eigenständiges Programm, mit dem man das zu überwachende Programm startet, oder als Visual Studio Plugin. Letzteres ist natürlich sehr viel praktischer, aber beide Arten funktionieren tadellos.
Da Bilder bekanntlich mehr als Worte sagen, hier ein kleines Beispiel. Ich weiß, dass man es so natürlich nie machen würde, aber es soll ja auch nur als Demonstration gelten (draufklicken zum Vergrößern):

Und das ist natürlich nur die einfachste Form eines Speicherlecks. Deleaker findet noch viel mehr. Meiner Meinung ein wirklich geniales Programm, das jeder, der sauber programmieren will nutzen sollte.

Arbeiten wollte ich an diesem Spiel schon lange. Schon als ich es das erste Mal gespielt hatte kam das Verlangen. Aber - ähnlich wie bei Lufia 2 - war es wiedereinmal unmöglich für mich. Ein Jahr später dann hat die Telekom wieder einmal Mist gebaut und ich stand ohne Internet da. Diese Zeit habe ich dann genutzt, um mir Valkyrie Profile noch einmal anzusehen. Zunächst verlief es wieder einmal erfolglos. Nichtmal im SaveState des Emulators ließ sich Text finden. Aus Neugier habe ich dann einmal das gesamte SaveState in einem grafischen Editor durchgescrollt - und ich wurde fündig!

Es zeigte sich, dass das Spiel die Zeichensätze in einem ungewöhnlichen Format speicherte, nämlich nur die Zeichen die auch verwendet wurden. Die Ursprünge davon liegen vermutlich bei der japanischen Version, wo so eine Vorgehensweise viel wertvollen RAM speichern kann. Für englische Spiele ist es dagegen sehr ungewöhnlich und fast schon kontraproduktiv.

Jedenfalls hatte ich so endlich einen Anfang gefunden. Das nächste Problem stellte die Komprimierung des Spiels dar. Besser gesagt, die Komprimierungen. Es gibt zwei verschiedene, aber sie sind relativ ähnlich. Es dauerte ein wenig, aber schließlich könnte ich sie beide umsetzen und so die Daten vom Spiel dekomprimieren.

Aber schon zeigte sich das nächste Problem. Das Dateisystem vom Spiel. Alles was man auf der CD finden konnte waren drei Dateien. Einmal die CNF-Date, die das System zum Starten braucht, einmal die ELF-Datei die den Code enthält, und schließlich eine 700mb große Datei wo der Rest des Spiels enthalten ist. Nun, wo sollte man da anfangen? Ich wusste schon, dass das Spiel diese Datei intern in viele tausend einzelne Dateien unterteilt, aber, wie macht es das?

Es half alles wenig. Aber durch einen glücklichen Zufall bekam ich Kontakt zu einem französischen Rom-Hacker namens Pixel - der einigen sicher ein Begriff sein sollte (Stichwort: Terminus Traduction). Nach einem kleinen Crashkurs in Sachen Verschlüsselungen und kleinen Hilfestellungen konnte ich so dank ihm die Dateien vom Spiel entpacken!

Und das waren nicht grade wenige. Viele tausend Dateien waren es, 4300 Stück. Allesamt natürlich ohne Namen. Ein wenig günstiger Umstand ist das, aber damit muss man nun einmal klar kommen. Die nächste Zeit verbrachte ich also damit diese Dateien zu analysieren, Daten zu finden, Zeichensätze zu analysieren (da das Spiel ja für jeden Text nur die nötigen Zeichen speicherte), Texte zu dumpen, und so weiter. Es gelang mir schließlich sogar, die Daten vom Spiel auch wieder erfolgreich zu komprimieren - ein großer Schritt für mich.

Aber dennoch blieb ein Problem. Die Daten wieder richtig einzufügen blieb umständlich, wegen den Fehlerkorrekturen die so eine CD inne hat. Für C++ gab es dafür Code der einem das abnahm, aber da ich mit Objekt Pascal arbeitete war das keine Wahl. Da ich allerdings schon lange auf C++ umsteigen wollte, fasste ich den Entschluss es nun endlich zu tun.

Es war ein harter Umstieg, und ich musste viel Code portieren, aber schließlich hat es sich gelohnt. Inzwischen kann ich sehr gut mit C++ umgehen, habe allen Code portiert, und auch noch viel mehr geschrieben.

Zu dem was ich inzwischen alles mit dem Spiel anstellen kann zählen:

• Alle Daten dekomprimieren und wieder komprimieren (effektiver als vorher!)
• Alle Arten von Texten dumpen und wieder einfügen und Zeichensätze anpassen
• Grafiken extrahieren

… nach viel sieht das nicht aus, oder? Aber es ist es. Viel Code steckt da drin, und vieles kann man damit anstellen. Doch es steht mir noch viel Arbeite bevor.

Anzumerken ist auch noch, dass die italienische Gruppe SadNES City ebenfalls an diesem Spiel arbeitet, und wir uns gegenseitig gut mit Informationen unterstützen.

Viele schöne Dinge verbinde ich mit dem Spiel, doch auch unschönes, wenn ich beispielsweise an die groteske deutsche Übersetzung denke. Schon seit ich mit Rom-Hacking angefangen habe, hatte ich den Wunsch mehr mit diesem Spiel zu machen. Aber es zeigte sich schnell, dass das Spiel weit über meinem Niveau war, mit seinen multiplen Kompressionen und verworrenem Format. Seitdem sind nunmehr drei Jahre vergangen. Drei lange Jahre, in denen ich mir das nötige Wissen aneignen konnte.

Vor zwei Monaten schließlich fing ich an dieses Wissen anzuwenden. Der wichtigste Schritt war zunächst, die Komprimierung des Spiels herauszufinden. Nach einer kurzen Einarbeitungen in 65816 Assembly ging das dann schließlich, und ich machte erstmals Fortschritte. Ein paar Wochen später gelang es mir dann auch, die Komprimierung soweit umzusetzen, dass ich die Daten auch wieder komprimieren konnte - ebenso effektiv wie sie vorher auch komprimiert waren.

Mit diesem großen Problem aus dem Weg machte ich mich schließlich an andere Dinge. Nach einigem Testen gelang es mir im Laufe der letzten Woche schließlich, das Kartenformat vollständig zu entschlüsseln, und jegliche Karten ins Bitmap Format zu konvertieren. Dazu waren mehrere Schritte nötig, und vermeidbare Fehler haben mich auch viel Zeit gekostet, aber am Ende zählt nur dass es jetzt funktioniert.

Im Moment arbeite ich schließlich an den verschiedenen Events auf der Karte, wozu unter anderem NPCs zählen. Das Format scheint relativ simpel zu sein, mit Glück zeigen sich also schon bald weitere Erfolge.

Alleine arbeite ich allerdings nicht an diesem Spiel. Ein weiterer Verrückter namens Favorite teilt das Interesse an diesem Spiel und arbeitet ebenfalls mit Erfolg an mehreren Formaten vom Spiel - unter anderem das der Monster.

• Eine deutsche Übersetzung für Valkyrie Profile
• Momentan noch recht wenig, allerdings verschiedene Arbeiten an Lufia 2

Der Großteil meiner Zeit fließt dabei in Valkyrie Profile ein (die Playstation Version, nicht die PSP Version). Es ist ein ziemlich schweres Spiel, und braucht auch noch sehr viel Arbeit bis es fertig ist. Im Moment nehme ich allerdings eine kleine Auszeit von Valkyrie Profile, nach vielen Wochen sehnt man sich eine Zeit lang nach etwas anderem.

Und da kommt Lufia 2 ins Spiel. Das gibt es zwar schon auf Deutsch, aber das schlecht als recht und mit vielen fragwürdigen Änderungen. Ob ich eine Übersetzung dazu mache weiß ich noch nicht, aber bisher habe ich schon vieles über das Spiel herausgefunden. Dazu später mehr.

Ansonsten gab es noch einige andere Projekte, aber ich weiß noch nicht, ob ich sie weitermachen soll. Zwei Spiele haben ein Remake auf einer neueren Konsole erhalten, also habe ich noch etwas Zweifel ob es sich auch lohnt. Ich werde aber natürlich davon berichten.