 |
 |
 Guida completa alla traduzione di ROM in lingua straniera |
||
|
Autori:
D-Chan,
mickey,
Fraka,
Duke,
BGies,
MJL,
_Ombra_
Dannazione, non esiste nessun fottuto manuale per le traduzioni! Nessun nome, nessuna tecnica! Soltanto un ammasso uniforme di valori esadecimali legati da regole decise da quei pazzi dei programmatori, e la vostra intelligenza!! - Introduzione -Intendete tradurre una ROM, o semplicemente volete modificarne il contenuto, ma non avete la più pallida idea di come si faccia, non siete pratici di editor esadecimali o cose del genere e soprattutto non sapete come è fatto l'interno di una ROM? Allora iniziamo dalle basi. Il testo di una ROM, salvo in rari casi, non utilizza lo standard adottato dal DOS e da Windows, il codice ASCII. In questo codice (come in tutti quelli esistenti anche nelle ROMs), ogni lettera corrisponde ad un numero. Per esempio, la lettera A in ASCII corrisponde al numero esadecimale $41, la B al $42 e così via (i numeri esadecimali si indicano generalmente col simbolo "$" che li precede, ma per comodità in questa guida li lasceremo indicati senza). Una ROM ha anch'essa ogni lettera associata ad un numero, che generalmente viene espresso in numeri esadecimali (per chi lo ignorasse, il sistema esadecimale è un sistema di numeri in cui si va da 0 a 15, dove i numeri dal 10 al 15 vengono indicati con le lettere dalla A alla F). Un tempo era necessario procurarsi un Hex Editor, cioè un editor esadecimale, ed imparare a memoria il codice della ROM che si traduce. Quindi per tradurre la parola "Arma" in FF3 era necessario cercare i numeri 00 2B 26 1A e sostituirli con quelli equivalenti alla parola desiderata. Fortunatamente adesso esistono delle utility che visualizzano e permettono di modificare il testo come se fosse in ASCII (o quasi) e rendono molto più semplice la modifica della ROM, anche se non riducono certo i problemi di spazio che si incontrano. Già, per chi non lo sapesse in una ROM non si può superare il numero di caratteri in una riga presenti nella versione originale. Questo rappresenta il più grosso problema di traduzione, specie nelle ROMs in Giapponese (anche se un metodo per aumentare lo spazio per il testo esiste, ma è estremamente complesso). Comunque ricordatevi che è meglio cambiare di molto il testo anziché renderlo più vicino all'originale ma facendolo diventare difficilmente comprensibile. La grafica in una ROM è sempre gestita in tile, ma di questo parleremo dopo. Premessa:
ricordate che in questa guida le lettere della ROM verranno definite "font" oppure
"tile". Le tile ad ogni modo non contengono esclusivamente il testo ma anche la
grafica, per cui non fate confusione (vedere il capitolo "I FONT" per ulteriori
delucidazioni). - La modifica del testo -Per iniziare a tradurre una ROM è necessario
conoscere la sua tabella dei fonts, ovvero le corrispondenze valore esadecimale ->
carattere. 0 1 2 3 4 5 6 7 8 9 A B C D E F La tabella si legge come un piano cartesiano: prendendo prima il numero della riga, poi
quello della colonna troverete a che codice esadecimale corrispondono le varie lettere
(in questo caso: A=11, B=12, 9=4D, >=F0). Come trovare la giusta tabella dei font1) Metodo del confrontoSe il gioco che volete tradurre permette di cambiare il nome al proprio personaggio
(Es: Chrono Trigger) procedete in questo modo: fc /b chrono.1 chrono.2 > cfr.txt Adesso lanciate edit cfr.txt e andate ad esaminare il file.
file: cfr.txt Confronto dei file chrono.1 e chrono.2 in corso... Nel file chrono.2 si notano 5 caratteri uguali uno di seguito all'altro che corrispondono
al nome "AAAAA", quindi la A = A0 e di conseguenza la C = A2, r = CB,
o = C8, n = C7. Ora si può costruire la tabella delle fonts seguendo l'ordine alfabetico
(se A = A0 allora B = A1, C = A2 e così via...).
Naturalmente se il simbolo che stiamo cercando, mettiamo sia il disegno di una faccina, si trova 2 tiles prima della A e il codice della A è A0, il codice per faccina è A0 - 2 = 9E. Un altro sistema è invece quello di sostituire alla prima frase del gioco dei numeri
esadecimali a caso, per vedere quali simboli escono fuori. Il piu' delle volte sarete
costretti a fare così per scoprire tiles che non sono numeri o lettere, e quindi
difficilmente rintracciabili in altro modo. Si, oggi e' una bella giornata! :) Aprendo la ROM col Thingy cercate questa frase, vi si presenterebbe una situazione del genere: Si<0B> oggi e<0C> una bella giornata<0E> <0F><10> Ovviamente i bytes 0B,0C,0E,0F e 10 sono rispettivamente virgola, apostrofo/accento, punto esclamativo, due punti e parentesi ;) 2) Con il programma SearchR dei DejapInnanzitutto consiglio di procurarsi l'utility chiamata SearchR che potete scaricare alla sezione Utilità. Essa permette di cercare stringhe di testo all'interno della ROM. Come esempio utilizziamo la ROM di Final Fantasy III, proviamo a cercare il nome della protagonista Terra. Nella stessa directory mettiamo la ROM e il SearchR. Lanciamo SearchR, che dalla versione 2 presenta una comoda interfaccia, apriamo la ROM, e scriviamo "terra" nel campo "search for:". Come risultato otteniamo: Offset: 0047C0 Se hai giocato a FFIII saprai che quando ti viene chiesto di inserire il nome di un personaggio, il nome di default è proposto tutto in lettere maiuscole. Così i numeri trovati in precedenza corrispondono tutti a lettere maiuscole: 93 = T, 84 = E, 91 = R, 80 = A. Se nella colonna con la scritta "Ascii text" comparirà lo stesso testo di quella "Rel. Text", significa che il testo nella ROM è in ASCII e pertanto è facilmente modificabile con un editor esadecimale. Stessa cosa se si trova A=41. Se invece non trovate niente, tenete in considerazione i vari metodi di compressione e
codifica spiegati più sotto, soprattutto quello a 16 bit. Per le compressioni come il DTE/MTE invece l'unico metodo efficace per scovarle è cercare per esempio una decina di parole, cosi' da riuscire a costruire una tabella. Aprire la ROM in un editor come il Thingy e leggere il testo che avete trovato con le tabelle che avete creato. A questo punto cercate di "intuire" quali sillabe/parole mancano e far corrispondere queste supposizioni ad 1 byte. Per esempio, se nel Thingy vedete le parole "Mario#out", puo' voler dire che il byte # corrisponde al MTE " is ", quindi nella vostra tabella non fate altro che aggiungere "#= is " dove # corrisponde al byte hex (naturalmente il tutto senza le virgolette) Metodi particolari di codifica del testoIl metodo con cui è sistemato il testo cambia da ROM a ROM. Si basano tutte sul sistema delle tile, ma con delle varianti. Vediamole: 1) DTE/MTELo spazio che una cartuccia mette a disposizione è sempre molto poco, e questo gli sviluppatori lo sanno molto bene. Una cartuccia per SNES arriva a non più di 4 Megabytes e considerando che sono decisamente costose, meno spazio occupava un gioco meglio era. Per questo i programmatori delle varie software house sviluppavano potenti routine di compressione dei dati, cosi da risparmiare quanto più spazio possibile. E mettere in crisi i ROM hackers, anche :) La grafica è la parte più consistente, ma esistono metodi di compressione anche per il testo, e si basano
tutti sull'assegnazione di piu' lettere a un solo valore esadecimale. Per sostituire le sillabe, bisogna trovarle all'interno della ROM. Generalmente utilizzano la stessa tabella degli altri fonts, per trovarle potete cercarle col SearchR. Spesso sono separate da un altro byte, ad esempio in Chrono Trigger sono separate da un valore che rappresenta il numero di lettere che compone la sillaba: 02 se la sillaba è di due lettere). In Final Fantasy III invece è il valore esadecimale 7F e tutte le sillabe sono composte da due lettere. Quindi ponendo il caso in cui le tre tile consecutive fossero "he", "it" e "is", bisognerà scrivere he?it?is nella schermata principale del SearchR. L'MTE può presentarsi in diverse forme:
NB: sebbene queste siano le tre varianti con cui più spesso si presenta il MTE ogni gioco è diverso dagli altri e potrebbe usare tecniche di compressione diverse, quindi non prendete per oro colato tutto quello che leggete. Usate la vostra intelligenza e fate esperimenti :) Può capitare che le varie sillabe non abbiano la stessa tabella del testo (ovvero che questi
byte speciali non siano una specie di comando per concatenare più lettere), ma che
in ogni tile doppia siano effettivamente disegnati più caratteri.
Questo genere di tile è generalmente chiamato "squished tiles" e
l'unica soluzione per utilizzarle è fare un hacking della grafica. 2) La codifica a 16 bitNon so se sia il nome esatto per questo metodo, mi sono basato sul readme
del Thingy ^__^ 3) Interleaved Genesis ROMLe ROM per Megadrive in formato SMD hanno una strana disposizione dei bytes nella ROM e di conseguenza anche delle lettere. Per questo motivo, non sono traducibili senza essere prima convertite in formato BIN. Diverse utility (uCON, GenConv, SegaTool) sono capaci di farlo. Ad ogni modo, il SearchR riesce a leggerle de-interlacciandole on-the-fly (la ROM comunque non subirà alcun cambiamento). 4) ByteswapLe ROM per Nintendo64 dumpate con il Doctor64 (formato V64) sfruttano questo sistema. Praticamente i byte nella ROM sono invertiti a due a due (byteswapping), perciò la parola "MARIO " diventa "AMIR O". Procuratevi un'utility per convertire la ROM su Dextrose. - La grafica delle console -Il sistema a tileIl SNES, così come la maggior parte delle console, disegna la sua grafica con il metodo delle tile (mattonelle), ovvero dei rettangolini di pixel che vengono uniti insieme in modo da formare una immagine. L'immagine originale viene scomposta in tasselli che sono memorizzati singolarmente nella ROM, nel momento di mostrare l'immagine a video tali tasselli vengono richiamati e ricomposti attraverso una mappa (tilemap grafica). Ora verrebbe da chiedersi "perchè?". Senza dubbio disegnare le immagini pixel per pixel sarebbe stato più agevole (è il metodo usato dai nostri PC, per dirne una), soprattutto quando è necessario disegnare dei singoli pixel sullo schermo: il motivo fondamentalmente è lo spazio, è possibile riusare in immagini diverse le stesse tile risparmiando un sacco di spazio. Se ad esempio in due schermate abbiamo lo stesso sprite in cui però cambia un dettaglio (che ne so, un buco dovuto a un proiettile in uno sparatutto) è sufficiente memorizzare una sola volta tale sprite, sostituendo semplicemente la tile "bucata" :) C'e' da dire che il metodo delle tile incasina parecchio il lavoro del romhacker (e quando
mai?), perchè spesso si fa fatica a ritrovare le immagini: se volete modificare con un
tile editor il title
screen di un gioco ad esempio, potreste trovare le sue tile tutte affiancate e quindi
lavorare agevolmente, avendo l'intera immagine sotto gli occhi. Le tile però potrebbero anche
stare sparpagliate nella ROM (valle a ritrovare!) o peggio ancora, alcune tile potrebbero
essere utilizzate piu' volte nell'immagine, quindi ritoccandole provochereste modifiche anche
ad altre zone dell'immagine. Qualche spiegazione tecnica, i bitplaneIn che modo può essere utile sapere tutto ciò al romhacker? Per modificare le tile oggi esistono programmi appositi detti tile editor (uno dei migliori è probabilmente il Tile Layer Pro), che permettono di visualizzarle e modificarle direttamente, come se si stesse lavorando con un programma di grafica tradizionale, sono comunque convinto che un minimo di conoscenze tecniche sulle tile faccia sempre bene. Bisogna innanzitutto sapere che una tile viene memorizzata come una stringa di byte (scontato:P), ognuno dei quali rappresenta una riga. Ad esempio: 0 1 1 1 1 1 0 0 -> 7C 1 1 0 0 0 0 1 0 -> C2 1 1 0 0 0 0 1 0 -> C2 1 1 0 0 0 0 1 0 -> C2 1 1 0 0 0 0 1 0 -> C2 1 1 0 0 0 0 1 0 -> C2 0 1 1 1 1 1 0 0 -> 7C 0 0 0 0 0 0 0 0 -> 00 0 = pixel vuoto 1 = pixel pieno Immaginate di guardare questa figura come se fosse "disegnata", vedreste una O. Basta convertire
ogni riga in un numero esadecimale ed si ottiene la stringa da memorizzare nella ROM, in questo
caso 7C C2 C2 C2 C2 C2 7C 00. Un rettangolo come questo è chiamato bitplane (piano di bit).
Come vengono gestiti però i colori? Un metodo come questo permette
solo di disegnare immagini monocromatiche (0=pixel vuoto, 1=pixel pieno) mentre sappiamo bene
che i giochi usano i colori, e tanti anche! La risposta è sovrapporre i bitplane :) 3 3 3 3 3 3 3 3 ------- bitplane 3
3 2 2 2 2 2 2 2 2 ----- bitplane 2
3 2 1 1 1 1 1 1 1 1 --- bitplane 1
3 2 1 0 0 0 0 0 0 0 0 - bitplane 0
3 2 1 0 0 0 0 0 0 0 0
3 2 1 0 0 0 0 0 0 0 0
3 2 1 0 0 0 0 0 0 0 0
3 2 1 0 0 0 0 0 0 0 0
2 1 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Pensate a una tile come a una sequenza di bitplane sovrapposti uno sull'altro, per sapere il
colore di un pixel bisogna leggere i bit sovrapposti su quel punto. Ad esempio, avendo una tile
di 8x8 pixel formata da due bitplane, se voglio sapere il codice del colore per il pixel in alto
a sinistra (quello che i programmi di grafica identificano con le coordinate 0,0), leggerò il bit
in alto a sinistra del primo bitplane e poi il bit in alto a sinistra del secondo bitplane. I
due bit ottenuti sono il colore di quel pixel. Le tile su SNES sono sempre di 8x8 pixel. Le tile di dimensioni diverse di cui parlano altri docs non sono altro che degli "assemblaggi" formati da più tile, ad esempio con 4 tile 8x8 si può ottenere una tile 16x16. Questo è il caso di Go! Go! Ackman, in cui le lettere del testo occupano una tile 16x16 ciascuna. Primi passi, alcuni problemiL'editing della grafica può dare parecchi grattacapi a chi ci si avvicina la prima volta. Alcune delle domande sentite piu' frequentemente sono "come mai i colori nel tile editor non corrispondono a quelli del gioco? Sono tutti sballati!" oppure "cosa è tutta quella roba che si vede tra una zona di grafica e un'altra?". Andiamo con ordine. Innanzitutto bisogna precisare che il SNES cosi come tantissime altre console utilizza le palette per memorizzare i colori, chi smanetta con immagini in formato GIF o PCX saprà bene di cosa si tratta. Il problema di fondo è che per rappresentare un colore RGB sono necessari un sacco di dati, per fare un esempio tangibile prendiamo il formato BMP a 24 bit per PC (le comuni immagini .bmp salvabili col paint di windows). Per ogni pixel vengono salvati tre byte, uno per ogni componente della tripletta RGB (insomma uno per la componente rossa, una per la verde e una per la blu). Con una rapida moltiplicazione si capisce perchè tali immagini hanno sempre dimensioni spaventose! Un'immagine di appena 50x50 pixel occupa 50*50*8=7500 byte! Svariati anni fa venne introdotto il metodo della palette, che permetteva di risparmiare un
sacco di spazio: perchè ripetere tre byte per ogni pixel che deve
essere di un determinato colore? Ora, tutto questo discorso è stato necessario per dire che, per disegnare un'immagine, c'è bisogno dell'immagine stessa (i byte indice che indicano i vari pixel) e della palette, per determinare la giusta colorazione di ogni pixel. Per quale motivo le immagini nei tile editor hanno i colori sballati? Il problema è che i nostri poveri tile editor non hanno la più pallida idea di dove si trovi la palette! Ogni gioco potrebbe memorizzarla in una zona differente e con un metodo differente. Tutto ciò che si può fare è "tentare" di leggere la ROM come se fosse codificata con un determinato metodo grafico (2bpl, 3bpl etc) affibbiandogli una palette inventata, e vedere se si riesce a individuare immagini familiari. Può sembrare di "tirare a indovinare", in effetti è proprio cosi :) Questo causa anche un effetto collaterale: quelle zone confuse e ingarbugliate che compaiono
tra una zona di grafica e un altra all'interno di un tile editor. Che roba è? Un'altra cosa importante da sapere è che una ROM spesso utilizza più di un metodo grafico, per
cui è necessario provare i vari metodi e scandagliare di volta in volta il file. - L'hacking della grafica -La modifica degli sprite ed in generale della grafica in una ROM è particolarmente utile
a chi vuole intraprendere una traduzione dal giapponese, ed è per questo che mi
soffermerò specialmente sulla sostituzione delle tile che compongono le righe di testo.
Il resto della grafica, comunque, è modificabile circa nella stessa maniera. 1) Con il NaGa sprite editorAprite la ROM scegliendola dal menu e premendo ESC. Cercate se riuscite a vedere in una certa zona della ROM delle figure che possono sembrare quelle presenti nel gioco. Se non ci riuscite, premete i tasti 1, 2 o 4 per cambiare metodo di visualizzazione (1Bit per pixel, tiles 8x8, ecc) ed utilizzate le altre opzioni possibili descritte nelle istruzioni di ogni utility (anche se il default del NaGa va bene per le ROM del Gameboy). Tra queste tiles, oltre a quelle che compongono i vari sprite del gioco, sicuramente vi saranno anche i font (lasciate perdere scritte intere come CONTINUE, SAVE, RAFT, SHOP, o altre che sono "disegnate" per intero e non sono sequenze di tile raffiguranti le lettere). Una volta visualizzate, cliccate su ogni tile per modificarla a piacimento. Questo editor scrive direttamente sulla ROM che state modificando. 2) Con il Tile Layer ProAprite la ROM e mettete l'editor in modalità GameBoy cliccando su "View", poi "Format" e poi "Game Boy". A questo punto cercate la zona della ROM dove sono situate le tile. Prendete quelle che volete modificare, copiatele sulla clipboard a destra e modificatele. Una volta modificate, sarà necessario salvare le modifiche cliccando su "File" e poi su "Save", oppure su "Save as..." se volete salvarla senza modificare quella originale. Quella clipboard è molto comoda se si vuole modificare uno sprite le cui tile sono disposte alla rinfusa nella ROM. [NOTA: Le tile contenute nelle ROM per Super Nintendo sono
leggermente più difficili da modificare, perché possono essere codificate in formati
differenti. Consiglio di provare i diversi metodi di visualizzazione se non sono visibili da
subito. In alcune ROM compresse (come Seiken Densetsu 3) la grafica non è visibile in nessun
modo, almeno non con i nostri sistemi. Chi è molto bravo con la programmazione e conosce
l'assembly del SNES può scriversi un decompressore su misura, ma bisogna essere veramente veramente esperti :) Nelle traduzioni del Game boy c'e' un piccolo trucco per scovare facilmente la tabella dei font, il tutto con l'emulatore No$gb. Il trucco consiste nell'aprire il suddetto emulatore, la ROM che si vuole tradurre e giocare finché non compare del testo, a questo punto bisogna premere "Esc" e apparira il menu "Debugger". Una volta qui, clicca sull'opzione "Window" ed entra nel "Tile viewer". Qui potrai vedere gli sprite che stà usando l'emulatore nel momento che hai premuto Esc. Ora con il puntatore del mouse vai sulle tile che contengono le lettere di cui volete sapere il codice. Una volta sulla tile, guardate sul lato destro in basso, ci sara' scritto "Tile Nº --", dove -- corrisponde al codice della tile. In questa maniera si puo' creare una tabella "quasi" completa senza complicazioni. Anche con il NES si puo' usare lo stesso trucco solo che va fatto in una maniera diversa. Come emulatore si usa il Nesticle, caricate la ROM e quando appare il testo premete ALT+P e apparirà "Cpu emulation paused". Qui premete F2 e vedrete una schermata piena di lettere, grafica e altre cose. Una volta qui cercate la lettera A o quella di cui volete sapere il codice, cliccateci sopra e vedrete una finestra con lo sprite che avete scelto, poi, nell'angolo della finestra che e' apparsa, ci sara' una scritta come #?? dove ?? e' il codice hex corrispondente alla tile che avete scelto. In realtà è possibile usare questo trucchetto anche per le ROM Megadrive, usando il
Genecyst. Come al solito apritelo e caricare la ROM, poi premete ALT+P e anche qui apparirà
"Cpu emulation paused". Una volta qui premete la barra spaziatrice e scegliete l'opzione
"View", poi sull'opzione "Patterns" e qui potrete vedere gli sprite che sono in quel momento
sullo schermo. L'unico problema è che non potrete vederne il codice :)))) - La creazione della patch -Per creare le patch da distribuire, si usa normalmente il formato IPS (International
Patching Standard). Per creare le vostre patch IPS dovete procurarvi il programma SnesTool.
Una volta avviato usate l'opzione "Create IPS", selezionate la ROM "genuina"
(quella che non avete modificato) e poi la ROM modificata. Il programma costruirà il
file IPS con tutte le differenze che avrà il nome dell'ultima ROM selezionata.
Inoltre non guasterebbe un bel file batch che, prima crea una ROM di backup, e poi
lancia ips con la vostra patch. - FAQ -Q: Ho rinominato la ROM in formato TXT, perché non vedo il testo? (domanda realmente
posta) Q: Ora ho trovato la tabella dei font, ma cosa me ne faccio?!? Q: Perché non riesco a trovare certe parole col SearchR o le parole compaiono
"troncate"? Q: Il SearchR non trova alcuna parola! Perché? Q: Perché il SearchR trova corrispondenze diverse cercando la stessa parola (nel senso
che, cercando una parola e trovandone varie corrispondenze nella ROM, trova
che la lettera A risulta associata a diversi numeri esadecimali)? Q: Come mai cercando la stessa parola con le maiuscole e con le minuscole ottengo
gli stessi risultati? Significa che quella ROM utilizza allo stesso modo maiuscole e
minuscole? Q: Posso modificare le ROM in ASCII direttamente con un editor di testo come il
WordPad? Q: Voglio ottenere più spazio nella ROM! Come devo fare? Q: Ho tradotto una ROM del Gameboy, ma quando faccio partire l'emulatore dà un errore
di "checksum". Che fare? Q: Il SearchR non parte! Quando lo avvio scrive solo "Unable to open 640x480x8bpp
VESA2L screen". Q: Ok, ora parte, ma se clicco su GFX EDIT scrive "Unable to open 320x240x8bpp
VESA2L screen". Eppure ora la mia scheda supporta i drivers VESA. Q: Le patch di traduzione sono legali? Bene, se ci sono domande che riteniate vadano aggiunte a queste FAQ o se semplicemente avete ulteriori problemi, scriveteci specificando di aver letto la presente guida e dando informazioni precise di cosa non riuscite a fare. |
 |
 |