Sprites de 'comutação bancária' em aplicativos antigos da NES

Question

Atualmente, estou escrevendo em C# o que basicamente poderia ser chamado de minha própria interpretação do hardware NES para um jogo de aparência da velha escola que estou desenvolvendo. Eu demiti o FCE e tenho observado como o NES exibia e renderizou gráficos.

Em poucas palavras, o NES poderia conter dois bitmaps em informações gráficas, cada uma com as dimensões de 128x128. Estes são chamados de tabelas de PPU. Um era para azulejos BG e o outro era para sprites. Os dados tiveram que estar nessa memória para que fossem desenhados na tela. Agora, se um jogo tivesse mais dados gráficos do que esses dois bancos, ele poderia escrever partes dessas novas informações para esses bancos - o que escrevia o que havia - no final de cada quadro e usá -lo a partir do próximo quadro.

Então, nos jogos antigos, como os programadores 'trocaram'? Quero dizer, dentro do design de nível, como eles sabiam qual gráfico definido para carregar? Percebi que o Mega Man 2 Bankswitches quando a tela rola programaticamente de uma parte do palco para a próxima. Mas como eles armazenaram essas informações no nível - o que se espalha para copiar para as tabelas da PPU e onde as escrever?

Outro exemplo seria acertar uma pausa no MM2. Os ladrilhos BG ficam muito escritos durante a pausa e depois são restaurados quando o jogador não for pobres. Como eles se lembraram de quais ladrilhos substituíram e como restaurá -los?

Se eu fosse preguiçoso, eu poderia fazer um enorme bitmap estático e apenas pegar valores dessa maneira. Mas estou me forçando a limitar esses valores a criar uma experiência mais autêntica. Eu li o incrível guia sobre como o MC Kids foi feito e estou tentando estar com os barebones sobre como programar este jogo. Ainda me surpreende como esses programadores realizam o que fizeram com o que tinham.

EDIT: A única solução em que posso pensar seria manter tabelas separadas que afirmam quais ladrilhos deveriam estar na PPU a que horas, mas acho que seria um enorme recurso de memória que o NES não seria capaz de lidar.

Answer 1

Depois de uma noite pensando e relendo documentos, acho que encontrei uma solução perfeita. Uma matriz!

Dados os seguintes dados:

 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 usar essas informações para acessar informações nas tabelas de pesquisa para determinar quais informações eu preciso. A primeira entrada (0,0) define o mapa inteiro, onde os outros valores definem o que é necessário nessa tela específica.

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

Então, ao carregar o mapa, olho para o item (0,0). Ele dirá que preciso carregar os ladrilhos X na PPU, usar pallete de cores, Z Tileset e uma música. Ele também dirá que a tela 0 é a tela inicial e que o nível começa por aí - posicione o caractere de acordo.

   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

Agora digamos que eu preciso fazer telas de transição. Eu posso olhar para a tela atual versus a tela de destino. Se a nova tela precisar de informações não na PPU, posso iniciar uma transição que carregue os dados durante ela. Também posso ver se consigo rolar nessa direção; Por exemplo, se a tela de destino for -1, não posso rolar essa direção. Também posso armazenar uma bandeira em algum lugar para determinar que, se rolar nessa tela, não posso rolar para trás. Por exemplo, eu posso ir direto na tela nº 2, mas não consigo rolar para a esquerda na tela 1.