Budfolk reconstruiu trechos de Super Mario 64 para o Atari Jaguar, escrevendo um motor novo em assembly e fazendo o console rodar cenas do jogo original de forma nativa. Quatro áreas estão implementadas: os arredores do castelo (castle grounds), o térreo do castelo, Bob-omb Battlefield e Tiny-Huge Island.
Como o projeto foi feito
Segundo Budfolk, o código 3D é dividido entre os dois processadores RISC do Jaguar, enquanto o Motorola 68000 fica responsável pela lógica do jogo. O som também foi aproveitado de forma criativa: o processador DSP do console faz verificações de visibilidade, transforma parte da geometria, responde a pedidos de colisão e mixa 12 vozes de música a 10,9 kHz. O “GPU” do Jaguar realiza transformações restantes, clipping (remoção de partes fora da vista), ordenação e desenho dos polígonos.
Como o Jaguar não dispõe de um Z-buffer (uma estrutura que guarda profundidade por pixel para determinar quais objetos ficam na frente), Budfolk implementou um método alternativo: o renderer ordena triângulos em 256 “baldes” e os desenha nessa sequência. Mario recebeu uma faixa própria nesses baldes para reduzir a chance de o terreno atravessar o personagem. Texturas são lidas da memória do cartucho usando o blitter, o subsistema de cópia/transformação de dados gráfico do Jaguar.
Desempenho e escolhas técnicas
Em hardware real, Budfolk relata taxas entre 12 e 20 frames por segundo, variando conforme a cena, com uma imagem de 320 pixels de largura e a distância de visão completa do jogo original. Para comparar, ele cita números aproximados do N64 na faixa de 20–30 fps, referenciando o trabalho do otimizador Kaze Emanuar.
O desenvolvedor testou algumas otimizações e descreveu os efeitos: renderizar apenas linhas horizontais alternadas aumentou a velocidade em cerca de 32%; reduzir a distância de visão para cerca de um terço proporcionou ganho de ~55% durante um voo sobre os arredores do castelo, mas fez surgirem elementos do cenário abruptamente (pop-in). Budfolk optou por manter a distância completa como padrão, oferecendo a distância reduzida em um menu.
Outras tentativas tiveram pouco ou nenhum efeito: remover geometria submersa não trouxe ganhos, e reduzir pela metade a taxa de atualização da física trouxe menos de 0,5% de melhoria. Segundo ele, o gargalo principal é a largura de banda de memória do blitter. Uma tabela pré-computada para pular partes invisíveis melhorou o desempenho dos arredores do castelo em cerca de 12–16% nos testes.
Mostra em emulador e em console real
Há uma gravação mais longa feita no emulador BigPEmu, além de um vídeo mostrando o jogo rodando em um CRT ligado ao hardware Jaguar real. Budfolk observa que a filmagem com celular apontado para a TV parece mais instável por falta de sincronização entre a câmera e o CRT, o que pode dar impressão de desempenho inferior.
Restrição à divulgação
Há um detalhe importante: Budfolk afirma que este é um experimento de hardware não comercial e declara que não serão liberados ROMs, dados do jogo ou builds. Ele também diz que as ferramentas de conversão usam um exemplar original legalmente obtido e permanecem em suas máquinas. Não há menção a alguma notificação ou exigência da Nintendo forçando o sigilo; a decisão de não publicar o projeto foi tomada pelo próprio desenvolvedor. Budfolk não explicou se o motor reescrito ou as ferramentas poderiam ser separadas dos ativos da Nintendo ou se isso exigiria trabalho adicional.
O projeto mostra soluções técnicas e limitações práticas ao portar um jogo 3D complexo para hardware com arquitetura e recursos muito diferentes, mas, por enquanto, permanece fechado ao público.
Fonte: Retro Replay