Sprites «Bank Switching» sur les anciennes applications NES

Question

J'écris actuellement en C# ce que l'on pourrait appeler ma propre interprétation du matériel NES pour un jeu à l'ancienne que je développe. J'ai lancé FCE et j'ai observé comment le NES affichait et affichait des graphiques. En un mot, le NES pouvait contenir deux images bitmap d'une valeur de 128 x 128 pixels. Ce sont les tables PPU. L'un était pour les carreaux BG et l'autre pour les sprites. Les données devaient être dans cette mémoire pour être dessinées à l'écran. Maintenant, si un jeu avait plus de données graphiques que ces deux banques, il pourrait écrire des parties de cette nouvelle information à ces banques - en l'écrasant par écrit - à la fin de chaque image, et l'utiliser dès la prochaine image. Donc, dans les vieux jeux, comment la banque des programmeurs a-t-elle changé? Je veux dire, dans la conception de niveau, comment ont-ils su quel ensemble graphique charger? J'ai remarqué que la banque Mega Man 2 bascule lorsque l'écran défile par programmation d'une partie de la scène à la suivante. Mais comment ont-ils stocké cette information dans le niveau - quels sprites copier dans les tables PPU, et où les écrire?

Un autre exemple serait de faire une pause dans MM2. Les tuiles BG sont écrasées pendant la pause, puis sont restaurées lorsque le joueur se relâche. Comment se sont-ils souvenus des carreaux qu'ils ont remplacés et comment les restaurer? Si j'étais fainéant, je pourrais juste faire un bitmap statique énorme et saisir juste des valeurs de cette manière. Mais je me force à limiter ces valeurs pour créer une expérience plus authentique. J'ai lu le guide incroyable sur comment M.C. Les enfants ont été créés, et j'essaie d'être des barebones sur la façon dont je programme ce jeu. Il me vient encore à l'esprit comment ces programmeurs ont accompli ce qu'ils ont fait avec ce qu'ils avaient.

EDIT: La seule solution que je peux penser serait de tenir des tables séparées qui indiquent quelles tuiles devraient être dans le PPU à quel moment, mais je pense que ce serait une énorme ressource de mémoire que le NES ne pourrait pas gérer.

Answer 1

wAprès une nuit de réflexion et de relecture de documents, je pense avoir trouvé une solution parfaite. Une matrice!

Étant donné les données suivantes:

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 

Je peux utiliser ces informations pour accéder à l'information dans les tables de consultation afin de déterminer quelles sont les informations dont j'ai besoin. La première entrée (0,0) définit la carte entière, où les autres valeurs définissent ce qui est nécessaire dans cet écran particulier.

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

Donc, lors du chargement de la carte, je regarde le point (0,0). Il dira que j'ai besoin de charger des carreaux X dans le PPU, utiliser une palette de couleurs Y, un tileset Z et une musique. On dira aussi que l'écran 0 est l'écran de départ et que le niveau commence là - positionnez le personnage en conséquence.

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 

Maintenant, disons que j'ai besoin de passer des écrans. Je peux regarder l'écran actuel par rapport à l'écran cible. Si le nouvel écran n'a pas besoin d'informations dans le PPU, je peux lancer une transition qui chargera les données pendant le PPU. Je peux aussi voir si je peux faire défiler dans cette direction; par exemple, si l'écran cible est -1, je ne peux pas faire défiler cette direction. Je peux également stocker un drapeau quelque part pour déterminer que si défilé sur cet écran, je ne peux pas revenir en arrière. Par exemple, je peux aller directement dans l'écran n ° 2, mais je ne peux pas faire défiler vers la gauche dans l'écran 1.