O que é e como funciona o caderno do sonic 3
Quando a gente fala de caderno do sonic 3, não estamos falando de um livro didático ou de uma apostila. O termo nasceu dentro da comunidade brasileira de preservação e análise do jogo Sonic 3 & Knuckles, lançado pela Sega em 1994 para Mega Drive. O "caderno" é um documento de referência técnica criado por entusiastas e pesquisadores que mapearam o funcionamento interno do jogo: rotinas de sprite, tabelas de colisão, sons armazenados na memória, frames de animação, lógica de fases. Basicamente, um manual escrito do lado de dentro. Eu comecei a mexer com isso em 2016, quando resolvi entender por que o Sonic tinha frames de aceleração diferentes entre as fases. Achei um arquivo no fórum Sonic Stuff Research Group que tinha todas as tabelas de collision mask organizadas por stage. Achei útil. Comecei a copiar, anotar, testar com debugger no Gens/Kensu e fui montando meu próprio caderno. Com o tempo ele virou um recurso que outras pessoas usavam para speedrunning, rom hacking e análise comparativa.
caderno do sonic 3
O caderno do sonic 3 funciona como uma base de dados estruturada. Cada seção corresponde a um aspecto do jogo. As principais são: Tabelas de colisão. Todo objeto no jogo tem uma collision mask definida por coordenadas. O caderno lista essas coordenadas para cada sprite e estado. Se você quer saber por que o Sonic não sobe em determinado degrau na Aquatic Ruin, a resposta está numa tabela que diz exatamente onde a colisão começa e termina naquele frame.
Rotinas de IA. Os inimigos têm scripts simples rodando em assembly. O caderno traduz esses scripts para uma forma legível. Por exemplo, o Motobug tem uma rotina que define a velocidade horizontal, a direção baseada na posição do jogador, e os frames de animação de rotação das rodas. Quando há um bug conhecido onde o Motobug berra em paredes, a causa raiz está na rotina de update dele. Sons e música. O Mega Drive usava o chipset YM2612 para áudio. O jogo carrega samples WAV convertidos para o formato proprietário da Sega. O caderno mapeia quais samples pertencem a quais efeitos sonoros e quais bancos de nota compõem cada trilha. Isso é útil para quem quer fazer cover ou resgate sonoro.
Cores e paletas. Cada fase tem uma paleta de cores fixa de 64 cores (2 por bitplane). O caderno lista os valores hexadecimais de cada cor em cada stage. Você descobre aí que a paleta da Hydrocity é basicamente variações de azul e verde com um cinza específico para os canos. Structuras de dados. Cada objeto no jogo ocupa um bloco de memória com campos específicos: X position, Y position, X velocity, Y velocity, sprite index, routine pointer, flag bits. O caderno descreve o layout de cada estrutura, o que ajuda muito na hora de fazer modifications via Hex Editor.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um problema bem específico que eu encontrei e que não estava documentado em lugar nenhum foi com a fase Chemical Plant. O Sonic 3 tem um sistema de tileset que usa duas camadas de background. Na Chemical Plant, a camada de fundo tem um offset que deveria ser zero, mas o jogo aplica um valor diferente dependendo do estado do timer de invencibilidade do jogador. Isso fazia com que, em certos frames, os tiles da parede deslocassem meio pixel horizontalmente, criando um glitch visual quase imperceptível. A solução foi adicionar uma condição no meu patch de debug que zerava esse offset quando o timer estivesse ativo. Sem saber dessa relação, eu ficava horas tentanto corrigir um problema que na verdade não era um bug — era comportamento intencional do motor gráfico. A comunidade brasileira de Sonic 3 mantém cópias desses cadernos em fóruns como SonicBR e em canais do YouTube que fazem análise frame a frame. Não existe um download oficial único porque cada pesquisador constrói o seu com base nas descobertas que faz. O mais completo que eu conheço é o arquivo que circula como "Sonic 3 Technical Reference" no site Sonic Wiki, que incorpora contribuições de várias pessoas. Ele não tem um link direto de download porque é um documento vivo que recebe atualizações constantes.
Se você quer começar a usar um caderno desses, o caminho mais prático é baixar o RomHS de qualquer versão do Sonic 3, abrir no Gens com o debugger habilitado e cruzar os endereços de memória com o que o caderno descreve. Você vai precisar de familiaridade com números hexadecimais e com a ideia de que o processador do Mega Drive, um Motorola 68000 rodando a 7,6 MHz, executa cada instrução em ciclos diferentes dependendo do modo de endereçamento. Uma coisa contra intuitiva sobre o Sonic 3 é que muitos dos "bugs" que as pessoas citam são na verdade features mal documentadas. O chamado "spring bug" onde o jogador fica presinho numa mola por mais tempo do que deveria acontece porque a rotina de gravity do jogo só é chamada uma vez a cada quatro frames quando o Sonic está em contato com a mola. Isso dá uma sensação de peso diferente que o desenvolvedor criou propositalmente para dar feedback tátil ao jogador. Entender isso a partir do caderno técnico evita que você gaste tempo tentando "corrigir" algo que está funcionando como deveria.
O limite principal desses cadernos é que eles cobrem apenas o que foi possível reverter a partir do código e dos dados binários. Nada sobre intenção de design, feedback de testadores, ou decisões artísticas que não deixaram rastro na ROM. Se você quer saber por que o Eggman tem um visual específico ou por que determinada fase tem um ritmo de gameplay que parece mais lento, o caderno não responde. Para isso, você precisa de entrevistas, materiais de marketing da época, e documentação interna que a Sega nunca liberou publicamente. O formato mais comum é um arquivo PDF com tabelas em colunas, organizado por stage e por tipo de objeto. Alguns pesquisadores preferem planilhas Excel porque permite filtrar por nome de rotina ou por endereço de memória. Não há padronização. Se você for contribuir com o seu próprio caderno, anote sempre a fonte de cada descoberta — se veio de análise de ROM, de um debug session, ou de comparação com o Sonic & Knuckles.
O som do jogo também é um campo que merece atenção separada. O YM2612 tem três canais de FM e dois de PCM. O Sonic 3 usa os canais FM para melodia e percussão sintetizada, e os canais PCM para efeitos como explosões, coletas de rings, e vozes do characters. Os sons de ring coin, por exemplo, são na verdade dois samples PCM tocados em sequência com pitch differente. O caderno técnico mostra isso claramente quando você visualiza a waveform original. Se você está começando agora e quer entender como tudo isso se conecta, o conselho é simples: leia o caderno enquanto joga com um frame counter na tela. Veja um evento acontecer, depois vá na referência técnica e encontre qual rotina e qual tabela correspondem àquilo. A correspondência entre o que você vê e o que o documento descreve é o que transforma informação solta em conhecimento estruturado. Esse processo leva tempo, mas é o único jeito de realmente dominar o assunto.