Codificando a tela de animação "woosh" no Amiga

Codificando a tela de animação "woosh" no Amiga

• O Amiga, quando foi lançado em 1985, oferecia um deslumbre de gráficos e som.
• Exibir imagens coloridas no Amiga é simples, mas no contexto de um motor de jogo há muitos desafios.

Desafio 1: requisitos de RAM

• Um Amiga 500 típico tem 512 KB de "chip RAM" e 512 KB de RAM expandida.
• Apenas a chip RAM pode ser usada para exibir gráficos e som, então ela é mais valiosa.
• Um CG de personagem em tela cheia usa um bitmap de 320x240 com 32 cores e ocupa 48 KB de RAM sem compressão.
• Para dar suporte à compressão de assets, foi adicionado o formato de compressão ZX0; ao comprimir o CG, ele cai para 8 KB, tornando-se viável.
• Quando os assets da fase são carregados, o CG comprimido é carregado na RAM expandida e descomprimido para a chip RAM logo antes de ser exibido.
• Em vez de encontrar 48 KB de chip RAM, outras partes da memória de tela são reutilizadas.

Desafio 2: efeito de "divisão de tela"

• No início, foi considerada uma transição vertical tipo wipe para a troca de telas.
• Porém, para que isso ficasse legal, seria necessário um wipe com gradiente, ajustando a paleta de cores em cada scanline.
• O efeito de divisão de tela é mais fácil de implementar e parece mais impressionante para o público em geral.
• Dois recursos especiais do Amiga trabalham juntos para tornar esse efeito possível:
  1. O coprocessador (copper) funciona em paralelo com a CPU e pode ser instruído a alterar registradores de hardware em linhas específicas da tela.
  2. A memória de tela pode ser alterada para qualquer lugar da chip RAM ao configurar os ponteiros de tela nos registradores de hardware.

Desafio 3: "linhas de movimento"

• Para completar o efeito de animação, são necessárias linhas com efeito de "woosh" no fundo.
• Usar sprites para desenhar essas linhas é uma boa escolha, porque eles podem ser desenhados e movidos independentemente da memória de tela.
• Os sprites do Amiga são muito limitados e complexos.

Cores dos sprites

• Os sprites compartilham bitplanes e a paleta de cores, então é desejável usar o mínimo possível de cores.
• Os sprites usam apenas 3 cores, deixando 28 cores para o CG e 1 cor para o fundo.
• Sprites diferentes usam cores diferentes da paleta.

Reutilização dos gráficos de sprite

• Os primeiros 4 bytes dos gráficos de sprite são os "bits de controle", que informam a posição e a altura do sprite.
• Isso se torna um problema quando se quer desenhar o mesmo gráfico em várias posições.
• Em vez disso, são criados 8 sprites falsos contendo apenas os bits de controle, e os ponteiros de sprite são configurados para esses sprites falsos.

Sprites não são desenhados quando os bitplanes estão desativados

• Antes de o CG chegar à parte superior da tela, há muito espaço vazio entre o topo da tela e o início do CG.
• Se os bitplanes permanecerem ativos durante esse período, dados lixo serão desenhados na tela.
• Se os bitplanes forem desativados, os sprites também deixam de ser desenhados.
• A solução é ativar apenas 1 bitplane e definir o ponteiro de tela para dados vazios.

Conclusão

• No começo, havia incerteza sobre incluir CG no jogo por causa dos requisitos de RAM.
• A implementação da compressão de dados provou que o overhead era bastante razoável.
• Aproveitar as características únicas do hardware do Amiga é algo especialmente interessante.

GN⁺ Opinião:

• Este artigo mostra bem a capacidade de processamento gráfico do computador Amiga e as técnicas de otimização de memória durante o desenvolvimento de jogos.
• Explica como implementar efeitos impressionantes dentro de recursos limitados usando compressão de dados e recursos especiais do hardware.
• Entender e aproveitar o hardware de computadores clássicos como o Amiga é um tema muito interessante para desenvolvedores de jogos retrô ou para quem se interessa por história da computação.

[GN⁺]

Comentários do Hacker News

• Resumo dos comentários sobre "Racing the beam":

  • Um usuário relembra que conhecia bem a técnica de "beam racing" e que a usou para calcular o tempo de CPU por quadro.
  • Ele menciona que usava o endereço $dff180 para definir cores nas bordas da tela e que aprendeu essa técnica de boca em boca, não pela internet.
  • Pergunta se ainda existem pessoas tentando explorar esse chipset ao máximo e demonstra curiosidade sobre o perfil de quem desenvolve jogos para computadores Amiga.
  • Agradece por compartilharem o interesse pelo Amiga.

• Resumo dos comentários sobre a configuração de memória do Amiga 500:

  • Um usuário aponta que o Amiga 500 vinha por padrão com 512kB de chip RAM, e que muitos usuários expandiam com mais 512kB de fast RAM.
  • Ele explica que essa RAM expandida não podia ser acessada diretamente pelo hardware gráfico e que era mais lenta do que fast RAM de verdade.

• Resumo dos comentários sobre o potencial de jogos de console japoneses no Amiga:

  • Um usuário diz ter curiosidade sobre como jogos de console japoneses seriam no Amiga e questiona se faltava desempenho à máquina ou se ele simplesmente não gostava do design da maioria dos jogos.
  • Cita como exemplo a conversão de Bonk feita pela Factor 5 e elogia o estúdio como desenvolvedores quase mágicos.

• Resumo dos comentários sobre o apelo de programar dentro de limitações:

  • Um usuário expressa que programar dentro de restrições é algo muito atraente.

• Resumo dos comentários sobre experiências pessoais com o Amiga e o compartilhamento de como essas animações eram feitas:

  • Um usuário comenta que o Amiga que ele usou parecia diferente da experiência que outras pessoas tiveram e, ao compará-lo ao Nintendo NES, diz que não sente tanta nostalgia.
  • Ainda assim, reconhece que é muito legal mostrar como essas animações eram feitas.