[Anfänger] Rom-Translation - Das absolute Beginner Tutorial

Bevor man lernen kann ein „Rom“ zu übersetzen, muss man erst mal wissen, wie es aufgebaut ist und wie es funktioniert.

Also ein Rom ist ein Abbild einer Cartrige(Modul) eines Spieles. Die Abbilder sind mit RAW Dateien vergleichbar (Abbild einer ganzen CD). In Ihnen ist der gesamte Inhalt des Spiels gespeichert! Er umfasst Programmcode, Grafik, Sound und natürlich den Text. Wichtig ist es zu wissen, dass ein Rom immer von einen Modul stammt. Das Abbild einer CD ( z.B. einer von Sonys Playstation) nennt man Iso! Die Daten die in das Rom kommen, werden also aus der Cartrige ausgelesen. Dafür gab/gibt es beistimmte Geräte, die allesamt wohl nicht ganz legal sind. Diesen Vorgang , beim dem die Cartrige ausgelesen wird nennt man dumpen! Den Begriff des Dumpens werdet ihr später beim Übersetzen wiederfinden, dort allerdings im anderen Zusammenhang. Die ausgelesen Daten werden in ein Roms geschrieben. Allerdings arbeiteten/arbeiten einige dieser Geräte nicht ganz korrekt, was dazu führt, dass mal ein paar Datenstücke vergessen werden. Dann hat das Rom eine schlechte „Checksum“. Einige Emulatoren zeigen das eventuell als Warnung an, weil man davon ausgehen muss, dass das Rom irgendwann, irgendwo abstürzt. Das muss aber nicht der Fall sein. Dennoch sollte man darauf achten, dass man immer ein Rom mit guter, also richtiger, Checksum bekommt. Das wird zwar nicht immer möglich sein, aber wenn schon, denn schon!

Wie schon gesagt, befinden sich im Rom alle Informationen zum Spiel. Grafik, Text, Sound und Code. Alles zusammen, gemischt und für den PC nicht lesbar. Darum wird ja auch der Emulator benötigt! Wenn man also ein Rom übersetzt, sollte man es tunlichst unterlassen irgendetwas irgendwo einzuhacken. Vielleicht passiert nicht, aber man könnte auch den Programmcode ändern und das Roms vielleicht unbrauchbar machen. Darum ein Tipp: „Bevor ihr im Rom arbeitet, immer eine Kopie anlegen, damit ihr es nicht neu saugen müsst“

1. Das Rom, welches ihr übersetzen wollt
2. Einen Table File des Roms. Das wird in Kapitel 5 erläutert!
3. Einen Rom-Editor. Das bedarf einiger Erläuterungen. Dieser Editor ist ein spezieller Hex-Editor. Für diejenigen die nicht wissen was ein Hexeditor ist, werden ich das natürlich erklären. Der Rest kann diesen Abschnitt getrost überspringen.

Ein Computer kann nur mit 0 und 1 umgehen!

