'Conmutación de banco' Sprites en aplicaciones NES antiguas

Question

Actualmente estoy escribiendo en C# lo que básicamente podría llamarse mi propia interpretación del hardware NES para un juego que estoy desarrollando en la vieja escuela. He activado FCE y he estado observando cómo se muestra y representa gráficos NES.

En pocas palabras, el NES podría contener información gráfica de dos bitmaps, cada una con las dimensiones de 128x128. Estas se llaman tablas PPU. Una era para fichas BG y la otra era para sprites. Los datos deben estar en esta memoria para que se dibujen en la pantalla. Ahora, si un juego tuviera más datos gráficos que estos dos bancos, podría escribir partes de esta nueva información en estos bancos -escribiendo lo que estaba allí- al final de cada cuadro, y usarlo desde el siguiente cuadro en adelante.

Entonces, en juegos antiguos, ¿cómo cambiaba el banco de los programadores? Quiero decir, dentro del diseño de niveles, ¿cómo sabían qué conjunto de gráficos cargar? Me he dado cuenta de que MegaMan 2 conmuta cuando la pantalla se desplaza programáticamente de una parte del escenario a la siguiente. Pero, ¿cómo almacenaron esta información en el nivel? ¿Qué sprites copiar en las tablas de PPU, y dónde escribirlas?

Otro ejemplo sería presionar pausa en MM2. Los mosaicos BG se sobreescriben durante la pausa, y luego se restauran cuando el jugador se reanuda. ¿Cómo recordaron qué fichas reemplazaron y cómo restaurarlas?

Si fuera flojo, podría hacer un gran mapa de bits estático y simplemente tomar los valores de esa manera. Pero me obligo a limitar estos valores para crear una experiencia más auténtica. He leído la increíble guía sobre cómo M.C. Los niños se hicieron, y estoy tratando de ser barebones sobre cómo programo este juego. Todavía me sorprende cómo estos programadores lograron lo que hicieron con lo que tenían.

EDITAR: La única solución que se me ocurre sería mantener tablas separadas que indiquen qué teselas deberían estar en el PPU y en qué momento, pero creo que sería un gran recurso de memoria que el NES no podría manejar.

Answer 1

wSo después de una noche de pensar y volver a leer documentos, creo que se me ocurrió una solución perfecta. Una matriz!

determinado los siguientes datos:

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 

puedo utilizar esta información para acceder a la información dentro de las tablas de búsqueda para determinar qué tipo de información que necesito. La primera entrada (0,0) define el mapa completo, mientras que los otros valores definen lo que se necesita en esa pantalla en particular.

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

Al cargar el mapa, miro el artículo (0,0). Dirá que necesito cargar mosaicos X en el PPU, use Y color pallete, Z tileset y A música. También dirá que la pantalla 0 es la pantalla de inicio y que el nivel comienza allí; coloque el personaje en consecuencia.

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 

Digamos que ahora necesito pantallas de transición. Puedo mirar la pantalla actual frente a la pantalla de destino. Si la nueva pantalla no necesita información en el PPU, puedo iniciar una transición que cargará los datos durante la misma. También puedo ver si puedo desplazarme en esa dirección; por ejemplo, si la pantalla de destino es -1, no puedo desplazarme en esa dirección. También puedo guardar una bandera en algún lugar para determinar que si me desplazo a esa pantalla, no puedo desplazarme hacia atrás. Por ejemplo, puedo ir directamente a la pantalla n. ° 2, pero no puedo desplazarme hacia la izquierda en la pantalla 1.