[PSX] Ace Combat 3: Electrosphere

[OrientalComputer_1]

Salve a tutti, popolo di Romhacking.it!
Innanzitutto mi presento : sono OrientalComputer_1 (aka Naitoraven951) e volevo condividere con voi il progetto di traduzione di Ace Combat 3 electrosphere in italiano inziato 8 mesi fa.
Questo gioco ha avuto la grande sfortuna d'essere stato importato in America/Europa con un porting scabrosissimo. La versione giapponese possiede : 2 Dischi, 52 missioni, filmati in CG sviluppati dalla I.G production, una trama molto profonda e ben sviluppata!
Ci stiamo basando sul lavoro del project nemo e i nostri obiettivi sono i seguenti :

OBIETTIVI TRADUZIONE :

• ✓ Traduzione degli script dall'inglese all'italiano
• ✓ Hacking delle .TIM decompresse di entrambi i CD (grafica, sottotitoli, filmati in CG, discussioni in HUD)
• ✓ Decompressione e compressione file .BPB
• ✓ Creazione di un patch ppf/xdelta

• Aiutare con un wiki tutti coloro che vogliono tradurre il gioco nella loro lingua

Team di traduzione :

• Io, OrientalComputer_1 - traduttore/editore/revisore/hacking grafico
• Infrid - programmatore/traduttore/revisore/hacking grafico
• SolidSnake11 - programmatore/traduttore
• Yarghenforgen - traduttore giapponese

Ecco alcune prove di traduzione :

filmato in CG

Testi e V-Mail

Dialoghi Radio

Cutscene in-game

Abbiamo una pagina facebook e un wiki che spiega la struttura tecnica dei files (disponibile anche in lingua inglese).
Ecco i link :

Ace Combat 3 - Italian Translation Project
Ace Combat 3 Translation Wiki [ENG/ITA]

Vi ringrazio in anticipo e....stay tuned, ragazzi!
Sicuramente avremmo tanto bisogno del vostro supporto.
P.S Ringrazio Gemini che ha risolto il mio problema di accesso al forum.

[Clomax]

per prima cosa: COMPLIMENTI!

creerò una news quanto prima.

[OrientalComputer_1]

Grazie infinite, Clomax !
Speriamo di portar a termine il progetto il prima possibile!
Dovessi avere difficoltà con la traduzione, posso esporre il mio problema qui o devo creare un altro topic?

[Infrid]

anni fa misi le mani su questo gioco cercando di capire il funzionamento della sua compressione per modificarne i testi. Il fatto di non conoscere nulla di giapponese era un problema secondario, qualcuno magari mi avrebbe aiutato.

Per via della mia niubbaggine in materia ed anche per alcuni impegni personali (università) misi nel cassetto questo progetto.

Anni dopo vidi che altre persone stavano tentanto la stessa cosa con risultati più o meno fruttuosi, ho ripreso in mano il progetto e facilitato dalle scoperte altrui ho scritto il mio decompressore per poter lavorare sui file del gioco.

Ora la sfida e comprimere, e riscrivere le accozzaglie di tool che esistono in giro per creare una suite decente per poter lavorare col gioco.

Al momento questo è l'unico tool pubblico che riesce a decomprimere tutti i file del gioco, nei ritagli di tempo limo il codice ed aggiungerò nuove funzionalità. Preferisco rilasciare il software ora, anche se immaturo, piuttosto che tenerlo sull'hard disk quando a qualcuno potrebbe servire!

Ecco a voi il link per il repo https://github.com/Infrid/ac3es-tools

[Gemini]

Sbaglio o sulle wiki sono presenti solo un paio di decompressori ulz ma nessun compressore? Di preciso che dati sarebbero contenuti in forma compressa?

[Infrid]

Sbaglio o sulle wiki sono presenti solo un paio di decompressori ulz ma nessun compressore? Di preciso che dati sarebbero contenuti in forma compressa?

Non ti sbagli, al momento solo decompressori. Per quanto riguarda i contenuti, sono state compresse le Tim con i testi del gioco e qualche altro dato come mappe e texture.

In questi giorni sto cercando di capire come veniva popolato un bit nell'header del file ulz, utile per creare una maschera al fine ricavare il Jump/Run nell'algoritmo lzss.