Selbst das ist nicht ganz richtig, denn eigentlich heißt es „Strom ein“ (1) und „Strom aus“(0). Der Computer arbeitet also mit 1 und 0. Jeder Chips tut das so, auch der einer Konsole. Nur die Konsole arbeitet halt etwas anders mit den Daten( darum der Emulator)! Dabei rechnet der Chip in bestimmten Paketen von Bits. Jeder kennt das Byte, das sind 8 Bits. Programmierer kennen noch das Word, das sind 16 Bit. Dann gibt es noch Long-Word, das sind 32 Bit! Soweit alles klar, doch was hat das mit Translation zu tun? Im Prinzip nichts, aber es erforderlich um zu wissen, wie der Hex-Editor arbeitet. Wie stellt man nun Buchstaben in einen Computer dar? Klar mit dem Bildschirm! Aber wie sieht es bei den Daten aus? Der Computer kennt ja nur Bits! Nun. Man sagt ihm, das er bei einer bestimmten Bit-Folge ein bestimmten Zeichen ausgeben soll! Um dieses Zeichen zu benennen benötigt man gerade 8Bit, also ein Byte. 8 mal 1 oder 0 reicht aus um 256 Zeichen zu benennen. Das ist genug für das Alphabet, Zahlen, Sonderzeichen. Ein Zeichen könnte so aussehen: 00000001 in Binär. Etwas unübersichtlich, wenn man bedenkt, das man da was hacken soll. Darum hat man statt dem Binären System, ein anderes genommen. Nicht das dezimale, sondern das Hexadezimal. (Darum Hex-Editor). Es beruht auf der Basis von 16 Ziffern ( das Dezimale auf 10 Ziffern, das Binäre auf 2). Diese Ziffern sind: 0,1,2,3,4,5,6,7,8,9,A,B;C,D,E,F Die Zahl 00000001 würde nach dem Hexadezimalen System so aussehen: 01 00000011 à 03, etc. Bis 11111111 à FF Ihr werdet euch mit diesem System anfreunden müssen. Es ist ein Hauptbestandteil beim Rom-Hackung. Aber keine Sorge, ihr werdet kein Umrechnungen anstellen müssen. Wozu nun das ganze, warum hat man nicht das Dezimale System genommen, wäre doch einfacher? Das liegt daran, dass das Hexadezimale System bei einfachen Zeichen nur zwei Ziffern umfasst (z.B. D5) während, das Dezimale System bis 3 Ziffern gehen müsste ( z.B. 129). Mit 8 Bit kann ich ja 256 Möglichkeiten erfassen. 256 = FF !!! Das Hexadezimale System bietet sich also der Übersichtlichkeit her an! Ihr werdet es sehen, wenn ihr einen Hexeditor in Aktion seht! Hier haben wir es zwar schon mit eine Rom-Editor zu tun, aber den könnte man auch als normalen Hex-Editor verwenden. Wir man gut sehen kann, steht auf der linken Seite der sogenannte Hexcode! Wenn man sich hier jetzt 3stellige Zahlen hindenkt, wird man sehen, dass es so übersichtiger ist Genug der Theorie. Der Hexeditor dient also dem verändern der Daten in einer Datei. Jede Datei kann mit ihm geöffnet werden. Wie man nun damit editiert, werdet ihr leicht einsehen können. Man kann entweder die rechten Zeichen( wo später auch der zu übersetzende Text stehen wird) umschreiben, oder den Hexcode editieren. Wie der Text aussieht wird vom Zeichensatz bestimmt.

Jedes Programm beinhaltet irgendwo Text.

Wenn ich den verändern will, muss ich wissen welcher Hexcode (z.B. 65) welchen Buchstaben repräsentiert! Denn theoretisch könnte ich jedem Hex Wert (von 00 bis FF) jedes Beliebige Zeichen zuweisen. Irgendwann in der Geschichte der Computer hat man sich auf den Zeichensatz der Firma IBM geeinigt. Mit diesem Zeichensatz arbeitet heute jeder normale PC. In Ihm repräsentiert z.B. der Hexcode 41 ein A, 42 ein B, etc. Ich kann diesen Zeichensatz auch nicht auswendig, normaler Weise braucht man ihn auch nicht, weil er so standardisiert ist, das sogar das Note Pad von Windows ihn immer anzeigt. Das einzige was man wissen sollte ist, das der Zeichensatze eine Zuordnung darstellt in der festgeschrieben ist, welcher Buchstabe bei welchen Hex-Wert geschrieben werden soll! Z.B 41= A, 42= B, 65= e etc. Auch Sonderzeichen (z.B. Klammern, Satzzeichen) werden hier fest geschrieben. Diesen Standart auf den IBM-kompatiblen PC nennt man ASCII( American Standard Code for Information Intercharge). Was hat aber der ASCII Code mit Rom Translation zu tun? Nun, er gilt im Rom nicht! Darum ist Rom Translation ja schwieriger als das übersetzen eines normalen Windows Programms. Das liegt aber nicht zwingend an der Konsole oder einen anderem Rechner, sondern am Programmierer des Spiels. Die Entwickler der Spiel haben meist einen eigenen Zeichensatz in ihren Spielen verwendet. Warum ist mir nicht ganz klar. Fest steht, das ich den Text im Rom nicht einfach so lesen kann, weil mein Editor den falschen Zeichensatz benutzt. So könnte ein B im Rom, einen ? im ASCII Code entsprechen. So kann ich nicht einsehen was da steht und ich könnte es auch nicht übersetzen. Also haben sich die Pioniere des Rom-Hacking/Translation etwas pfiffiges einfallen lassen: Den Table File.

So sinnvoll dieses „Format“ ist, so einfach ist es auch!

Wie schon oben gesagt, kann ich normalerweise den Text im Rom nicht sehen, weil ein anderer Zeichensatz vorliegt! Also muss ich so eine Art Übersetzung des eigentlichen Zeichensatzes vornehmen. Das ist der Table-File (*.tbl). Der hat natürlich nichts mit der eigentlichen Übersetzung zu tun. Die Table sagt meinen Editor nur welches Zeichen er zu welchen Hex-Wert schreibt. Das ganze sieht dann so aus: 80= A 81= B DF= ? FF= „Leerzeichen“ à hier dürft ihr später beim erstellen der Table nur ein Leerzeichen nach dem“=“ machen! Das ein anderer Zeichensatz verwendet wird ist aber nicht immer der Fall. Es kann gut sein, das ein Spiel mal Teile des ASCII Zeichensatzes verwendet. Z.B Breath of Fire II von Capcom. Dieses Spiel verwendet eben gerade die Zahlen und Buchstaben des ASCII. Andere Zeichen haben aber auch andere Bedeutungen! Viele sind Steuerzeichen, die z.B. das Ende einer Textzeile oder eines Menü Punktes darstellen. Dadurch, das wir teilweise keine Table-File brauchen wird das übersetzen aber nicht viel leichter.. Nur das herausfinden der Table, also des Zeichensatzes des Roms, entfällt. Wie man den heraus bekommt werde ich später etwas erklären, doch zunächst werden wir die Besonderheiten eines Rom-Editors kennen lernen.

Um es kurz zu sagen: Der Romeditor ist ein Normaler Hex-Editor der einige nette Features mitbringt.

Ein Normaler Hexeditor kann nur den ASCII Code anzeigen. Er kann Hex-Code editieren oder ganz normalen Text verändern. Der Rom-Editor ist hier etwas variabler. Er kann einen Table-File verarbeiten, heißt also er überschreibt bei der Anzeige die Zeichen, die im Table File als Hex-Wert gegeben wurde, mit den Zeichen die im Table-File hinter dem „=“ stehen! Beispiel: Im Text: 41 = A Im Rom: 41 = 9
Der Rom-Editor schreibt also an den Hex-Wert 41 kein A sondern eine Neun. Sollte man schon den ganzen Table File haben kann man nun Text suchen. Hat man ihn gefunden kann man ihn natürlich auch verändern. Hier ist jedoch Vorsicht geboten. Verändert nur Werte von dehnen ihr ganz sicher seit, das es Text ist, sonst kann es böse Überraschungen geben. Der beste Rom-Editor den ich kenne ist „SNESEdit“ von SinaP. Er ist soweit ich weiß der einzige er alles zum übersetzen integriert. Der Screen-Hot von oben zeigt dieses sagenhaft, praktische Tool in Aktion. Seit nicht stutzig, weil es sich um ein Dos Tool handelt! Was kann den Rom-Editor noch so, was ein Normaler Hex-Editor nicht kann? Ich werde hier einige Funktionen aufzählen die fast jeder Rom-Editor kann. Search Relative, Pointer & Pointersuche, komprimierten Text anzeigen und editieren, IPS File erstellen, Table editieren und Text Dumpen (müsste uns noch bekannt sein!) All diese neuen Begriffe werden jetzt intensiv erläutert.

Wenn ihr den Text, oder was anderes, in einen Rom geändert habt, wollt ihr vielleicht anderen dieses Werk zukommen lassen?

Damit man nicht das ganze Rom durch die Telefonleitung schicken muss, behilft man sich eines Tricks. Erinnert euch, das ich euch den Tipp gab, von einen Rom immer eine Kopie anzulegen! Das kommt euch nochmals zu gute. Ihr habt das Rom geändert, also müsst ihr auch nur die Änderungen ins Netz stellen. Denn jeder andere hat ja das gleiche Original Rom. Der muss es dann auch nur wieder verändern (lassen) und schon hat er eure Übersetzung oder was ihr sonst so mit dem Original gemacht habt. Diese Änderungen werden im IPS File abgelegt. Patches gibt es auch für Windows Programme. Dort nennt man sie aber meist Update. Sie erscheinen dort auch nicht als *.ips sondern als EXE die nach dem Starten alles von alleine macht. IPS steht für „International Patching Standard“! Was ist aber Patching? Nun das ist von dem englischen Wort „patch“ abgeleitet. Jede kennt diese zusammengeflickten Hosen; diesen Stil nennt man Patchwork. Patch bedeutet Stückchen und genau das repräsentiert er auch im Wort IPS. Dieser File ist aus beherbergt die Stellen wo ihr das Rom verändert habt und wie ihr es verändert habt. Je mehr ihr verändert desto größer wird der Patch. Bei einen Großen RPG kann der Patch schon mal gut 300- 400 KB groß sein. Das ist aber immer noch besser als ein 4 MB Rom zu verschicken. Der Patch wird einfach erzeugt indem man das Original Rom mit dem geänderten vergleicht. Dazu kann ich das SNES Tool empfehlen. Es heißt zwar SNES kann aber bei Patchen mit allen Dateien umgehen. Die Bedienung dieses Tool erklärt sich quasi von selbst, sodass ich es hier nicht weiter ansprechen will.

