Consoles modernos são mais caros devido à sua memória RAM, mas Sonic rodava perfeitamente há 35 anos em um Mega Drive com apenas 64 KB

Yuji Naka conseguiu fazer Sonic se mover em velocidade máxima no Mega Drive graças a técnicas de programação engenhosas

Com apenas 64 KB de RAM e um processador modesto, Sonic provou que a otimização faz mais diferença do que a potência bruta

Imagem | Joshua Doherty/Unsplash
Sem comentários Facebook Twitter Flipboard E-mail
pedro-mota

PH Mota

Redator
pedro-mota

PH Mota

Redator

Jornalista há 15 anos, teve uma infância analógica cada vez mais conquistada pelos charmes das novas tecnologias. Do videocassete ao streaming, do Windows 3.1 aos celulares cada vez menores.

2228 publicaciones de PH Mota

Há alguns anos, para começar a jogar videogame, você só podia escolher entre Mario ou Sonic. Ou seja, entre a Nintendo e seu Super Nintendo ou a Sega e seu Mega Drive. As duas empresas estavam moldando o rumo dos videogames no início dos anos 90, pelo menos no mercado doméstico e cada uma precisava se diferenciar com um recurso único. A Sega optou pela velocidade.

Sonic era rápido, o Mega Drive não

O hardware do console não era ruim para a época, mas tinha certas limitações. O principal obstáculo era o processador: o Motorola 68000, com 7,67 MHz, era um chip bastante capaz, mas não possuía um componente especializado em cálculos matemáticos complexos. Seus 64 KB de RAM também não ajudavam (com outros 64 KB dedicados ao vídeo).

Como o Mega Drive precisava de um jogo do Sonic de alta qualidade para impulsionar as vendas, a Sega confiou o projeto a Yuji Naka, cocriador da série. Como ele explicou em vídeo para o vigésimo aniversário do Sonic, Yuji deixou claro que os programadores não podiam abrir mão da velocidade.

Sonic

Naka relembrou as origens do projeto:

"Eu gosto de coisas rápidas e achei que seria interessante criar um jogo onde, quanto mais habilidoso você se tornasse, menos tempo precisaria para completar uma fase."
"Naquela época, os videogames não tinham sistema de salvamento, então, toda vez que você jogava, tinha que começar do zero. Hoje em dia, você pode retomar o jogo de onde parou, mas naquela época, você tinha que começar do nada."
"Como resultado, os jogadores repetiam a primeira fase várias vezes até dominá-la. Por isso, pensamos que seria bom aproveitar essa habilidade para que eles pudessem completar as fases cada vez mais rápido. Essa é a ideia por trás da velocidade do Sonic. Também acreditávamos que esse recurso ajudaria a diferenciar o Sonic do Mario."

Um rival para Mario

A Sega queria desafiar o domínio da Nintendo e seu NES. A equipe que eventualmente se tornaria a Sonic Team queria criar um jogo de ação frenético baseado em inércia e velocidade. Pode parecer algo comum hoje em dia, mas no início dos anos 90, não havia nada parecido.

Percorrer a Green Hill Zone, especialmente os lendários loops, exigia a simulação contínua de trajetórias usando fórmulas trigonométricas. Calcular senos e cossenos em tempo real sobrecarregaria o processador do Mega Drive, causando lentidão significativa. Então, a equipe de Naka projetou um motor gráfico personalizado para superar essas limitações.

A solução

Isso envolvia armazenar uma espécie de catálogo de resultados pré-preparados no cartucho. Em vez de repetir operações complexas constantemente, o motor gráfico do Sonic consultava uma tabela para encontrar o valor de cada ângulo e determinar como ele deveria afetar o movimento. Essas tabelas eram chamadas de tabelas de consulta (LOA).

Além das tabelas, os programadores da Sonic Team criaram outras soluções engenhosas para superar as limitações do console:

  • Dois sensores sob os pés: eles detectavam a distância até o chão e calculavam a inclinação das rampas para adaptar o movimento do Sonic.
  • Velocidade e impulso: a física permitia que o Sonic usasse sua velocidade para descer rampas e completar os famosos loops.
  • Movimento e animação independentes: a posição era atualizada 60 vezes por segundo (em NTSC; na Europa, jogávamos com a taxa de atualização de 50 Hz da versão PAL). E os sprites mudavam de acordo com a velocidade do personagem.
  • Código otimizado: Naka usou o desenrolamento de loops para eliminar verificações repetitivas e economizar ciclos no processador Motorola 68000.
  • Recursos na tela: inimigos e objetos fora da tela não eram processados ​​para reduzir a carga do sistema.
  • O mito do Blast Processing: a Sega transformou essa fluidez em um argumento de marketing, embora a velocidade do Sonic fosse principalmente resultado da otimização do código, e não de um componente secreto.

A Sega e a Sonic Team criaram um jogo que, até hoje, continua a impressionar com sua velocidade, mesmo no Mega Drive, um console de 36 anos. Ainda me lembro da primeira vez que coloquei o cartucho no console, carreguei a fase Green Hill e fiquei maravilhado porque o Sonic se movia muito mais rápido do que eu conseguia ver. Nunca mais experimentei essa sensação de velocidade com nenhum outro jogo desde então.

Otimização é história

Yuji Naka e a Sega provaram que engenhosidade e otimização, em última análise, superam as limitações de hardware. É uma lição que parece não ter sido totalmente assimilada, porque os desenvolvedores de hoje tendem a criar verdadeiros monstros com seus jogos. Gigabytes de recursos, requisitos de hardware incrivelmente altos... E então temos consoles cada vez mais caros apenas para atender a todas essas demandas.

A ironia de tudo isso parece ter deixado a Nintendo como a verdadeira herdeira de toda essa otimização: os jogos do Switch são um monumento à otimização. Porque o Sonic não precisava de um console mais poderoso para rodar mais rápido: ele precisava de programadores que soubessem como utilizar cada ciclo do processador. Trinta e cinco anos depois, revisitar essa filosofia não seria uma má ideia.

Via | jeuxvideo.com

Imagem | Joshua Doherty/Unsplash

Texto traduzido e adaptado do portal parceiro Xataka Espanha.

Inicio