Doom roda, desta vez, em um BBC Micro de 1981, em wireframe e a cerca de 7 quadros por segundo
Doom foi portado para o BBC Micro Model B de 1981, rodando em wireframe a cerca de 7 quadros por segundo com portas e elevadores funcionais.
Um desenvolvedor portou a fase E1M1 de Doom para o BBC Micro Model B, computador britânico lançado em 1981 com processador de 2 MHz e 32 KB de RAM. O projeto roda a cerca de 7 fps e permite andar pelo mapa, com portas e elevadores funcionando.
A versão usa só as linhas dos cenários (wireframe), sem texturas nem inimigos. Mesmo assim, segundo o repositório ebenupton/doom no GitHub, o motor faz a travessia completa da árvore BSP, remove superfícies escondidas e aplica projeção em perspectiva, tudo num hardware que nunca foi pensado para isso.
Para testar, basta iniciar o arquivo doom_walk.ssd num Model B com sideways RAM ou arrastá-lo para o emulador jsbeeb, que roda no navegador. As setas giram e movimentam o jogador, e as portas e plataformas do nível se mexem sozinhas enquanto você explora.
O que é um BBC Micro
O BBC Micro é um microcomputador da empresa britânica Acorn Computers, criado para o projeto de alfabetização em informática da BBC e lançado em 1981. Virou presença comum nas escolas do Reino Unido e ganhou o apelido de “Beeb”. A Acorn, aliás, é a empresa de onde saiu mais tarde a arquitetura ARM, que hoje está em praticamente todo celular.
O Model B, versão usada no projeto, tem um 6502 a 2 MHz e 32 KB de RAM. Para ir além disso, o computador aceita sideways RAM, bancos extras de memória que entram numa janela de 16 KB. O port exige os bancos 4, 6 e 7 e funciona num Model B comum com essa expansão, sem precisar do modelo Master.
Por que rodar Doom ali é tão difícil
O Doom original foi escrito para CPUs de 32 bits: usa ponto fixo 16.16, cerca de 64 KB de tabelas de consulta e um desenho de colunas pensado para o hardware da época. O 6502 do BBC Micro é de 8 bits e não tem instrução de multiplicação. Dos 32 KB de RAM, 5 KB vão só para o framebuffer, e todo o resto precisa passar pela janela de 16 KB. O projeto resume que cada decisão do projeto nasce dessas limitações.
Como o motor dá conta do recado
O Doom clássico guarda, para cada coluna da tela, os limites de piso e teto, o que significa mexer em 320 bytes a cada portal. Aqui a região visível fica numa lista encadeada de spans trapezoidais, com um pool de 32 posições. O estado de oclusão de um quadro cabe em poucos spans, e a árvore BSP descarta subárvores inteiras quando já não há espaço visível.
Sem multiplicação no processador, o projeto usa só uma rotina de multiplicação 8×8 para 16 bits por quarter-square e uma tabela de recíprocos para a perspectiva. A seleção de caixas delimitadoras (bounding boxes) acontece no espaço de ângulos, como no Doom original, com zero multiplicações e uma divisão por vértice de silhueta.
Boa parte do trabalho pesado sai da execução e vai para o build. Um estágio de empacotamento, inspirado no Doom8088, pré-calcula marcações de segmentos, funde segmentos colineares e identifica o tipo de partição de cada nó da BSP. Só nessa etapa foram detectadas 494 arestas falsas que nunca precisam ser desenhadas. Como 73% dos nós têm partições alinhadas aos eixos, o motor lê apenas os dois bytes de que precisa em cada teste de lado.
Dois caches que reaproveitam o quadro anterior
Os autores do projeto aproveitam que um quadro se parece muito com o seguinte, e os dois caches produzem saída idêntica bit a bit ao cálculo completo:
- Cache de rotação: enquanto o jogador gira parado, o ângulo das caixas só precisa ser recalculado em relação à direção da câmera, o que reduz o tempo de renderização em 16,5%.
- Cache de translação: ao caminhar, a transformação de cada vértice vira seis leituras e somas no lugar de cerca de 1.100 ciclos, com ganho de 8% ou mais nos quadros em movimento.
Portas e elevadores “não existem” quando ninguém olha
Portas, o elevador e o piso em zigue-zague rodam como máquinas de estado no próprio 6502. As tabelas do renderizador só são reescritas quando a caminhada pela BSP chega a um subsetor com esse elemento móvel. Uma porta fora do campo de visão não gera nenhuma escrita em tabela, e uma porta fechada bloqueia a visão pelo mesmo mecanismo de spans, sem tratamento especial.
Tela e sincronização
O vídeo usa o Mode 4 numa janela de 256×160, com buffer duplo. Um timer do chip 6522 acompanha exatamente um campo PAL de 312 linhas, porque a configuração padrão do sistema operacional deriva 32 µs a cada campo, um bug que o README classifica como “entretenimento”. A limpeza do quadro é dividida em blocos e agendada atrás do feixe de varredura, então os 5 KB são apagados sem custo visível e sem cintilação.
Testado como software de verdade
O motor nativo evolui junto com uma referência em Python que replica o comportamento bit a bit, incluindo a mesma multiplicação 8×8 e as mesmas tabelas. O rasterizador tem um gêmeo em Python validado pixel a pixel num conjunto de 42.462 linhas. Segundo o projeto, um teste de estresse renderizou 272.392 posições e orientações aleatórias sem nenhuma falha e sem divergência nos caches. Cada commit passa por um conjunto de regressão que compara o framebuffer em 18 posições e também o total de ciclos, para evitar lentidão silenciosa.
Como compilar
É preciso ter o DOOM1.WAD (a versão shareware, que não vem no repositório), Python 3 com pygame e py65, o beebasm incluído no projeto e as ferramentas ca65/ld65 do cc65. O comando python3 build_walk_ssd.py gera o disco jogável, e python3 play.py abre a versão interativa em Python, com a opção de alternar para o pipeline 6502 simulado. Há ainda um disco de demonstração com a câmera girando, o doom_spin.ssd.
Aproveite que está aqui e siga o Arkade no:
- Plataformas
- PlayStation, Xbox, PC
Leia também
Conto a história dos videogames e da velocidade de ontem e de hoje por aqui! Você pode me seguir em instagram.com/juniorcandido ou x.com/junior_candido E para contatos, envie sua mensagem para o e-mail [email protected]
Mais matérias de Junior Candido