Gargoyles Quest 2

  • Hallo Zusammen,


    leider kann ich die Zeiger immer noch nicht finden. manakoAT hat sich leider noch nicht gemeldet und auch mit der Suche im SnesEdit konnte ich nichts finden. Daraufhin habe ich selber ein kleines Java-Tool geschrieben, welches mit eine Differenzsuche nach Vorgabe durchführt, auch hier bin ich nicht fündig geworden.



    Hier mal der Code (komischerweise landet der Code immer in einer Zeile, auch wenn ich ihn korrekt formatiere...):


    Code
    1. public void searchPtrBlock() throws Exception { int[] valuesToFind = { 61, 68, 44, 54, 33};
    2. byte[] bytes = Files.readAllBytes(Paths.get("./data/rom/in.rom")); for(Integer index = 0; index < bytes.length - valuesToFind.length; index ++) { //Search the differences from the current position corresponding to the difference array boolean found = true; for(int idx = 1; idx < valuesToFind.length; idx++) { int nextVal = (int) bytes[index + idx]; int lastVal = (int) bytes[index + idx - 1]; if(found && ((lastVal + valuesToFind[idx]) == nextVal)) { //The array rules still apply - continue } else { found = false; } } if(found) { //found possible position - print it System.out.println("Found index: " + index); } }


    Nochmal des Verständnis wegen: ich zähle die Länge von Textanfang zum nächsten Textanfang (inkl. Text-Ende-Byte), zähle dann genau so den nächsten Text. Und suche dann diese Liste von Abständen im Rom. Z.B.


    Liste mit Textlängen: {61, 68, 44}


    Wäre im Rom sowohl: 61, 68, 44 als auch 62, 69, 45 bzw. 71, 78, 54 jeweils ein Hit! Bitte korrigiert mich, wenn ich hier falsch liege. Entweder ich zähle die Textlängen falsch, oder ich kann auf diesem Wege nichts finden...


    Vielen Dank und viele Grüße!


    Seb

  • Dein Code hat nur ein LF (bei Linux) oder nur ein CR (bei MAC).
    Bei Windows sollte es ein CR LF sein : CR=0Dh, LF=0Ah. Sonst gibt es keinen Umbruch am Zeilenende.
    Deinen Code einfach mit WordPad Laden und Speichern. Der erweitert denn Text dann auf CR LF und alles ist gut.


    Falsch verstanden.


    - Vom PUNKT bis zum Zeichen vor dem nächsten PUNKT. Weil der PUNKT ist der ANFANG der Textlänge und nicht das ENDE. Ansonsten zählst Du ihn zu viel.
    - Du suchst die Textlänge als wert denn Du ermittelt hast. Das steht dort nicht drin.
    Du must die ermittelten werte zu deinem Anfangswert im ROM dazu zählen.


    Als Beispiel Deine Werte aus dem Code: 61 68 44 54 33


    Erstes Byte aus ROM einlesen: z.B.: 200, dazu 61 zählen. -- Mehr wie 255 geht nicht, also weiter mit ...
    ... nächstes Byte aus ROM einlesen: z.B.: 5, dazu 61 zählen, = 66, gute zahl nächstes Byte lesen.


    -- Pointer haben normalerweise 2 Byte also immer 2 Byte suchen und wert dazu zählen.


    Erste 2 Byte lesen:
    z.B.: 3DF1 = 15857 + 61 = 15918 + 68 = 15986 + 44 = 16030 + 54 = 16084 + 33 = 16117


    Das ist das was Du suchst: 15857 15918 15986 16030 16084 16117


    Leider mu0t Du jedes Byte durch laufen. Bei 8-Bit Systemen sind die Pointer nicht an allen ungeraden Offsets. Sie können auch an geraden Offsets sein.


    Bei SE-Win ist die Suche mit der Pointer Anzeige gekoppelt. Da kannst Du die gefundenen stellen gleich ansehen.


    P.S.:
    Die Pointer Blöcke die Du findest sind nur die RICHTIGEN Abstände. NICHT die richtigen Pointer.
    Deshalb so viel wie möglich Abstände benutzen. Dann sind die Treffer weniger aber eindeutiger.
    Danach must Du noch Deine Pointer Differenz einstellen um zu Sehen (Pointer Anzeige) ob es die gesuchten Pointer sind.


    - Noch ein Tipp. Die Differenz ist nur zum Sehen da. Die Pointer sind im Programm berechnet und Zeigen an denn richtigen Offset. Sie können relativ zu der Position im ROM sein, oder aber Absolut zum ROM Anfang minus Header plus 8000h (SNES, NES weis ich gerade nicht mehr) für Start ASM Code.


    Viel Spaß :bye:

  • Hallo Zusammen,


    für die von euch, die der Patch interessiert hier mal ein kleines Statusupdate: Ich habe das Spiel komplett übersetzt und ein Tool geschrieben, welches es ermöglicht das Spiel in eine beliebige Sprache zu übersetzen. Es extrahiert automatisch das Script, liest die Übersetzung ein, berechnet die optimale interne Kompression (das deutsche Script wird dabei von ca. 13 KByte auf unter 8 KByte komprimiert), teilt die Texte automatisch optimal über die Speicherbereiche auf und fügt es wieder in das Rom ein. Es werden momentan noch keine Grafiken manipuliert.


    Aktuell habe ich leider noch das Problem, dass bestimmte Strings (ca. einer von 100) verschoben werden (es wird ein anderer Text angezeigt als erwartet...) und ich noch nicht ganz verstehen wieso dies der Fall ist. Ich denke aber, dass ich auch diesen Fehler in den nächsten Wochen beheben werden. Sollte jemand von euch Interesse daran haben die Übersetzung zu testen, würde ich mich über eine kurze Meldung freuen!


    Hier noch ein Screenshot: [picul]n71[/picul]



    Viele Grüße!


    SebMaster