In teoria potrei ricopiare il byte dall'header originale ed utilizzarlo nella compressione, ma mi sto divertendo troppo e voglio arrivare a capire tutto!

[Gemini]

Non ti sbagli, al momento solo decompressori. Per quanto riguarda i contenuti, sono state compresse le Tim con i testi del gioco e qualche altro dato come mappe e texture.

Quindi tutta roba utile. Come hanno risolto nella traduzione inglese?

In questi giorni sto cercando di capire come veniva popolato un bit nell'header del file ulz, utile per creare una maschera al fine ricavare il Jump/Run nell'algoritmo lzss.

Probabile che il compressore di Namco prendesse dei parametri appositi per determinare quanti bit fossero spartiti nella coppia salto-lunghezza. In teoria un sistema automatico testerebbe il risultato della compressione con un buffer circolare per evitare di sprecare tempo a comprimere realmente. Facendo un test da 5 fino a 10 bit per i salti dovresti avere tutte le variazioni utili e risparmiare sui tempi di compressione, oltre ad avere risultati ottimali senza la soluzione di copiare dall'originale (che potrebbe risultare in una compressione tutt'altro che soddisfacente).

[Infrid]

Nella patch inglese non hanno compresso nulla, il gioco ad ogni modo accetta anche TIM non compresse, l'unico problema è cercare di non sforare i valori massimi dei puntatori che sono contenuti nel file ACE.BPH che fa da indice. Immagino ci sia pure un altro problema, quello dello spazio su disco.

Ho visto che per il processo di decompressione devo fare uso di un buffer circolare

Per quanto riguarda il calcolo della coppia salto-lunghezza, il gioco usa 2 byte per immagazzinare questo dato ma quanti bit riservare al salto e quanto per la lunghezza, viene deciso da un byte nell'header che chiamo nbits.

Verosimilmente nbits dipende dai valori massimi di salto-lunghezza, ho analizzato i file e stampato gli header cercando di capire quale sia il nesso logico. Ho provato a scrivere due righe di codice ed azzecco il valore giusto di nbits per oltre duemila files (nel cd 1 sono contenuti 2256) tranne per 160 files circa. Immagino che quelli siano dei valori di default se vengono riscontrate certe condizioni.

Stasera mi rimetto a lavoro e cerco di capire meglio, eventualmente apro un topic e spiego meglio la situazione se non riesco a venirne a capo

[Gemini]

Nella patch inglese non hanno compresso nulla, il gioco ad ogni modo accetta anche TIM non compresse, l'unico problema è cercare di non sforare i valori massimi dei puntatori che sono contenuti nel file ACE.BPH che fa da indice. Immagino ci sia pure un altro problema, quello dello spazio su disco.

Se il gioco accetta anche file non compressi tanto di guadagnato, ma credo sarebbe meglio mantenere la compressione per un semplice motivo: snellisce drasticamente i tempi di caricamento su console.

Verosimilmente nbits dipende dai valori massimi di salto-lunghezza, ho analizzato i file e stampato gli header cercando di capire quale sia il nesso logico. Ho provato a scrivere due righe di codice ed azzecco il valore giusto di nbits per oltre duemila files (nel cd 1 sono contenuti 2256) tranne per 160 files circa. Immagino che quelli siano dei valori di default se vengono riscontrate certe condizioni.

Potrebbero essere una scelta in base ai tipi di file come anche la scelta più efficiente tramite analisi euristica. Che poi, in fin dei conti, potresti tranquillamente ignorare tutto ciò che non serve alla traduzione e comprimere (anche con un algoritmo non velocissimo di analisi) giusto le immagini con testo.

[Infrid]

Potrebbero essere una scelta in base ai tipi di file come anche la scelta più efficiente tramite analisi euristica.

Potrebbe anche essere così, avranno fatto dei test ed hanno scelto i parametri migliori.

piccolo aggiornamento, stiamo traducendo i testi per il momento mentre sul lato tecnico sto analizzando come i file sono assemblati nel file ACE.BPB

Devo riprendere in mano la compressione e poi provare ad assemblare un ACE.BPB modificato.