Ich werde diesen Part nicht zu ausführlich gestallten. Es gibt andere Tutorials die dies besser können.

Im Grunde gibt es 3 Möglichkeiten die Table eines Roms heraus zu finden. Das Rom hat den ASCII Standart und ich muss nur noch Sonderzeichen suchen Den Table File Grafisch suchen mit einem Sprit Editor Table mit Search Relativ finden. Die erste Möglichkeit muss ich wohl nicht weiter erläutern. Manchmal kann es jedoch schwierig werden, weil man meist Dialoge braucht um die Sonderzeichen zu finden. Wenn der Text dann komprimiert ist wirt es schwieriger. Ein Beispiel wäre wieder Breath of Fire II. Hier haben wir ASCII Code, aber auch komprimierten Text. Dazu aber später mehr! Die Zweite Möglichkeit ist ebenfalls nicht immer Möglich, weil nicht jeder Zeichensatz zusammenhängen und einsichtige, grafisch im Rom vorliegt. Wie man den Zeichensatz so findet erfährt man am besten im Tutorial der Kollegen von G-Trans Auch die dritte Methode funktioniert nicht immer. Der Grund warum das so ist, ist wohl immer ein anderer. Was es mit Search Relativ auf sich hat erfahrt ihr anschließend. Habt ihr den Table File heraus gefunden heißt es aufschreiben. Ihr habt weiter oben schon gesehen wie ein Table File aussieht! So könntet ihr es aufschreiben, oder ihr nehmt einen Rom-Editor. Manche Rom-Editoren (z.B. SNESEdit von SinaP oder Hexcalibur von LavosSpown) können die Table selbständig erzeugen, sobald ihr sie gefunden habt! Gespeichert wird die Table im Text-Format! Sie bekommt dabei den gleichen Namen, wie das Rom! Jetzt kommen wir zu den noch ungeklärten Begriffen. Als erstes erfahrt ihr was ein Sprite Editor ist.

Auch dieses Kapitel werde ich etwas kürzer fassen.

Ich sagte am Anfang, dass ihr nicht viel generelles Rom-Hacking lernen werdet. Ich wollte nur das im Voraus einige wichtige Begriffe geklärt werden, sowie den des Sprite-Editors. Der Sprite-Editor ist dem Hex-Editor sehr ähnlich auch wenn es auf den ersten Blick nicht so scheint. Der Sprite-Editor zeigt den gesamten Inhalt eines Roms als Grafik an. Der Hex-Editor hingegen zeigt alles als Text an. Mit dem Sprite-Editor kann man natürlich auch jedes beliege Byte verändern, wovon abzuraten ist, weil man auch hier wieder empfindliche Stellen des Roms treffen könnte und es unbrauchbar macht. Wer mehr zum Begriff des Sprite-Editors wissen möchte den verweise ich wiederum auf das Tutorial von G-Trans. Dort erfährt man unter anderem was ein Sprite ist und wie er verwaltet wird. Dort wird auch sehr ausführlich erklärt, wie man den Zeichensatz (die Table) im Rom finden kann. Was für uns im Moment nur wichtig ist, ist, dass mit dem Sprite-Editor die Grafik verändert werden kann. So könnte man z.B. die Figuren umgestallten, oder andere sinnvolle Dinge. Für den Übersetzer ist wichtig, dass er den Zeichensatz Verändern kann. Er könnte das Aussehen der Buchstaben ändern. Auch wenn man andere Sonderzeichen (z.B. Ä,Ü,Ö) einhacken will, ist dieser Editor unverzichtbar. Zum Schluss noch einige Empfehlungen von Editoren: 1. SNESEdit von SinaP: Dieser Rom-Editor ist, wie ich schon erwähnte, Multifunktionär. Er hat einen Sprite-Editor schon integriert, was sehr praktisch ist. 2. Naga: Der Standart Sprite-Editor für jeden Romhacker. Seine Stärke liegt vor allem in der Schnelligkeit.

