Come sono stati programmati i giochi basati su cartucce? [chiuso]

Sto pensando a SNES, N64, Atari ... anche il DS oggi, suppongo.

I giochi SNES di solito non occupavano più di 4 MB di spazio, mentre i giochi N64 erano in genere da 32 a 64 MB di dati.

In questi giorni, puoi a malapena compilare un "ciao mondo!" programma senza la compilazione risultante che genera 1,21 gigabyte !! di dati. (Scherzi a parte, i file oggi occupano tonnellate e tonnellate di spazio rispetto ad alcune delle tecnologie di allora.)

Dunque come l'hanno fatto?

• In che cosa hanno programmato questi giochi? ASM? L'intera cosa in ASM ?!
• Come sono state create le grafiche? Quale tecnologia avevano per creare fogli sprite e, in alcuni casi (come l'N64), modelli 3D?
• Come si sono adattati a così tanti livelli, personaggi, missioni e oggetti su queste cartucce? Voglio dire, Super Mario World sugli orologi SNES in circa 1 MB e ha 96 uscite! Ocarina of Time, Banjo-Kazooie, DK64 e alcuni altri giochi occupano meno di 64 MB e avevano mondi enormi, tonnellate di contenuti e modelli 3D!

Scusate se le mie domande sembrano un po 'là fuori, sono solo stupito che molti grandi titoli là fuori siano riusciti a stare in uno spazio di archiviazione così piccolo.

È affascinante per me perché anche i più piccoli e banali file e giochi riescono a occupare almeno alcuni MB, quindi immaginare che livelli enormi come quelli di GoldenEye 007 non siano riusciti a catturare quasi nessun dato è strabiliante.

Sono le risorse artistiche e audio che occupano spazio, la scelta del linguaggio di programmazione è stata più incentrata sull'ottimizzazione dell'hardware.

Usando N64 come esempio, la maggior parte dei giochi di terze parti erano 8, 12 o 16 Mb. I giochi da 32 e 64 Mb provenivano principalmente da Nintendo in quanto era così costoso spedire su carrelli così grandi per tutti gli altri. Sembra minuscolo, ma lo erano anche i beni artistici e l'output visivo finale. Devi ricordare che la maggior parte dei giochi N64 resi a 320x240 non i 1280x760 o più di oggi. Con una risoluzione di output così ridotta, le trame e gli sprite erano molto più piccoli di oggi.

A causa della minuscola cache delle trame sull'N64, la maggior parte delle trame era di 32x64 pixel con una tavolozza a 4/8 bit (ovvero 16/256 colori). I dettagli sui colori extra venivano spesso miscelati con trame e colori dei vertici. I giochi Banjo ne sono un buon esempio.

Oggi un singolo rock in un gioco Unreal avrà più 512x512x24 bpp o anche 32 bpp. Inoltre, invece di una sola texture diffusa, ora hai mappe normali, maschere speculari, maschere di riflessione, cubemap di riflessione e altro ancora. Quindi un oggetto che aveva una trama 4Kb è ora coperto da diversi MB di dati.

I vecchi giochi hanno anche una grande quantità di riutilizzo dell'arte. I cespugli in Super Mario Bros. sono gli stessi folletti delle nuvole, le colline sono uguali ai funghi. Personaggi diversi sono solo versioni con spostamento del colore delle stesse risorse artistiche. Tutto ciò ha permesso di sfruttare maggiormente ogni trama o sprite presente nel carrello.

L'audio è un'altra grande differenza per i giochi moderni. Quasi tutto ai vecchi tempi era fatto con tracce sequenziate. Ora entrambe le tracce musicali, gli effetti vocali e sonori sono memorizzati in vari formati audio compressi. Sebbene certamente più piccoli dei dati non compressi, sono ancora significativamente più grandi dei loro equivalenti sequenziati.

Per quanto riguarda il NES (e anche il SNES per lo più), ecco una panoramica di base. Non ho scritto alcun gioco NES, ma ho scritto un emulatore NES (Graybox) e ho fatto un bel po 'di reingegnerizzazione di vecchi carrelli.

Per quanto riguarda il linguaggio di programmazione: sì, era tutto assemblato. Programmare il NES significava lavorare direttamente con interrupt di processo, porte DMA, commutazione di banchi ecc. Fortunatamente, programmare il 6502 (o meglio, il 2A03) è abbastanza semplice [1]:

• ci sono pochi registri: principalmente A, X e Y, gli ultimi due sono utilizzabili solo per indicizzazione e iterazione
• il set di istruzioni è piccolo e per lo più semplice
• poca memoria: la RAM principale è di 2 KB, con un'estensione opzionale da 8 KB alimentata a batteria. Di quei 2 KB, 256 byte sono riservati per lo stack e la pagina 0 (i primi 256 byte) era il punto in cui si desidera archiviare i puntatori e i valori più utilizzati a causa di alcune modalità di indirizzamento speciali

Queste 3 cose insieme creano un ambiente abbastanza facile da memorizzare mentre ci si lavora. Sì, gestisci tu stesso tutta la memoria, ma ciò significa essenzialmente che crei una mappa completa di dove tutto va avanti e quella mappa non è molto grande perché devi solo preoccuparti di 2K, quindi puoi tracciarlo su un pezzo di carta millimetrata. Dovevi pianificare un po 'di più le cose e assegnare staticamente variabili e costanti alle posizioni RAM e ROM (sulla cartuccia).

Diventa un po 'più complicato quando i dati della cartuccia superano i limiti indirizzabili della CPU. Sono 64 KB, di cui i 32 KB inferiori sono impostati in pietra e mappati su tutti i tipi di porte hardware e RAM. È qui che entra in gioco il cambio di banco, il che significa mappare una sezione della ROM nello spazio degli indirizzi di 32 KB (parte di) superiore.

Questo può essere usato nel modo desiderato dal programmatore, ma un esempio potrebbe essere quello di avere un gioco con 3 livelli, con tutti i dati di livello, i metadati e il codice per ogni livello stipati in aree di memoria separate da 8 KB sulla cartuccia. Il livello potrebbe avere callback per es. Inizializzazione, aggiornamento per frame, ecc. "Caricamento" del livello significherebbe mappare quel pezzo di memoria da 8 KB ad es. 0xC000. È quindi possibile specificare che la routine init è sempre a 0xC000, la routine di aggiornamento dei frame è a 0xC200 e i dati di livello iniziano a 0xC800. Il codice principale del gioco contenuto in un altro blocco di memoria controlla quindi i cambiamenti di livello semplicemente scambiando il blocco giusto e saltando agli indirizzi assoluti 0xC000 e 0xC200 nei momenti appropriati.

Dati grafici scritti: i dati dei riquadri del NES sono mappe di pixel 8x8 a 2 bit. Per lo sfondo sono combinati con uno strato da 2 bit a risoluzione 1/4. Questi valori a 4 bit sono stati quindi indicizzati in una tavolozza a 16 voci, con credo che siano disponibili 53 colori unici efficaci. Gli sprite hanno anche usato i dati dei pixel a 2 bit e ogni sprite ha nuovamente specificato il proprio indice di gruppo a 2 bit formando un indice pal a 4 bit. L'immagine BG sullo schermo è una matrice 32x30 di numeri indice di piastrelle.

In sostanza, avendo una tonnellata di ripetizioni e indici in indici è possibile mantenere i dati molto piccoli. I dati di livello venivano spesso memorizzati come barre verticali di indici di riquadri e poiché anche quelle barre verticali venivano riutilizzate, anche quelle venivano indicizzate e archiviate una sola volta sulla cartuccia. Semplici tecniche di compressione dei dati funzionano in modo simile. Ciò ha permesso a Mario 1 di avere 32 KB di dati (con spazio libero) e 8 KB di dati bitmap.

Per quanto riguarda gli ambienti di sviluppo, ho visto alcune foto in cui le persone lavoravano su alcuni computer certificabilmente antichi collegati ai masterizzatori EEPROM per lavoro. Il debug con strumenti non era realmente possibile fino all'età SNES [2]. Questo è il motivo principale per cui molti vecchi giochi hanno bug "ovvi" e perché cose come Gameshark potrebbero fare quello che fanno; la salute del giocatore sarà sempre nella posizione mem X, quindi puoi forzarla a 100 in ogni momento.

Se trovi interessanti queste cose, ti incoraggio a consultare, ad esempio, http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Ci sono alcuni corsi di programmazione per NES che possono essere trovati anche online.

Spero che questa panoramica semplificata abbia dato un'idea dello sviluppo del gioco degli anni '80.

[1] Relativamente parlando. Inoltre sono di parte mentre scrivevo Graybox stesso in circa l'85% di assemblaggio PowerPC. [2] Vedi la realizzazione dell'articolo FF6: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

Ci sono molti argomenti secondari in quasi tutte le domande che stai ponendo. L'ottimizzazione è un campo enorme tutto per sé e ci sono molte cose da esplorare.

Se sei interessato a questo tipo di ottimizzazione, una delle cose che potresti esplorare è il demoscene . Il demoscene, e alcune delle sue culture artistiche correlate, hanno a lungo conservato un senso di meraviglia nel cercare di creare arte intricata per computer che occupa il minor spazio possibile. Molti di loro avranno informazioni su come hanno fatto alcuni o tutti i loro "trucchi".

Spesso c'è un abile mix di buon senso, sebbene ci siano "trucchi" e "hack" specifici per un gioco o un genere. Spesso c'è un po 'di "fortuna" in gioco, e una squadra che conosce i limiti per i quali sta lavorando (forse mettendo continuamente testa a quei limiti durante tutto il processo), conoscendo i loro compromessi disponibili ed essere disposta a fare alcuni degli scambi necessari -off e sacrifici per soddisfare i loro limiti.

Ecco alcune delle cose a cui riesco a pensare che possono aiutare una squadra a ottenere un gioco di dimensioni inferiori:

• Riutilizza ciò che puoi: riutilizzare gli stessi sprite e le variazioni che puoi facilmente fare da una singola immagine sprite (come riflessi, rotazioni, spostamenti della tavolozza) ti faranno risparmiare spazio. Lo stesso vale per il codice, la musica e quasi tutto il resto in un gioco.
• Comprimere ciò che è possibile: ci sono una serie di schemi di compressione là fuori e sapere quali utilizzare è un enorme risparmio di spazio. Anche a volte semplici schemi di compressione come la codifica run-length possono fare una differenza sorprendente. Non solo, ma esistono schemi di compressione (e formati alternativi che non sono esattamente di compressione) per singoli tipi di file, spesso con compromessi di qualità. Ad esempio, i file audio wave / CD possono essere compressi, con una leggera perdita di informazioni, in file MP3. Inoltre, formati di file come MIDI e MOD basati su campionatore sono formati alternativi che occupano molto meno spazio, ma codificano la musica in modo completamente diverso e richiedono competenze diverse per farli suonare bene.
• Perdi quello che non ti serve: puoi farlo a un prezzo inferiore? Ad esempio, puoi ancora ottenere la "personalità" di un personaggio in meno pixel (o poligoni)? Il posizionamento dei riquadri deve essere definito esattamente da un designer o possono essere generati casualmente nel codice del programma?
• Il codice è spesso più economico: sebbene tu abbia fatto una battuta su quanto spazio in genere una compilazione di codice ora prende idee (e ci sono ragioni per cui questa "piattaforma" è aumentata nel corso degli anni e modi per ridurla quando ne hai assolutamente bisogno), ma in genere se si può fare facilmente qualcosa in modo algoritmico / procedurale / nel codice, tale approccio sarà anche più facile da modificare e riutilizzare per altri beni simili ma diversi. I frattali sono un esempio particolarmente facile da vedere: potresti avere un'immagine di un intricato frattale che occupa molto spazio rispetto alla formula matematica che lo genera. La formula matematica, inoltre, può avere parametri che possono generare immagini simili, ma a volte sorprendentemente diverse dall'aspetto.

Ad ogni modo, per una serie così ampia di domande, spero che alcuni degli argomenti di cui sopra siano buoni punti di partenza per saperne di più.

Una cosa è che non sono sicuro che si trovi ancora nell'era post N64, ma SNES e N64 spesso riutilizzano trame su altri oggetti 3D che spesso risparmiano spazio considerevole e arte pre renderizzata che gli sfondi sono spesso falsi. Un altro trucco era quello di creare uno sfondo di nebbia che sarebbe stata utilizzata.

San Francisco Rush N64 ha sempre avuto un po 'di nebbia, anche se le impostazioni potevano cambiare la densità dove il arcade di San Francisco Rush non ne aveva e si poteva vedere il Golden Gate Bridge sulla Traccia 1 rispetto alla versione N64.

Inoltre, i giochi spesso riutilizzano la musica come Zelda Ocarina of Time, riutilizza molto la musica che trovo fastidiosa in quanto si sarebbe potuto fare un lavoro migliore come Banjo Kazooie / DK64 spesso aveva temi all'interno di temi!

Zelda Ocarina del tempo avrebbe potuto avere l'Hyrule Overworld e quindi una versione subacquea del tema se andassi sott'acqua o facessi gli strumenti nel tema Shop riflettono l'area esterna dove flauti e violini sarebbero stati usati per il negozio della foresta di Kokiri e le corna e trombe per il negozio di Hyrule Castle Town e batteria nel villaggio di Goron.etc

Nei moduli 3D del PC i moduli vengono compilati in librerie per accedervi rapidamente utilizzando un programma per decomprimerlo, ma non sono sicuro che sia il caso di Nintendo basato su ROM. Il PC è la RAM come entrare in una stanza disordinata in cui le cose non sempre rimangono dove sono supposte e le informazioni possono essere sovrascritte al punto che il computer non si avvia nemmeno!

Le console di gioco sono ROM in cui tutto è archiviato in uno spazio assegnato, quindi ogni volta che accendi il gioco cercherà i file in quello spazio assegnato con la garanzia che rimarrà lì.