SoR-GTs

In letzter Zeit hab ich hier nicht wirklich viel geschrieben, aber dafür hab ich die Zeit anderweitig genutzt. Ich habe endlich wieder an Valkyrie Profile gearbeitet, und dabei gute Fortschritte erzielen können. Der ganze Code wurde jetzt überarbeitet - schneller und besser zu verwalten. Dazu kommen noch neue Codeteile und viele alte sind völlig neu gemacht worden. Und deshalb …

… 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?

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.

Ich denke jeder kennt das Problem der Speicherlecks (”Memory Leaks”). Sie gehören zu den Fehlern, die sich am schwersten von allen finden lassen, da sie ja eigentlich gar keine Fehler im eigentlichen Sinne sind. Neulich bin ich auf ein sehr praktisches Programm gestoßen, das einem genau bei dieser Art Fehlern helfen kann. Es heißt Deleaker, und es tut genau das - es sucht und (wenn denn welche da sind) findet Speicherlecks! Aber zunächst eine kleine Erinnerung, was Speicherlecks denn überhaupt sind, wie sie entstehen, und warum sie so schlecht sind.

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.