Sprites 'Bank Switching' su vecchie applicazioni NES

Question

Attualmente sto scrivendo in C# quello che potrebbe essere sostanzialmente chiamato la mia interpretazione dell'hardware NES per un gioco alla vecchia maniera che sto sviluppando. Ho attivato FCE e sto osservando come il NES ha mostrato e reso grafica.

In breve, il NES può contenere due bitmap di informazioni grafiche, ciascuna delle dimensioni di 128x128. Queste sono chiamate le tabelle PPU. Uno era per le tessere BG e l'altro era per gli sprite. I dati dovevano essere in questa memoria per essere disegnati sullo schermo. Ora, se un gioco avesse più dati grafici di questi due banchi, potrebbe scrivere parti di queste nuove informazioni su queste banche, riscrivendo ciò che era lì - alla fine di ogni frame, e usarlo dal prossimo frame in poi.

Quindi, nei vecchi giochi, come ha fatto il cambio banca dei programmatori? Voglio dire, all'interno del level design, come hanno fatto a sapere quale set grafico caricare? Ho notato che i bankwitch di Mega Man 2 quando lo schermo scorre programmaticamente da una parte dello stage a quella successiva. Ma come hanno archiviato queste informazioni nel livello: che cosa sprite copiare nelle tabelle PPU e dove scriverle?

Un altro esempio potrebbe essere la pausa in MM2. Le tessere BG vengono sovrascritte durante la pausa e poi vengono ripristinate quando il giocatore non è pronto. Come hanno ricordato quali tessere hanno sostituito e come ripristinarle?

Se fossi pigro, potevo semplicemente creare un enorme bitmap statico e solo prendere i valori in questo modo. Ma mi sto costringendo a limitare questi valori per creare un'esperienza più autentica. Ho letto l'incredibile guida su come M.C. I bambini sono stati creati e sto cercando di essere iperboli su come programmare questo gioco. Mi infastidisce ancora il modo in cui questi programmatori riescono a realizzare ciò che hanno fatto con ciò che avevano.

EDIT: L'unica soluzione che posso pensare sarebbe di tenere tabelle separate che indicano quali piastrelle dovrebbero essere nel PPU a che ora, ma penso che sarebbe un'enorme risorsa di memoria che il NES non sarebbe in grado gestire.

Answer 1

wSo dopo una notte di riflessione e rilettura dei documenti, penso di aver trovato una soluzione perfetta. Una matrice!

Dati i seguenti dati:

3, -1, -1, -1, -1 
-1, 0, 1, 2, -1 
-1, -1, -1, 3, -1 
-1, -1, 5, 4, -1 
-1, -1, -1, -1, -1 

posso utilizzare queste informazioni per accedere alle informazioni all'interno di tabelle di ricerca per determinare quali informazioni che mi servono. La prima voce (0,0) definisce l'intera mappa, dove gli altri valori definiscono ciò che è necessario in quella schermata specifica.

MAP ARRAY PALETTE MUSIC TILESET STARTINGSCR 
    0   0  0  1   4 
    1   4  3  2   2 
    2       etc. 
    3 

Quindi, durante il caricamento della mappa, guardo l'elemento (0,0). Dirà che ho bisogno di caricare X tiles nel PPU, usare Y color pallete, Z tileset e A music. Dirà anche che lo schermo 0 è la schermata iniziale e che il livello inizia da lì - posiziona il personaggio di conseguenza.

SCREEN  PALETTE TILESET MUSIC TILEDATA SCROLLL SCROLLR SCROLLU SCROLLD 
     0   0   1  2   4  true  true true true 
     1     etc 
     2   2   1  2   3  false false  false true 

Ora diciamo che ho bisogno di schermi di transizione. Posso guardare la schermata corrente rispetto alla schermata di destinazione. Se la nuova schermata necessita di informazioni non nella PPU, posso avviare una transizione che caricherà i dati durante la stessa. Posso anche vedere se posso scorrere in quella direzione; ad es., se lo schermo di destinazione è -1, non posso scorrere quella direzione. Posso anche memorizzare una bandiera da qualche parte per determinare che se si scorre su quello schermo, non posso tornare indietro. Ad esempio, posso andare direttamente allo schermo n. 2, ma non posso scorrere a sinistra nello schermo 1.