TMNT: Tournament Fighters (SNES)

[White Dragon]

Finito il testing del programma di de/compressione.
Ecco uno screen:


Grazie Morher! ^___^

un ultimissimo piccolo aiuto. per il testo sono apposto. x la grafica ho visto ke (naturalmente ) si usa lo stesso algoritmo di compressione. vorrei però kapire per es. per decomprimere la grafika delle font come posso agire. le fonti tra l'altro stanno subito dopo il testo della skermata iniziale..
solo ke nn capisco da dove devo prendere i bytes x decomprimere il tutto..

[Morpher]

Il "trucco" è sempre lo stesso. Metti un bel break in scrittura all indirizzo 7e2000 finchè non vedi i soliti byte e poi salva. Decomprimi il salvataggio e apri il file con un editor grafico. Se usi Tile Molester imposta la codifica a 2bpp planar e vedrai il font decompresso. I primi byte del font de/compresso sono DB3CBD66. In pratica sono subito dopo la sfilza di FF che succede il testo compresso all'offset C8D00

[White Dragon]

grazie morpher come al solito sei stato d'aiuto!
tra l'altro dopo ke mi hai detto dove stanno i bytes, mi sono accorto ke c'era una cosa che non avevo implementato nel de/compressore.
in pratika la KONAMI per scrivere da 2 a 33 byte 0x00 usa questi bytes:
da 0xE0 a 0xFF poi ci fa un AND 0x1F e poi ci somma 2.
azz però... mi metto subito ad aggiornare il de/compressore!!
grazie ankora morpher!!

[White Dragon]

Ho finito di scrivere il de/compressore (a quanto pare).
Devo dire che scrivere il decompressore è stata una cavolata pazzesca, mentre invece per il compressore proprio no!
alla fine x il compressore bisogna andare a logica x capire come funziona
e vedere quali sono le differenza tra i dati compressi del mio e del loro.
credo ke un compressore IDENTICO all'originale sia quasi impossibile da fare perkè le strategie di compressione possono essere un tantino differenti..
in ogni caso mi sono studiato 5 diversi dati compressi.
ne è uscito fuori ke il mio compressore comprime MEGLIO i dati, nel senso ke proprio la ratio di compressione ke ho usato io (emulando quella della konami)
funziona meglioe quindi l'algoritmo di efficienza del compressore fa sì ke i dati compressi col mio tool siano ankora + piccoli di ampiezza.
questo xò potrebbe essere uno svantaggio in realtà morpher? nel senso ke
io x modificare i dati del gioko dovrei avere la stessa identika ampiezza? oppure basta ke sia semplicemente minore/uguale ( e riempire di byte 0x00 o 0xFF il mancante)?

ps. se vuoi ti posto anke il tool. byeeee

[Gemini]

io x modificare i dati del gioko dovrei avere la stessa identika ampiezza? oppure basta ke sia semplicemente minore/uguale ( e riempire di byte 0x00 o 0xFF il mancante)?

La decompressione rileva in qualche modo quando terminare il processo? In quel caso (dubito si possa fare altrimenti) puoi mettere dati di qualsiasi dimensione al posto degli originali e tutto dovrebbe filare liscio.

[Morpher]

Credo che il padding di 0xFF indichi alla routine di decompressione quando fermarsi, ma non ne sono certo. In ogni caso segui il consiglio di gemmo; una bella sfilza di spazi e nessuno vede niente

Per quanto riguarda il compressore devi sapere che anche la roba che ho scritto io, così come quella scritta da gemini, da phoenix e da mat comprime sempre meglio dell'originale... sarà che i programmatori non vengono pagati abbastanza per impegnarsi un po'di più nel lavoro

[White Dragon]

Vi ringrazio a tutti per l'aiuto!! in realtà dovrebbe essere il byte 0x80 a fermare la decompressione se si trova al posto di una coppia salto/recupero. in realtà poi nn è ke si ferma la decompressione, ma semplicemente dall'0x80 in avanti prende i byte così come li trova senza decodificarli. a questo punto potrei fare 0x80 seguito poi da una sfilza di 0x00 (o di 0xFF).
pensavo di nn aver fatto un buon lavoro ma se mi dite così a questo punto devo ricredermi..
credo anke di aver capito quali migliorie ho apportato al compressore, ed alcune riguardano lo scorrimento del search_buffer oltre ke dell'algoriitmo per determinare l'efficienza delle coppie.
presto mi metterò a cercare le parti compresse da tradurre (ke saranno poke da quel ke ho visto). a presto buone nuove ciao e grazie ankora per i vostri aiuti determinanti (a morpher poi c'è uno special thnx nel readme del tool).

byeee

[White Dragon]

Nessun problema nel modificare i tiles grafici a parte questo...
La scritta "FIGHTER SELECT" che fa parte dello sprite layer...
Ho modificato l'intero savestate per cercare i byte che compongono la scritta
e ho trovato la scritta che comincia per questi bytes:

Codice Seleziona Espandi

50 28 00 67 48 30 11 67 50 30 10 67 54 5A 3D 67 40 38 2B 67 58 60 3F 67 20 53 0A E7 50 60 2D 67 30 55 08 E7 40 57 06 E7 3E 57 3A 67 46 57 3E 67 3E 47 04 67 48 37 02 67 40 90 2B 67 4E 98 2E 67 3E 90 0C 67 48 A0 0E 67 B1 4B 36 27 A8 42 3D 27 C6 23 2B 27 A4 54 2F 27 A1 44 20 27 B8 28 37 27 D8 38 38 27 C0 28 24 27 D0 28 22 27 D4 B0 2B 27 C8 B8 39 27 D0 B0 ... ...
Questi bytes stanno all'indirizzo =x7E01E0 in RAM... quando carichi il gioco con il savestate modificato, nn si visualizza nessun cambiamento.
Lo si visualizza solo con il programma vSNES.exe che serve a vedere le informazioni del savestate.
Vorrei capire come la rom ottiene questi bytes, ma nel modo ke Morpher mi ha indicato non riesco a ricavari i bytes nel rom fisica.
Come potrei trovarli?

RISOLTO: i caratteri erano scritti in questo modo:
XX XX XX YY XX XX XX ZZ dove YY era la parte superiore del carattere e ZZ la parte inferiore in più la parola era reversata es. fighter = rethgif
quindi ogni carattere si trovave dopo BEN 8 bytes... ed i bytes intermediari caricati in ram erano completamente diversi da quelli nella rom fisica (almeno il testo non era compresso)

[White Dragon]

come nn detto... finkè nn prendo confidenza con l'assembly x consoles..
sto modifixcando la scritta da 1P/2P a 1G/2G come in figura:

e sto modificando i bytes ke compongono il disegno (oltre che la grafica).
ci sono 2 disegni xò. quello di 1p/2p normale, e quello di quando premi START e ti aggiungi durante la selezione del personaggio già attiva.
il primo sono riuscito a modificarlo completamente, il secondo no.
il problema è ke i bytes ke kompongono il disegno vengono caricati in VRAM all'indirizzo 0x43b0 e non in RAM. come faccio quindi a mettere un breakpoint x capire da dove prende i bytes x decomprimerli dalla rom fisica?

RISOLTO: se la data non è compressa basta cercarla in ram escludendo
l'intervallo di offset 7e2000~7e23ff.
quello che viene caricato in vram, viene posizionato a partire dall'offset di memorizzazione in ram.
quindi se in ram la data viene immagazzinata in 0xXXX000
in vram la troveremo in 0xYYYY00 o 0xYYY000