Come se non bastasse stiamo vedendo come modificare i credits eventualmente, nella versione PAL i testi sono in formato ASCII (wow!) mentre su quella JAP probabilmente sarà qualche altra codifica. Appena smaltiremo il lavoro ci torneremo.

[Gemini]

Per i crediti consiglierei di guardare il gioco sotto debugger grafico catturando i pacchetti della GPU, soprattutto se è davvero testo e non grafica come tutto il resto dei dialoghi in gioco. Da lì si dovrebbe capire senza troppi problemi come funziona l'assegnamento delle primitive sprite.

[OrientalComputer_1]

Salve Gemini. Sì, posso confermare che i crediti sono immagini e non testo ASCII. Usando il no$psx ho visto la VRAM in modalità debug e si vedono anche i rispettivi ritagli dei testi. Anche le immagini di sfondo lo sono (dovrebbero essere a .TIM segmentate a 8 bpp, credo...).

Ora, il problema è che noi non riusciamo a trovare questa .TIM in quanto sarà compressa o celata in qualche file specifico. Ma sopratutto, non sappiamo la vera "natura" di quest'immagine.
Se credo un dump della RAM, lo decomprimo e lo visualizzo con un decompressore/compressore qualsiasi, il risultato è questo :

Sono i crediti ma sembrano compressi/codificati. Poi nella VRAM è possibile vedere questa .TIM senza queste strane sfumature di colore. Non ho mai visto una cosa del genere, ma...siccome parliamo di PS1, tutto è possibile  !

[Phoenix]

Credo che l'unico modo per svelare il mistero, sia quello di andare di debugger, e capire come il gioco carica l'immagine in VRAM.
Il motivo per cui in RAM non trovi la TIM in chiaro è probabilmente dovuto la fatto che appena questa viene mandata in VRAM, la zona di RAM che la ospita viene marcata come libera e sovrascritta da qualcos'altro. Dovresti fare un dump della ram qualche istante prima che i credits vengano visualizzati, così da avere la TIM dei credits ancora in RAM. Oppure mettere uin breakpoint alla chiamata della funzione SDK LoadImage e verificare quando questa viene chiamata per trasferire la TIM dei credits in vram.

[OrientalComputer_1]

Con grande gioia, siamo lieti di annunciarvi che la patch per il primo disco di AC3 è stata rilasciata .
Ancora non riusciamo a credere che siamo arrivati a questo punto, siamo troppo contenti.
Mancano alcune cosine, ma cercheremo di sistemarle con la patch 1.00 e con la traduzione del secondo disco.
Vi lasciamo il link con la patch :
AC3ITA_translation_v050b

Ragazzi, vi auguriamo un buon divertimento con AC3  .

Credo che l'unico modo per svelare il mistero, sia quello di andare di debugger, e capire come il gioco carica l'immagine in VRAM.
Il motivo per cui in RAM non trovi la TIM in chiaro è probabilmente dovuto la fatto che appena questa viene mandata in VRAM, la zona di RAM che la ospita viene marcata come libera e sovrascritta da qualcos'altro. Dovresti fare un dump della ram qualche istante prima che i credits vengano visualizzati, così da avere la TIM dei credits ancora in RAM. Oppure mettere uin breakpoint alla chiamata della funzione SDK LoadImage e verificare quando questa viene chiamata per trasferire la TIM dei credits in vram.

Salve anche a te Phoenix, onorato di ricevere una tua risposta. Ho provato ad effettuare il savestate il più velocemente possibile, ma la .TIM la vedo sempre rovinata. Credo tu abbia ragione, il debugger sicuramente potrebbe svelarci la soluzione a questo problema.
Se sappiamo qualcosa, vi informeremo subito  .
Phoenix, esistono altri giochi che si comportano alla stessa maniera con il caricamento delle .TIM?
Grazie in anticipo!

[Infrid]

grazie per il suggerimento LoadImage, devo ripassare l'architettura della psx e rimettere mano al debugger, dovremmo correggere altri bug relativi alla sezione search del gioco e non vedo altra strada che l'uso del debugger!

Come ha detto il mio amico è uscita la patch beta per il primo disco, buon divertimento

comunque abbiamo una bella wiki dove raccogliamo i nostri appunti e lo stato della traduzione!
http://ac3es.infrid.com/doku.php