SoR-GTs

In letzter Zeit kam ich in Hinsicht auf meine Projekte leider zu gar nichts. Aber, das hat einen guten Grund!

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.

Inzwischen ist es mir gelungen, die Komprimierungen von Tales of the Abyss zu entschlüsseln. Dabei habe ich mir zu Nutze gemacht, dass scheinbar alle PSX und PS2 Tales-Spiele die selbe Komprimierung verwenden.

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.

Im Grunde kann man sagen, dass einen fortgeschrittenen und einen anfangenden Übersetzer nur eine Sache unterscheidet - das Anwenden und das Nutzen eines Debuggers.

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.

Playstation 2 zählt sicher zu den Systemen, die sich noch am schwersten hacken lassen. Manche Spiele mehr, manche weniger. Bisher habe ich mich erst mit zwei Spielen dieses Systems beschäftigt, aber sie sind ein starker Kontrast.

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.

Zunächst einmal meine Fortschritte bei Lufia 2.

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.