Salve a tutti,
Sono bell1-1010 mi ricorderete per film del tipo "che sbattimento questo rom hacking" e "rom hacking, ancora non ci capisco una mazza"..
Scherzi a parte.
Sono anni che tento di imparare a tradurre un gioco come si deve, ma oltre alle piccole cose tipo trovare la table, modificare i caratteri (graficamente parlando), tradurre il testo nella rom non sono in grado di fare nient'altro...
il mio desiderio sarebbe riuscire a capire anche solo un poco i puntatori (che nonostante le guide mi restano incomprensibili), Wvf, e compressioni varie, cosa che per quanto mi sforzi non riesco proprio a comprendere.
Quasi sicuramente i miei problemi sono alla radice dato che mai imparai la programmazzione.
Quindi vi volevo chiedere per favore ditemi cosa dovrei imapare per capirci qualcosa di più...
se sapete consigliarmi una buona guida per imparare il linguaggio C o un gioco semplice per capire i puntatori o il wvf,
Per favore help me..... :ciaotriste: :ciaotriste: :ciaotriste:
per iniziare non c'è niente di meglio che la guida del C di html.it:
http://programmazione.html.it/guide/leggi/32/guida-c/ (http://programmazione.html.it/guide/leggi/32/guida-c/)
Innanzitutto devi chiederti "cosa m'interessa?".
Hai detto di avere già delle basi. Dovresti sfruttare quelle (e può aiutarti il fatto che, contrariamente all'opinione di alcuni, NON tutti i bei vecchi giochi sono stati tradotti).
Una volta tradotto un gioco secondo le tue competenze, allora dovresti voler imparare di più. Ma al tuo livello (che poi è praticamente il mio) è inutile e frustrante voler imparare tutto.
Vuoi un consiglio? Prova Dragon View per SNES. Non ho la minima idea delle sue specifiche tecniche, ma è un gioco piuttosto divertente. Prima provalo, e poi attaccalo con un Editor di tua scelta.
Sentirsi rispondere sempre "c'è la guida, leggila" è frustrante, ma pochi hanno voglia d'insegnare direttamente in questo campo, e non li biasimo (e fidati, dare consigli anche del cazzo d'informatica a distanza è la scomposizione molecolare dei coglioni).
Personalmente quando ho iniziato mi son trovato un gioco in ASCII e l'ho tradotto senza puntatori. Manco sapevo cosa volessero dire.
ehehe confortante mog,
Io ho già tradotto Metal Gear per nes senza puntatori o cose simili, solo che vorrei per esempio riuscire a comprendere meglio il suo funzionamento...
la cosa frustrante non è tanto leggere una guida, sono sempre ben lieto di farlo ma a volte non capire di che si sta parlando che ti lascia uno sconforto totale...
cmq non ho problemi nel cercare giochi da tradurre, anche se ora che me lai consigliato non vedo l'ora di provare Dragon View...
Ps: se scelgo un gioco da tradurre posso gia metterlo nella sezione progetti in maniera da avere in qualche modo un minimo di supporto morale?
Oi, qualcuno ha nominato i Vwf (Wvf pare il nome di un programma per proteggere i panda :P), la mia specialità. :D Esattamente cos'è che non capisci? Se mi dai qualche indicazione più precisa posso anche aiutarti.
CitazionePs: se scelgo un gioco da tradurre posso gia metterlo nella sezione progetti in maniera da avere in qualche modo un minimo di supporto morale?
Solo se ci tieni regolarmente informati. :w00t:
in effetti mi suonava strano.....
Allora dato che in molti (compreso io) abbiamo iniziato e mai terminato Mistic Quest per gb ora ci penso io..
se non ricordo male aveva il dte come unico problema
al diavolo anche che hanno fattto un remake in italiano per gba
l'ho tanto amato sul game boy per poi emularlo su psp per poterlo finire (dato che il gb è diventato il televisore nella casa per le bambole di mia sorella).
Tranquillo Gemmo la guida credo sia chiara il problema è il mio che di programmazione non capisco ancora(per poco perchè ora giù con la guida)molto.
Appena potrò permettermelo ti chiederò aiuto per un vwf su gb dato che sembra un'ardua sfida... :biribiribu: :biribiribu: :biribiribu:
Asm z80, sfida ardua. :P Saprò due opcode in croce di quel processore. xD Però non dovrebbero esserci problemi a darti delle dritte su come arrangiare un codice decente per stampare a larghezza variabile. :idea:
gia e tieni presente che ti stresserò per capire come aumentare i caratteri di inserimento del nome, come hai fatto per CC.... :P :P
Dipende dal gioco. Chrono Cross ha spazio a morire in ram per farlo, mentre con altri giochi è una faccenda abbastanza diversa. Con FF6 sono stato costretto a usare una codifica a 6 bit per lettera, anche perché non c'era spazio per mettere i caratteri extra altrove. :/
Se ho imparato io, che ho come base un Liceo Classico e un corso di basic in prima media..
Consiglio personale: inizia dal Nes. Tanti giochi da tradurre, moltissimi tool per farlo.
E nonhai sarcazzi vari per mancanza di spazio su schermo, come potresti averli sul GameBoy, e te lo dice un che dispera dal tradurremai un giorno Dragon Quest III per questo motivo.
Scusa ma qual'è il problema dello spazio su schermo?
L'inglese ha generalmente bisogno di meno caratteri in un enunciato rispetto all'italiano. Ha a che fare con la natura della lingua.
Ergo: talvolta far entrare una frase traducendo giochi vecchi è un problema.
O ci rimugini e riesci a parafrasare barra sfangartela con una buona conoscenza dell'italiano.
O usi i puntatori (dove possibile)
O t'impari l'ASM della console e calpesti le limitazioni tecniche come un Bigfoot 4x4 ridendo come un cattivo dei fumetti.
ehehehhehehehe
diciamo il punto uno si può anche fare...
per il due mi arrangio
per la terza opzione attendo che venga Padre Pio a farmi visita....
Ps: illuminante l'immagine del 4x4....
Per il terzo metodo ci vuole solo esperienza, ma una volta che afferri il meccanismo posso assicurarti che è un passo facilissimo, come cambiare del testo con table sotto Translhextion. XD L'unica difficoltà è che alcuni giochi richiedono modifiche a destra e manca e ti costringono a perdere parecchio tempo a cambiare moltissimo codice, vedi Dracula X. >_>
Cmq prima di apprendere l'arte oscura dell'asm credo sia meglio imparare a programmare in "c" o sbaglio?
anche perchè mi sto stampando la guida....
Più che altro devi imparare a ragionare come un programma. Il linguaggio non credo conti più di tanto, anche se partire dal c potrebbe darti una spinta in più, ma non è detto. In fondo c'è tanta gente che inizia direttamente dall'asm senza nemmeno essere passato per un qualsiasi linguaggio ad alto livello. :D
CitazionePiù che altro devi imparare a ragionare come un programma.
più che altro come un programmatore... non importa da dove inizi, non c'è un'unica strada per imparare a programmare. cosa devi fare? perfetto, rimboccati le maniche, studia e prova, prova e riprova. che sia assembler, che sia c, che sia java se un linguaggio corrisponde alle tue esigenze lo usi.
una delle risposte più apprezzate nei colloqui è: "il linguaggio di programmazione è solo un mezzo". :P
Citazionepiù che altro come un programmatore...
Non esattamente, o almeno la risposta cambia a seconda delle esigenze. Per capire il codice di un gioco si deve capire esattamente cosa fa una routine e anche conoscendo come si comporterebbe un programmatore non è detto che si arrivi a capire cosa fa il programma, soprattutto se c'è un compilatore di linguaggio ad alto livello dietro. La domanda "e questo come potrebbe funzionare o come si attiva?" ti dice nulla?
Già che ci siamo: libri sull'ASM da reperire?
Jeg ma non ti è sufficente la guida sul sito?
l'ho trovata relativamente (sottolineo relativamente)semplice.... :D :D
qualcuno ha parlato di gameboy e vwf? :brucelee:
http://www.romhacking.it/downloads/guide/e...ida_gbasmhk.doc (http://www.romhacking.it/downloads/guide/ev0/guida_gbasmhk.doc)
per i puntatori dai una occhiata qui
http://www.zuminator.altervista.org/guide/...hackvol1ZTG.rar (http://www.zuminator.altervista.org/guide/DarkDreAmromhackvol1ZTG.rar)
(io ho cominciato a programmare direttamente su gb-z80...
http://www.romhacking.net/forum/index.php?...msg7583#msg7583 (http://www.romhacking.net/forum/index.php?PHPSESSID=6010fff3bca9f007e57dd2b31e042a28&topic=590.msg7583#msg7583) )
Per quanto mi riguarda l'asm dello Z80 è uno dei più facili in assoluto. Innanzitutto è di tipo CISC (e questo non può che farmi molto piacere) e poi segue molto da vicino quello per architetture x86 (pur in maniera MOLTO più semplificata), che io tratto con maggiore frequenza.
Poi, ovviamente, non è necessario sapere il c per sapere l'assembly (altrimenti il primo compilatore c come avrebbero fatto a scriverlo?). Invece, è abbastanza utile avere qualche nozione di assembly quando si programma con linguaggi di un certo livello. Questo per motivi di ottimizzazione, di stesura del codice etc.
C'è da dire cmq che in genere il c ha diverse analogie rispetto al corrispettivo codice assembly (per lo meno con l'asm di tipo CISC) per cui io spesso e volentieri cerco di convertire mentalmente il codice da asm a c (dato che che in quest'ultimo linguaggio tutto diventa molto più "accessibile"). Tempo fa avevo pure scritto una specie di pseudo-guida che trattava in maniera relativamente approfondita l'assembly x86 e quello per lo Z80 (con elencate le differenze tra quel tipo di asm e quello nei processori del gameboy). Alla fine era una specie di traduzione/rielaborazione di alcuni documenti che avevo trovato in giro sulle varie architetture però c'era anche un esempio (secondo me carino) su una rom GB per imparare un po' a capire quel tipo di asm (si trattava proprio di un esercizio di reversing). Purtroppo con lo spostamento del sito ad un nuovo dominio ancora non ho avuto la voglia di spostare tutto il materiale e rimetterlo online.
Per capire i puntatori, il C non serve... o almeno... non serve per capire come modificare i puntatori in una rom. Questo per un semplice motivo.
Fai conto di considerare un puntatore come una specie di freccia. Le informazioni interessanti di questo pseudo-vettore sono il punto di applicazione (il punto di partenza), la lunghezza di questo vettore e la fine di questa freccia (ossia il punto di arrivo).
Partenza (Lunghezza) Arrivo
-------------------------------------------------->
In un linguaggio di programmazione viene considerato esclusivamente il punto d'arrivo (perchè è l'unica cosa che serve per far andare il programma), per altro in maniera piuttosto implicita. Alla fine poi il punto di arrivo è calcolato come la somma dell'indirizzo di partenza con la lunghezza, ma tutto ciò viene fatto in maniera completamente trasparente. Tieni conto che poi in altri linguaggi, tipo Java, i puntatori manco esistono come tipo di dato e sono totalmente impliciti nel linguaggio.
Quello che invece più probabilmente interessa a te è conoscere gli altri due parametri. Il punto di partenza non ha un vincolo preciso. Può essere determinato dalle specifiche della rom o può essere stabilito all'interno del codice stesso. La lunghezza in genere invece è sempre espressa da qualche parte all'interno della rom. È ovvio poi che, sapendo il punto di arrivo e la lunghezza è possibile risalire al punto di partenza e non ho intenzione di scrivere come "modificare" i puntatori anche perchè il tuo problema hai detto che è "capirli". Una volta capiti avrai tutto il tempo per fare le dovute prove e sbatterci la testa sopra.
Quello che ho scritto sopra è in pratica l'implementazione pratica di un puntatore (astraendo tutto ad offset e byte).
Se ti può essere più semplice capirlo come concetto puoi pensare ai puntatori come un array informatico (spero tu sappia cos'è... in caso contrario leggilo sulla guida che ti sei stampato). [Infatti in c è possibile anche dichiarare dei puntatori e poi utilizzarli direttamente e nello stesso modo degli array, tanto per far capire che i due concetti non sono poi così distanti.]
Ecco, fai conto la tua variabile array si chiami "memoria" e la variabile "index" sia appunto l'indice di questo array. Si ha una cosa di questo tipo: memoria[index]
Beh, questo index è in pratica un puntatore a tutti gli effetti. Se ci rifletti un po' su riuscirai a cogliere l'analogia.
È ovvio che tutto quello che ho scritto è un po' sintesi di tutto il concetto e vengono fatte anche alcune approssimazioni che nemmeno ho esplicitato (ma mica volevo scrivere una guida... volevo solo rispondere ad un post), ma in linea di massima tutto dovrebbe essere corretto. Poi magari in alcune guide si adottano ulteriori semplificazioni (con esempi) ed è ancora più chiaro, ma qua io ho cercato di mantenere un certo rigore tra concetto in sè ed implementazione dello stesso (in maniera volendo un po' alternativa, così da vedere se in questo modo è più chiaro).
Per i font a larghezza variabile è inutile scrivere qualcosa in un topic. Ti rimando alle guide specifiche e ti consiglio di appoggiarti a qualche tutorial e a 2-3 esempi pratici.
Per quanto riguarda le compressioni invece... non c'è una regola per "capirle". Sono algoritmi. Li leggi e cerchi di capire perchè funzionano (magari facendoti un debug mentale o su un foglio di carta con qualche esempio). Ad esempio la compressione huffman mi pare piuttosto semplice da capire perchè riesce a comprimere. L'unica difficoltà lì è capire i concetti fondamentali dell'informatica, come gli alberi e com'è sfruttato l'albero in quel particolare algoritmo.
Infine, per rispondere a "Già che ci siamo: libri sull'ASM da reperire?", se sei abbastanza pazzo puoi cercare "The Art of Assembly" che è un tomo gigante da centinaia di pagine, rigorosamente in inglese e rigorosamente su asm x86. Ma in quella bibbia viene sviscerato quasi tutto quello che può essere interessante riguardo all'assembly x86 e all'asm in generale, con consigli, riflessioni ed osservazioni, esempi a palate ed anche una guida che ti insegna ad usare il compilatore MASM, che rimane forse il miglior compilatore assembly x86 sulla piazza. È uscita anche la versione per compilare asm x64, ma quello ancora non l'ho provato.
Per le compressioni (o almeno la base) c'è la mia guida :w00t: