Quais são as limitações dos consoles retrô? [fechadas]

Estou interessado em criar um visual retrô para um jogo e atualmente estou decidindo o quão retrô (qual geração / console). O que tornaria mais fácil seria se houvesse algum tipo de wiki / documento sobre as limitações de cada console, como número máximo total de cores, máximo por sprite, número de camadas, máximo de blocos, tamanho máximo de bloco, tamanho de sprite, etc. ., etc .. Veja o Game Boy, por exemplo. 4 cores, sim, e também encontro a resolução da tela. Mas e todas as outras limitações?

Portanto, se alguém conhece algum bom recurso, seria uma grande ajuda. Acho que a liberdade que a geração atual de computadores e consoles oferece é um pouco demais , pois posso continuar adicionando cada vez mais e nunca terminarei. Eu adoraria definir um limite e fazer o melhor que puder dentro desse limite.

A maioria desses detalhes está implícita nas especificações de hardware dos consoles e no design de suas APIs de interação de hardware. Essas informações geralmente estão disponíveis nos guias de programação dos consoles relevantes, no entanto, esses guias estão sob o NDA e o mais próximo que você poderá obter é através da documentação disponibilizada pela engenharia reversa (ela mesma um pouco de uma área cinza legal) - eles discutem coisas como contagem e tamanho de bancos de RAM, a latência envolvida na troca de bancos e quando você pode fazê-lo (por exemplo, durante um retrace vertical em branco ou não), etc.

Felizmente, as limitações que você parece seguir são algumas das mais óbvias relacionadas a gráficos. Por exemplo, uma limitação comum dos consoles antigos, como o GameBoy e o NES, era que eles suportavam um número fixo (pequeno) de sprites por linha - o hardware apenas cativaria tantos e, se você tivesse muitos, eles simplesmente desapareceriam. Isso se manifestaria como "tremulação" de alguns sprites na tela quando a exibição do jogo ficasse lotada.

Alguns dos poucos recursos disponíveis incluem o wiki do NESDev , este artigo sobre sprites na Wikipedia (que inclui estatísticas sobre os vários recursos de sistemas de sprites mais antigos baseados em hardware, como o GameBoy, NES etc.).

Os consoles geralmente têm muitos modos diferentes, por exemplo, o DS pode ter 4 cores, 16 ou 256 (talvez até 16 bits, não me lembro). Esses foram usados ​​por causa da pegada de memória do cartucho (um jogo menor custou menos para fabricar), da velocidade das impressões e da pegada de memória.

Também havia muitas técnicas, como a interrupção da linha de varredura, para superar essas limitações (número de sprites incluídos).

Como parece que você quer dar uma olhada, basta conferir os gráficos dos jogos antigos e escolher sua opção; depois, verifique a resolução e a profundidade de cores desse jogo em particular e faça o mesmo.

Usando o SNES como um exemplo:

Os blocos de 8x8 ou 16x16 pixels são limitados a 16 cores cada. As cores podem vir de uma das oito paletas. Os mapas de mosaico, contendo esses mosaicos, estão limitados a 256x256, 512x256 ou 256x512 pixels. Dentro do mapa de mosaicos, você pode usar o mesmo mosaico com uma paleta diferente. Também havia suporte para 2 ou 4 camadas de fundo de cor para reduzir a memória usada pelos blocos.

O SNES tinha até quatro camadas de mapa de mosaico, dependendo do modo gráfico usado. A ordem de exibição do mapa de peças pode ser controlada no software.

Sprites são limitados ao poder de duas combinações de 8x8 a 64x64. (por exemplo, 8x8, 8x16, 32x64 64x64 etc.). Cada sprite é limitado a 16 cores em um conjunto separado de oito paletas.

Um dos recursos interessantes do SNES (e muitos outros consoles de 16 bits) é a capacidade de alterar as propriedades de exibição por linha de verificação. A cor do plano de fundo pode ser alterada ou o mapa em mosaico rolou para a esquerda ou direita em cada linha de digitalização. Isso é usado para criar um céu gradiente sem violar o limite de 16 cores ou criar uma imagem ondulada.

Apliquei as limitações acima ao meu mecanismo de jogo Super Play licenciado pelo MIT .