Um es nicht unnötig kompliziert zu machen habe ich diesem Thema ein extra Kapitel gegönnt.

Wir wissen ja mittlerweile was der Zeichensatz ist. Wenn ihr euch das Tutorial von G-Trans schon angesehen habt wisst ihr, dass der Zeichensatz aus einen 16 * 16 großen Feld besteht. Das ist die grafische Zuordnung des Zeichensatzes. Die einzelnen Felder werden wie ein ganz normales Array angesprochen. Im ASCII Zeichensatz(für den gibt es aber keine Grafische Zuordnung. Das aussehen der Buchstaben wird vom OS vorgegeben) würde der Buchstabe A in der 5. Reihe an 2. Position stehen. Warum denn nicht in der 4. Reihe an 1. Position? Der Wert für A ist doch 41! Nun das ist einfach erklärt: Man darf nicht bei 1 anfangen zu zählen sondern bei Null. Dann geht man die Reihe durch und kommt bei 40 in der 5 Reihe an! Bei den Zweiten werten ist es genauso. Wenn ihr das Tutorial von G-Trans seht werdet ihr es verstehen. Für uns heißt das: Der Zeichensatz steht(meistens) irgendwo im Rom als grafische Tabelle (darum Table-File). Hier ist die Zuordnung und das Aussehen der Zeichen gespeichert. Es kann auch vorkommen, das ein Rom mehrere Zeichensätze hat! Die muss man dann einzeln finden und jede in eine separate Table stecken. Manchmal findet man aber keinen Zeichensatz. Dann muss man die nächste Lösung versuchen: Search Relative

Die Arbeitsweise dieses Programms (ist auch wieder in SNESEdit integriert) hat mich persönlich am Anfang etwas verwirrt.

Wir gehen davon aus, dass wir den Text im Rom nicht lesen können, weil wir (noch) keine Table haben. Wir müssen uns klar machen, dass jedes Zeichen einen bestimmten Abstand zum nächsten hat und zwar nicht in der Länge sondern in der Anzahl der Hex-Werte die dazwischen liegen. Der Abstand von B und E beträgt logischerweise 3! Das kann man mit jedem Buchstaben machen. Dann sucht man sich ein Wort, von welchem man weiß, das es im Rom vorkommt. Es ist besser ein Rom aus dem Menu zu nehmen, weil die meist nicht komprimiert sind. Komprimierte Zeichen kann selbst Search Relativ nicht selbst erfassen. Nehmt euch das Wort und schreibt es auf, zählt die Abstände zwischen den Zeichen und schreibt sie auf(dabei sind kleine Buchstaben zu beachten) Dann habt ihr eine Zahlenreihe zu stehen, die Abstände der einzelnen Zeichen wiederspiegelt. Jetzt könnt ihr ins Rom gehen und nach Abständen suchen. Das dürfte etwa 1 ½ Jahre dauern, wenn ihr etwa Übung habt vielleicht weniger. Etwas geschockt? Na ja, damit es etwas schneller gibt hat man ja Search Relativ erfunden. Es macht genau das was ich oben beschrieben habe, nur sehr viel schneller. Es sucht nach den Abständen(nicht mal die müsst ihr selber ermitteln) der Buchstaben des Wortes was ihr eingegeben habt(das ist das einzige was ihr tun müsst)! Findet es diese Abstände im Rom, werden sie mit den Buchstaben des Wortes, welches ihr eingegeben habt belegt. Habt ihr ein Wort wie „Dragon“, „Village“ oder „Items“ gewählt und sie wurden gefunden, könnte ihr meinst mir ruhigem gewissen sagen, dass ihr die Table schon fast habt. Bei einigen Rom-Editoren, die Search Relativ unterstützen, könnt ihr aus den Suchergebnissen gleich eine Table anfertigen lassen. Wenn diese Richtig war könnt ihr schon einen Teil des Roms übersetzen. Wenn der viel Text im Rom ist könnt ihr zusätzlich davon ausgehen, der Text auch nochkomprimiert ist. Das ist Thema des nächsten Kapitels

Mit zunehmender Erfahrung im Rom-Tranlaten werdet ihr erkennen, das Platz in einem Rom sehr kostbar ist.

