Sorgenti rom pokemon Opzioni

[orochimaru 91]

Ciao ragazzi , sono nuovo , volevo sapere se c'è un modo per ricavare i sorgenti da una rom gba(pokemon verde foglia o pokemon rosso del 1996).....
(Ho anche il gioco originale)
Grazie

[batblaster]

Cavolo ne ho lette di minchiate nella mia vita ma quelle che ho visto in questa discussione sono veramente il massimo...

Dalla più semplice:

Il Visual Basic è un ottimo linguaggio di programmazione ed offre un marea di opportunità, ci ho scritto tools di conversione e tools grafici che ancora usiamo qui in azienda.

Codewarrior non è solo un compilatore ma è una interfaccia IDE che i programmatori usano per scrivere codice sorgente e per pilotare il compilatore C/C++. L'iterfaccia è generalmente sempre la stessa sia che sti programmi un gioco PS2 che un gioco Wii o uno DS. Questo per rendere più facile ai programmatori la vita, nulla di più... La miglior interfaccia, anche se per vari motivi uso Codewarrior, è quella del Microsoft Visual Studio.

Una procedura di reverseengine di un programma C/C++ è abbastanza difficile anche perchè non c'è scritto da nessuna parte a che livello di ottimizzazione l'autore ha compilato il sorgente , la stessa riga

"if(a==" con livelli di ottimizzazione diversi potrebbe essere compilata diversamente... E' un esempio e non credo abbia effetto per un semplice comando ma di sicuro in maniera più complessa.

Il codice generato da qualsiasi compilatore ,se la versione è la stessa, è praticamente idendito... Se scrivo codice a casa mia con GCC 3.0 sarà uguale a chiunque altro scriverà con GCC 3.0

Il codice generato è sempre in assembler che verrà a sua volta assemblato per generare un eseguibile che sia DS/PC o altro.

Per programmare i giochi in 3D non serve assolutamente doversi scrivere un engine 3D, ci sono decine di engine gratuiti nel mondo basta solo sapere come usarli.

I giochi 3D dei pokemon sarebbero venuti di sicuro più piccoli come dimensioni di cartuccia delle versioni 2D perchè il 3D occupa molto meno spazio ma il vero motivo della scelta lo sa solo nintendo..

Il DS non è affatto potente come il N64 in numero di poligoni renderizzabili in un secondo ma ha dalla sua la maggiore Vram che ha permesso di camuffare le mancanze in MARIO 64 DS. Avendo più Vram del N64 molte cose le si è migliorate li.

Se fosse così facile recuperare i sorgenti i cinesi avrebbero fatto di tutto e di più. Fortuna vuole che una volta compilati non si torna indietro, almeno per i linguaggi cosiddetti ad alto livello. Se il gioco è scritto in ASM puro allora è molto molto comprensibile e quindi anche facile da capire , per una persona esperta.

La Nintendo la Capcom e la Konami usano una sorta di compilatore C gia dai tempi dello snes dove tutti gli altri scrivevano i giochi in asm mentre loro ottenevano ottimi risultati con questi macro linguaggi. Come lo so ? Lo so perchè avendo programmato anche su SNES so e sapevo come funzionava la macchina.

Sono disponibile per domande se a qualcuno può interessare avere chiarimenti.

@ Dragon Chan: Veniamo più o meno dalla stessa era videoludica , la persona che hai citato è ed era brava ed ha sempre avuto la mia massima stima ma secondo me tu la gente brava non la ricordi più, gente che oggi solo in pochi ricordano purtroppo anche se sono quelli che sul moderno qualcosa di buono hanno fatto e fanno ancora. Es. Presidente di Bizarre Creation , Project Gotham Series x Microsoft, ne ha fatta di strada dal vecchio Killing Game Show. Il gruppo conosciuto come Silents (Moltissimi megademo) che fondò Digital Illusion che è poi diventata parte di EA. Ce ne sta di gente.

[SuperElf]

Cavolo ne ho lette di minchiate nella mia vita ma quelle che ho visto in questa discussione sono veramente il massimo...

Dalla più semplice:

Il Visual Basic è un ottimo linguaggio di programmazione ed offre un marea di opportunità, ci ho scritto tools di conversione e tools grafici che ancora usiamo qui in azienda.

Codewarrior non è solo un compilatore ma è una interfaccia IDE che i programmatori usano per scrivere codice sorgente e per pilotare il compilatore C/C++. L'iterfaccia è generalmente sempre la stessa sia che sti programmi un gioco PS2 che un gioco Wii o uno DS. Questo per rendere più facile ai programmatori la vita, nulla di più... La miglior interfaccia, anche se per vari motivi uso Codewarrior, è quella del Microsoft Visual Studio.

VB, giusto per dirtene una delle tante, è utilizzato per sviluppare collaudi funzionali con AtosF su architetture ICT o FCT Spea (azienda leader del settore) ed è preferito a prodotti importanti come LabView o ai normali sorgenti simil-Ladder.

Visual Studio è la migliore per te, io per esempio preferisco le Ide Borland.
Per il testing o per il vision&motion preferisco invece Labview
Comunque de gustibus.

