Autori: D-Chan, mickey, Fraka, Duke, BGies, MJL, _Ombra_, Sephiroth 1311
Versione: 1.0
Ultimo aggiornamento: 19/09/2010

Se siete giunti fino a qui, si spera che abbiate letto la prima parte della guida. Se non l'avete fatto, non cercate di barare e tornate indietro a leggerla. ;)
Mentre la prima parte della guida ha come obiettivo quello di essere un avvio "generico" al romhacking, questa seconda parte si rivolge invece a chi intende lavorare a traduzioni di ROM per NES/SNES/GBA, ecc.
Non verrà trattato l'aspetto testuale, di cui si è già discusso, se non per un breve accenno ai puntatori. Le operazioni di base sono tutte descritte nella guida principale. Detto ciò,
buona lettura!

Abbiamo dato qualche accenno al concetto di puntatore nella guida base. Questi accenni potrebbero però non esservi sufficienti se intendete lavorare su una ROM SNES. Vi verranno però in aiuto le guide scritte da mickey e da Duke. Non le riportiamo direttamente in questa pagina web per non aumentare eccessivamente le dimensioni di questo paragrafo, oltre al fatto che argomenti così importanti meritano di avere una guida tutta per loro. ;)
Cliccate qui per la guida ai puntatori hirom, oppure qui se siete interessati a quella dei puntatori lorom.

Capita spesso che durante una traduzione manchi lo spazio a disposizione del traduttore. E qui potrebbe essere consigliabile procedere all'espansione della ROM sulla quale si sta lavorando. È bene dire che una tale operazione si può effettuare sulle ROM dello SNES (inutile provarci con una ROM del NES perché crasherebbe inesorabilmente!).

La prima cosa da dire e che l'espansione può essere fatta agevolmente solo sulle cosidette LoROM (si rimanda alla nostra guida sui puntatori lorom [link qui] per capire il perché). Qui basta dire che se aggiungiamo un solo byte ad una HIROM TUTTI i puntatori si spostano e quindi andiamo incontro ad un crash della ROM stessa.

Ogni bravo hacker in erba avrà notato che, aprendo una ROM dello SNES, la sua parte iniziale è sempre formata da una sfilza di 00 (almeno per la maggior parte). Questo è il cosiddetto HEADER e si consiglia di non toccarlo se non si sa bene quello che si fa. In ogni caso scorrendo la ROM si noteranno molte parti in cui viene ripetuto un solo byte (FF o 00). Non ci crederete ma è tutto spazio libero. L'espansione non fa altro che aumentare questo spazio. Naturalmente ciò significa che aumenteranno anche le dimensioni della ROM. Tutto ciò che bisogna fare è aggiungere direttamente una serie di byte FF o 00 e poi sovrascriverli con il testo (questo metodo l'ho usato con la traduzione di Final Fantasy 6 ma anche con la traduzione del kernel.bin di Final Fantasy 7 PC e PSX).

Così semplice mi direte. Ebbene sì, facendo un po' di attenzione. Lo spazio che aggiungete deve essere sempre multiplo di 32kb, o di Ox8000 hex byte, o di un banco (se avete letto la guida ai puntatori lorom che vi ho linkato su, sapete perché). Inoltre vi consiglio, se decidete di espandere una ROM, che la grandezza della ROM espansa sia multipla di 4Mbit (quindi: 4Mbit, 8Mbit, 12Mbit, ecc.). Naturalmente sarebbe meglio avere (o programmarsi) un programma che faccia questo lavoro per noi. Comunque esistono alcuni programmi che potete provare per vedere se funzionano con la ROM sulla quale state lavorando. Uno piuttosto vecchiotto (è del 1999 e funziona sotto DOS) è Jabba che trovate su Romhacking.net. Un altro veramente ben fatto è Lunar Expand di FuSoYa (lo trovate sul suo sito) che ha una pregevole interfaccia grafica.

- La grafica delle console funzionanti a tiles -

Il sistema a tile

Il 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'è 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 più volte nell'immagine, quindi ritoccandole provochereste modifiche anche ad altre zone dell'immagine.
Il primo caso è teoricamente risolvibile sfruttando le mappe usate dalla unità grafica per ricomporre le immagini (le tilemap menzionate all'inizio) in modo da rintracciare le tile e ricomporre l'immagine al volo, è comunque una tecnica per programmatori SNES esperti e per quanto ne so, non è mai stata implementata.

Qualche spiegazione tecnica, i bitplane

In che modo può essere utile sapere tutto ciò al romhacker?
La modifica grafica ha parecchi utilizzi, il più comune e forse anche il più utile è il cambio del font del gioco, infatti le lettere sono immagini a tutti gli effetti e quindi sono memorizzate nella ROM sotto forma di tile. Cambiare il font è un'operazione simpatica quando quello originale non è di vostro gradimento, mentre diventa indispensabile se si traduce un gioco dal giapponese, poichè bisogna inserire nella ROM le lettere del nostro alfabeto. È possibile comunque modificare qualsiasi oggetto grafico, come il title screen per metterci la firma del traduttore ;) oppure sostituire lo sprite di Super Mario con quello di Sonic e altre cose simili. ^_^

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 :)
Per spiegare meglio uso un esempio preso direttamente dal doc di Peekin:

                    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.
Il modo in cui i byte dei vari bitplane sono disposti nella ROM varia a seconda del metodo grafico utilizzato, per i quali vi rimando alla già citata guida di Peekin sulla grafica del SNES, che a mio parere è la più completa a riguardo.
Torniamo invece ai colori, se siete riusciti a capire il metodo dei bitplane sovrapposti potreste essere giunti da soli a una importantissima considerazione: il numero dei colori di una tile dipende dal numero di bitplane. Con tre bitplane, il codice di ogni colore è formato da 3 bit e dunque si hanno a disposizione 2^3=8 colori, se fossero stati 4 avremmo avuto 16 colori e via via fino a un massimo di 8 bitplane, per un totale di 256 colori.

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 problemi

L'editing della grafica può dare parecchi grattacapi a chi ci si avvicina la prima volta. Alcune delle domande sentite più 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?
La palette è una specie di tabella contenente un numero limitato ma arbitrario di colori (la palette più classica ne ospita 256), per ogni pixel dell'immagine viene usato UN SOLO byte per indicare il colore, questo byte altro non è che un indice da usare per selezionare un colore dalla palette. La tripletta RGB viene memorizzata una sola volta ed è "richiamata" per ogni pixel che si vuole fare di quel colore. Ingegnoso, no?
Questo sistema si castra da solo, però. Infatti la palette deve avere dimensioni limitate (come detto poco fa, solitamente non più di 256 colori) perché altrimenti non e' più sufficiente un solo byte per fare da indice e tutta la tecnica si rivela inefficace. Questo spiega anche perché provando a salvare una fotografia in formato GIF, l'immagine si impoverisce di colori: vengono limitati a 256, contro i 16 milioni del formato BMP ^_^
Per una console è comunque un limite più che accettabile, tanto che con soli 256 colori si riescono ad ottenere giochi dalla grafica splendida. (Per evitare malintesi, bisogna precisare una cosa: 256 è il numero di colori visualizzabili contemporaneamente a video, ma il SNES potenzialmente ne sa gestire un numero molto maggiore!)

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", ed 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 è?
Il tile editor non ha la più pallida idea di dove si trovi la grafica del gioco, si limita a leggere L'INTERA ROM come se fosse un immenso file grafico. Cosi vengono interpretate come grafica anche cose come programma, sonoro, archivi di dati etc etc, tutta questa roba va a formare le misteriose zone "casinose" di grafica. ;)

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.
Non è certo il caso del Gameboy ^_^ dove la grafica è TUTTA da 2 bitplane (guarda caso il Tile Layer Pro ha chiamato la modalità a 2bpl "modalità gameboy"). Nel SNES il formato più usato è quello a 4bpl, con cui troverete la maggior parte degli sprite. I title screen possono arrivare anche a 8bpl, mentre i caratteri del testo sono memorizzati quasi sempre a 2bpl. Se ci pensate ha senso, 4 colori sono più che sufficienti per visualizzare il testo e una eventuale ombreggiatura. Quando riconoscete immagini che però appaiono leggermente distorte o confuse provate a visualizzarle con un'altra modalità, potreste semplicemente aver sbagliato quella.

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 ci sofferemo specialmente sulla sostituzione delle tile che compongono le righe di testo. Il resto della grafica, comunque, è modificabile circa nella stessa maniera.
Per sostituire le tile che costituiscono la grafica nella ROM, bisogna utilizzare un editor di tile. I più famosi possono essere scaricati dalla sezione utilità. Effettivamente, il capitolo relativo alle tile è già stato completato e ulteriori informazioni possono essere trovate nei readme di ogni tile editor, comunque faremo una piccola spiegazione prendendo ad esempio la ROM di "Zelda - Link's Awakening" per Gameboy (che è già in inglese, ma essendo una ROM per GB è particolarmente facile da modificare). Come programma utilizzeremo sia il Tile Layer Pro che il più famoso ed utilizzato editor di tiles (e non solo), il Tile Molester.

1) Con il Tile Layer Pro (TLP)

Aprite 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 :)
Un esempio di questo tipo di hacking lo trovate con il programma di FuSoYa, che abbiamo usato per tradurre alcune parole e parti grafiche di Zelda: A Link To The Past.]

2) Con il Tile Molester

Innanzitutto, assicuratevi di avere il Java installato sul vostro PC, altrimenti non potrete eseguire il programma. La prima grossa differenza che noterete rispetto al TLP è sicuramente la mancanza della clipboard per il riordino delle tiles. Questo è l'unico aspetto in cui il Tile Molester perde il confronto con il TLP.
Dove invece il TM vince a man basse è nella versatilità. Esso è in grado di gestire un enorme quantitativo di formati grafici, oltre a poter visualizzare sia tiles che grafica RAW. Il menu che dovrete conoscere a menadito è quello "View". Una volta apertolo, la vostra attenzione dovrà focalizzarsi sulle opzioni Code e Mode.
Aprite innanzitutto il menu "Mode": vi appariranno le opzioni 1 Dimensional (attivata di default) e 2 Dimensional. Se intendete lavorare su una console che sfrutta i tiles, lasciate impostato 1 Dimensional. Se dovete invece lavorare su grafica RAW di console più avanzate, impostate 2 Dimensional.
Potrete invece sbizzarrirvi con il menu "Code": Tile Molester supporta codifiche dall'1bpp al 32bpp! Molto utile è specialmente la 15bpp RGB, utilizzata abbastanza spesso per la grafica della Playstation. A parte questo, il resto delle opzioni non differisce granché dagli altri editor grafici. Vi sono opzioni per disattivare/attivare la griglia delle tile, per esportare la grafica in bmp/png, modificare la palette, et caetera.

Nelle traduzioni del Game boy c'è 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 apparirà il menu "Debugger". Una volta qui, cliccate 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 sarà scritto "Tile Nº --", dove -- corrisponde al codice della tile. In questa maniera si può creare una tabella "quasi" completa senza complicazioni.

Anche con il NES si può 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 sarà 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!
Se qualcuno sa' come fare, scrivete. :)

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 LunarIPS, che trovate nella nostra pagina delle utilità. Una volta avviato, usate l'opzione "Create IPS patch", selezionate la ROM "genuina" (quella che non avete modificato) e poi la ROM modificata, decidete infine come chiamare la patch. Il programma costruirà il file IPS con tutte le differenze riscontrate tra il file originale e quello da voi modificato.
Attenzione: il formato IPS può essere utilizzato solo per ROM di dimensione non superiore ai 16MB. Se avete lavorato su un qualche file più grosso, utilizzate il Delta Patcher di Phoenix per creare la vostra patch; trovate il programma nella nostra sezione Utilità. Ci sono anche formati di patching alternativi, come l'UPS, ma le xdelta sono ormai comunemente utilizzate.
Adesso siete pronti a distribuire la vostra patch! Createvi un bello zip/rar/7z con:

• Il programma da usare per patchare la ROM (Lunar IPS o Delta Patcher)
• Un bel README.TXT
• La vostra patch (Ma dai?? :) )

Nota importante: lo ZSNES e lo Snes9X supportano un sistema di patching automatico che patcha temporaneamente la ROM. Basta mettere il file IPS nella directory dei salvataggi, dopo averla eventualmente rinominata con lo stesso nome della ROM. L'unico formato supportato per il patching automatico è l'IPS.
Scrivete anche questo nel readme se traducete una ROM per SNES.

Speriamo, con questo documento, di aver fatto chiarezza sull'argomento dei puntatori e su quello della grafica funzionante a tile. Tenete bene presente che anche alcune console moderne, quali il Nintendo DS, a volte utilizzano le tile per costruire la grafica. Non dovete perciò considerare le tile un qualcosa del passato!
In ogni caso, dopo aver letto ed appreso queste prime due guide, dovreste essere in grado di effettuare una più che buona traduzione di un videogioco per le grandi console a 8/16 bit del passato. Certo, vi sono molti argomenti avanzati che non abbiamo trattato, ma il nostro scopo è quello di fornire una guida di base. :)
Se intendete lavorare su un gioco delle console del passato, potete anche fermarvi qui. Se invece siete curiosi su come si lavora su giochi che utilizzano un file system per organizzare i propri dati (tra cui i giochi per Playstatio e per DS), vi consigliamo di dare una lettura anche alla prossima guida, che tratterà di argomenti molto diversi da quelli finora trattati.