Sky Paws Awakening

O Mega Drive (Motorola 68000) é muito menos tolerante que os emuladores. O jogo rodava perfeito no emulador, mas o console desligava de forma aleatória, geralmente na segunda metade das fases.

Como não dava para reproduzir no emulador, auditei o código por classes de erro típicas de hardware: índices fora dos limites, retornos de alocação sem checagem de nulo, buffers de texto de debug estourando a pilha (no 68000, sobrescrever o endereço de retorno não gera erro; o jogo simplesmente trava) e escrita no chip de vídeo durante a interrupção de vídeo.

Validação de limites nos pontos de entrada, checagem de retorno nulo em toda alocação de sprite, regras de tamanho para buffers de formatação e interrupções desabilitadas nas janelas críticas de escrita de vídeo (em transições, com a tela já preta, então sem custo visível).

“Passa no emulador” não prova nada. Cada causa virou regra de código e item de checklist de revisão, para o problema não voltar.

Sprites do jogador, inimigos e efeitos corrompiam ao mesmo tempo, de forma intermitente, mesmo com muita VRAM livre no visualizador de depuração.

Orçamento. Medi o pico de uso do pool de sprites em combate denso e ele ficava perto de 85%: nunca estourava o total.

Fragmentação. O motor precisa de um bloco contíguo. Sprites nascendo e morrendo deixam o espaço livre espalhado em buracos pequenos; quando o pedido é maior que o maior buraco, a alocação falha e o fallback do motor sobrepõe endereços, corrompendo tudo de uma vez.

Instrumentei o alocador para registrar, a cada falha, o total livre versus o maior bloco livre. A assinatura ficou óbvia: total alto, maior bloco pequeno.

Alocação tolerante a fragmentação (desfragmenta e tenta de novo) nos pontos críticos. O custo, cerca de um frame, só aparece como fallback raro. Achado relacionado: sprites pequenos e frequentes não podem usar compressão, pois a fila de DMA lia um buffer já liberado.

Correção confirmada em emulador.

O código original do Mega Drive é procedural: estruturas globais, funções grandes e uma ordem de atualização fixa, com cerca de vinte etapas por frame. Traduzir isso linha a linha para C# levaria o acoplamento junto.

Traduzir a lógica, não as limitações do hardware. O que existia só por restrição da plataforma não foi portado:

Cada sistema foi redesenhado com um orquestrador enxuto (só coordena), estados intercambiáveis, interfaces pequenas, serviços resolvidos por abstração e valores de tuning em ScriptableObjects.

Novos tipos de inimigo reaproveitam a mesma IA com dados e estados próprios, sem editar o núcleo. A arquitetura foi desenhada para que chefes e ataques novos entrem do mesmo jeito.

Manter o mesmo design em C/SGDK e em C#/Unity sem que virasse dois jogos diferentes.

O código original serve como especificação executável: valores de física, padrões de inimigos, fases de chefe e cenas de diálogo já estão definidos e testados nele. Cada feature portada é validada contra esse comportamento. A fidelidade é à visão de game design, não ao visual: a versão Unity usa gráficos modernos e não se compromete com a estética retrô. As diferenças intencionais são listadas em vez de deixadas ao acaso.

Paridade se define pelo comportamento observável, não pela semelhança do código. Ter as duas versões também expõe bugs de design que uma só esconderia.