Una procedura di reverseengine di un programma C/C++ è abbastanza difficile anche perchè non c'è scritto da nessuna parte a che livello di ottimizzazione l'autore ha compilato il sorgente , la stessa riga

"if(a==" con livelli di ottimizzazione diversi potrebbe essere compilata diversamente... E' un esempio e non credo abbia effetto per un semplice comando ma di sicuro in maniera più complessa.

Questa proprio non riesco a capirla
cmq cos'è il reverse engine? un motore che gira al contrario?

Il codice generato da qualsiasi compilatore ,se la versione è la stessa, è praticamente idendito... Se scrivo codice a casa mia con GCC 3.0 sarà uguale a chiunque altro scriverà con GCC 3.0

Il codice generato è sempre in assembler che verrà a sua volta assemblato per generare un eseguibile che sia DS/PC o altro.

La definizione di eseguibile è aggettivo di "file...", quindi file eseguibile si differenzia da non eseguibile, per esempio file di testo, audio ecc.

Su ds non si parla di eseguibili ma di rom, elenco ordinato di byte inseriti SEMPRE nelle stesse locazioni di memoria, visto che non c'è tra l'altro un file system. Ciascun byte rappresenta un OPCODE che a sua volta identifica un istruzione Assembler e le eventuali variabili in gioco.
Talvolta degli stream (sinonimo di file) sono inseriti nella Rom del gioco in questione, assegnandogli un area di memoria ben precisa, con un inizio e una fine. Questo accrocchio di file system è gestito direttamente dal sorgente principale. Mi riferisco in questo a sprite, texture e quant'altro.

Per programmare i giochi in 3D non serve assolutamente doversi scrivere un engine 3D, ci sono decine di engine gratuiti nel mondo basta solo sapere come usarli.

I giochi 3D dei pokemon sarebbero venuti di sicuro più piccoli come dimensioni di cartuccia delle versioni 2D perchè il 3D occupa molto meno spazio ma il vero motivo della scelta lo sa solo nintendo..

Il DS non è affatto potente come il N64 in numero di poligoni renderizzabili in un secondo ma ha dalla sua la maggiore Vram che ha permesso di camuffare le mancanze in MARIO 64 DS. Avendo più Vram del N64 molte cose le si è migliorate li.

Se fosse così facile recuperare i sorgenti i cinesi avrebbero fatto di tutto e di più. Fortuna vuole che una volta compilati non si torna indietro, almeno per i linguaggi cosiddetti ad alto livello. Se il gioco è scritto in ASM puro allora è molto molto comprensibile e quindi anche facile da capire , per una persona esperta.

La Nintendo la Capcom e la Konami usano una sorta di compilatore C gia dai tempi dello snes dove tutti gli altri scrivevano i giochi in asm mentre loro ottenevano ottimi risultati con questi macro linguaggi. Come lo so ? Lo so perchè avendo programmato anche su SNES so e sapevo come funzionava la macchina.

Senza remark è dura lo stesso e gli investimenti sono comunque enormi.

nn so, N64 e Snes non li conosco
Invece EA,MS$, Square e compagnia cosa usano?

Sono disponibile per domande se a qualcuno può interessare avere chiarimenti.

grazie, molto gentile

[Sephiroth87]

Su ds non si parla di eseguibili ma di rom, elenco ordinato di byte inseriti SEMPRE nelle stesse locazioni di memoria, visto che non c'è tra l'altro un file system. Ciascun byte rappresenta un OPCODE che a sua volta identifica un istruzione Assembler e le eventuali variabili in gioco.
Talvolta degli stream (sinonimo di file) sono inseriti nella Rom del gioco in questione, assegnandogli un area di memoria ben precisa, con un inizio e una fine. Questo accrocchio di file system è gestito direttamente dal sorgente principale. Mi riferisco in questo a sprite, texture e quant'altro.

Veramente, la ROM è solo il supporto, e, comunque, le cartuccie DS hanno un loro filesystem (vero, non accrocchio) interno, e file eseguibili normalissimi (ovviamente non .exe )

[SuperElf]

Veramente, la ROM è solo il supporto, e, comunque, le cartuccie DS hanno un loro filesystem (vero, non accrocchio) interno, e file eseguibili normalissimi (ovviamente non .exe )

beh, oddio, ammetto che quella del filesystem era una mia convinzione, anche se non l'avevo verificato. grazie per la precisazione

cmq per la foga non ho spiegato bene quello che intendevo, vediamo se ci riesco adesso con il sonno che ho :
ROM= read only memory, Memoria fisica formata da FlipFlop che rappresentano bit e quindi byte e quindi opcode.
Il file binario con il suo relativo livello di astrazione (nel senso che i byte non li vedi più come flip flop ma come istruzioni) è quello scaricato nella Rom dal produttore secondo un certo protocollo, quindi per esempio l'identificativo sarà sempre allo stesso indirizzo ecc.
quindi non puoi intendere il file binario come un eseguibile IMHO

mi sono spiegato bene? dimmi di si ti prego!