Darum haben sich die Programmierer wieder was cleveres einfallen lassen. Im Zeichensatz wird nur wenig Platz von Zeichen belegt. Einige Bytes sind mit Steuerzeichen belegt. Aber die Bytes die frei sind werden genutzt um etwas zu adressieren. Aber was? Nun es wird eine Stelle im Rom angesprochen, wo verschiedene Zeichen singvoll zusammen stehen, sodass man gut Silben aus ihnen bilden kann. Die Tabelle, in der das festgehallten ist, ist jedoch nicht grafisch! Es werden einfach 2 Zeichen zusammen in einem Byte untergebracht! Natürlich kann man auch davon eine Table machen, die dann etwa so aussieht: 2F=th 30=in 31=g (hinten ein Leerzeichen dran) ... Aus diesen drei Byte (2F 30 31) könnte man also schon das Wort „thing „ bilden. Mit dem unkomprimierten Zeichensatz hätte man dafür satte 6 Byte benötigt, so braucht man nur die hälfte. Diese Form des komprimierten Zeichensatzes nennt man DTE ( das D steht für Dual, also Zwei, den Rest hab ich leider vergessen) Hier werden also 2 Zeichen in einem Byte untergebracht. Daneben existieren in manchen Roms noch die MTE´s (M für Multi) Hier werden noch mehr Zeichen in 2 Byte untergebracht. Dann gibt es noch MTE´s mit 3Byte. Diese könnten dann noch mehr Zeichen fassen, aber wie viele genau weiß ich nicht! Mehr will ich eigentlich zum Komprimierten Zeichensatz nicht sagen. Wer mehr zu Komprimiertem Text wissen soll dem empfehle ich das Tutorial von Cool Moe Di. Gibt’s natürlich auf http://www.g-trans.de und auch bald bei uns!

Den Begriff den Dumpens kennt ihr schon.

Es bedeutet das Daten irgendwo ausgelesen werden. Beim Text ist das ähnlich. Weil das Translaten selbst mit dem besten Rom-Editor umständlich ist zieht man den ganzen Text einfach heraus. Dafür sollte man aber den gesamten Zeichensatz, alle Sonderzeichen, alles komprimiert ist und alle Steuerzeichen kennen. Ich selbst weiß nicht viel übers Dumpen, darum kann ich nur sagen, dass er Text in eine einfache Text Datei geschrieben um ihn besser editieren zu können. Hat man alles übersetzt wird der Text gereinserted! Das heißt aller Text der im Rom war wird mit dem Übersetzten überschrieben. Wenn das geschehen ist werden die Pointer neu berechnet.

Programmierer werden wissen wo von die Rede ist.

Ein Pointer ist ein Zeiger auf eine Speicherstelle. Im Rom ist der Pointer auch ein Zeiger, aber nicht auf eine Speicherstelle sondern auf einen Text. Am Anfang eines Dialoges gibt es meistens einen Pointer, den muss man dann berechnen! Wie das geht könnt ihr (wieder mal) im Tutorial der Kollegen von G-Trans nachlesen, dort ist das sehr gut beschrieben. Mehr kann ich dazu nicht sagen, weil ich noch nie mit Pointern gearbeitet habe.

Das größte Problem ist immer der Platzmangel!

Wenn Menüs nur 5 Zeichen groß sind und man muss das Wort „Ausrüstung“ reinbekommen...
Na ja ihr werdet es selbst sehen, wenn Ihr übersetzt. Es gibt aber bestimmt auch Roms, wo man viel Platz hat, aber das ist sicher die Ausnahme. Das man sowenig Platz hat liegt nur daran, das die deutsche Sprache (meistens) länger ist. Ein weiteres Problem ist, das manche Roms ihren Zeichensatz nicht preisgeben wollen. Seiken Densetsu III ist so ein Beispiel. Geschafft hat man es aber trotzdem! Den Patch gibt’s bei G-trans oder bei uns. Das letzte große Problem was viele haben werden ist das Übersetzen von Japanischen Roms. Ich habe so was noch nie gemacht, weil ich sowieso kein Japanisch kann und das viel aufwendiger ist, weil man erst noch den Zeichensatz übersetzen muss oder er sogar noch erstellt werden muss. Also könnt ihr alles was ihr hier gelernt habt nur auf englische Roms anwenden. Wer jetzt meint er hätte nichts verstanden, der soll das ganze Tutorial noch mal lesen. Diese Tutorial sollte einen kleinen Einblick in die Welt der Rom-Translation geben und einige dinge erklären, Ich hoffe mir ist das gelungen. Wenn ja, bist du vielleicht bald ein neuer Translator