[#1857][Fev/1987] CONTRA

Então... Contra.

Um dos videogames mais famosos de todos os tempos, um dos pilares da biblioteca do NES nos anos 80 e, por consequência, da própria história dos videogames. Um jogo tão popular, tão discutido e tão analisado que praticamente não existe mais nada a dizer sobre ele que já não tenha sido dito. Quer dizer, sério, você já conhece as referências ao Stallone e ao Schwarzenegger, os xenomorfos, a Spread Gun, o Konami Code e todo esse jazz. Então o que diabos eu poderia dizer sobre um jogo tão emblemático que você já não saiba ou não tenha percebido por conta própria?

Bom, na verdade, várias coisas já que eu sou muito mais inteligente que todos vocês.
E muito mais humilde também, naturalmente.

Mas falando sério, eu joguei Contra para esta review e uma coisa que me chamou a atenção foi a quantidade absurda de merda acontecendo na tela a qualquer momento. Não absurda no sentido de "Nossa, como esse jogo é difícil, hahaha" — embora certamente seja —, mas absurda no sentido de "Peraí... como diabos o NES consegue processar tudo isso sem explodir em chamas?".

Porque, sério, eu já analisei 176 jogos de NES para este blog e vi a coisa inteira se transformar num festival de flickering, engasgos e câmera lenta com muito, MUITO menos acontecendo na tela. Já vi jogos terem dificuldades para mostrar três inimigos e um projétil sem parecer que o console estava tendo um AVC. Enquanto isso, Contra tem soldados correndo para todo lado, balas voando, explosões, plataformas móveis, dois jogadores ao mesmo tempo e, de alguma forma, o negócio continua funcionando.

Então que tipo de bruxaria a Konami está fazendo aqui?

Bom, é assim que a mágica funciona: o NES conseguia exibir até 64 sprites de hardware simultaneamente, cada um medindo 8×8 ou 8×16 pixels. É um número surpreendentemente generoso para uma máquina de 1983, mas havia uma pegadinha. E por "pegadinha" eu quero dizer aquele tipo de cláusula em letras miúdas que faria uma operadora de telefonia ficar orgulhosa: apenas oito sprites podiam ocupar a mesma linha horizontal da tela em cada frame.

Isso mesmo. A verdadeira limitação não era necessariamente quantos sprites você tinha na tela, mas quantos deles ocupavam a mesma linha horizontal. Passou de oito, o NES simplesmente deixava de desenhar o nono sprite e todos os seguintes na ordem de prioridade do hardware. Não importava se eles estivessem em lados opostos da tela cuidando das suas vidas ou lembrando do filho que deixaram em casa antes de ir a guerra. Se compartilhassem a mesma linha, estariam disputando as únicas oito vagas.

E lembre-se de que um sprite não é necessariamente um personagem inteiro. Um soldado podia ser montado a partir de vários pequenos sprites, o que significa que apenas alguns personagens e um punhado de balas já deu o seu limite.

O exemplo mais iconico desse Frankentein é o Goomba do primeiro Super Mario Bros. Pra ficar um boneco grande e vistoso na tela, ele contornava as limitações de tamanho do NES sendo montado com quatro sprites — dois por linha. O que significa que quatro desses carinhas e já estourava o limite do hardware

Agora, sendo você um biscoitinho esperto, provavelmente já percebeu uma solução óbvia: se o problema é ter sprites demais na mesma linha horizontal, por que não distribuir os inimigos por diferentes alturas? Fácil, fácil, certo?

Bom, "fácil" é uma palavra um pouco forte, mas sim, essa é uma das maneiras mais diretas de lidar com o problema. E, de repente, você começa a entender por que inimigos voadores eram tão convenientes para os desenvolvedores de NES, e pq diabos tantos e tantos jogos de Nintendinho tinham morcegos. Mais do que um fetiche com o Ozzy Osborn, agora vc sabe que um morcego voando acima da cabeça do jogador não compete o tempo todo com os sprites que compõem o corpo do personagem, o que torna muito mais fácil acomodar outro inimigo na tela. Você pode conseguir o mesmo resultado com cabeças de Medusa, Hammer Bros. arremessando martelos de plataformas elevadas ou praticamente qualquer coisa que não insistisse em compartilhar os mesmos oito pixels de espaço vertical do protagonista.

Claro, eu suponho que alguns morcegos do NES estão lá porque são tematicamente apropriados e não apenas por causa dessa limitação de hardware. Mas então, se você está programando para um console que vai full Karen sempre que coisas demais ocupam a mesma linha horizontal, de repente morcegos se tornam uma escolha bastante atraente muito antes da Rouge the Bat.

Contra, obviamente, tira proveito disso e para um run-and-gun suas fases de rolagem lateral fazem um uso do espaço vertical bem extensivo. Os inimigos aparecem em plataformas elevadas, saltam entre diferentes alturas, atacam por cima, por baixo, pelas costas, de cima de morrinhos, da sua mãe. Existe até uma fase inteira construída em torno de escalar uma cachoeira, o que certamente aliviou um bocado do trabalho da programação ali — ainda que não alivie nada para o jogador. 

E eu realmente acho muito maneiro quando level design e limitações de hardware trabalham juntos para criar uma experiencia única, que talvez não fizesse tanto sentido em qualquer outro equipamento.

O que é ótimo, obviamente, mas mesmo com todos esses truques, Contra ainda tem merda demais acontecendo na tela para que um posicionamento inteligente dos inimigos resolva tudo. Então o que a Konami faz?

Bom, não existe nenhuma gambiarra de software capaz de simplesmente convencer o NES a desenhar um nono sprite na mesma linha horizontal. Essa é uma restrição de hardware, e mudá-la exigiria modificar o próprio console, o que provavelmente resultaria em você acordar e encontrar Hiroshi Yamauchi parado no seu quarto segurando um taco de beisebol.

Com pregos.

Mas é aqui que entra a parte inteligente: uma vez que você sabe que o hardware vai descartar um sprite, pode controlar quem tem prioridade em vez de simplesmente aceitar que o mesmo coitado desapareça toda vez.

O NES tem uma pequena área de memória chamada OAM (Object Attribute Memory), onde fica uma lista dos sprites na tela. O processador gráfico percorre essa lista em ordem, selecionando os primeiros oito sprites que encontrasse em cada linha horizontal. Só que o truque aqui é que quem escreve essa lista é você, então nada impede de vc dizer ao NES que o sprite 1 é a bunda do Mario, mas a barriga dele é só o sprite 5 ou 6 da linha. 

Tá, mas no que é que isso ajuda?
Então imagine que nove sprites estejam disputando oito vagas disponíveis. Você poderia organizar a coisa assim:

• Frame 1: Exibir os sprites 1, 2, 3, 4, 5, 6, 7 e 8.

• Frame 2: Exibir os sprites 1, 2, 3, 4, 5, 6, 7 e 9.

• Frame 3: Exibir os sprites 1, 2, 3, 4, 5, 6, 7 e 8.

• Frame 4: Exibir os sprites 1, 2, 3, 4, 5, 6, 7 e 9.

Percebeu o que aconteceu? Os primeiros sete sprites permanecem visíveis o tempo todo, enquanto os sprites 8 e 9 se revezam. Vc está exibindo 9 sprites burlando o limite do hardware de oito sprites por linha.

E você pode levar esse princípio ainda mais longe: suponha que doze sprites estejam disputando as mesmas oito vagas. Mantenha os quatro primeiros visíveis em todos os frames e alterne entre os sprites 5–8 e 9–12. Ou faça um rodízio das prioridades entre todos eles, distribuindo os frames perdidos pelo grupo inteiro. Existem diferentes maneiras de lidar com isso, dependendo do que os programadores desejam priorizar.

A partir daí, é basicamente um exercício de malabarismo. Você é um mágico de palco tentando convencer a plateia de que existem mais coisas na tela do que o hardware realmente consegue exibir simultaneamente, decidindo o que ela deve ver e o que você pode esconder por alguns instantes sem estragar a ilusão.

[TÁ, MAS SE VOCÊ FICAR ALTERNANDO OS SPRITES DESSE JEITO, NÃO VAI FICAR TUDO PISCANDO O TEMPO INTEIRO?]

Sim! Parabéns, você descobriu o que chamamos de flickering.
É literalmente isso que ele é.

Mas existe um detalhe que costuma passar despercebido quando as pessoas discutem as maravilhas tecnológicas dos anos 80: o NES conseguia produzir aproximadamente 60 quadros por segundo.

Naquela época, ninguém se preocupava muito com FPS como argumento de marketing porque todo mundo estava ocupado demais discutindo bits. Oito bits! Dezesseis bits! Trinta e dois bits! Sessenta e quatro bits! Tua prima bits! Quanto mais bits você tivesse, mais poderoso seu console seria até que você tivesse o suficientes para dar um soco na fuça de Deus.

Só que que não é assim que a arquitetura de computadores funciona. Bits servem para coisas específicas na arquitetura de computadores, não como uma régua universal de potência. Tanto eles não são uma medida universal de poder que o PlayStation 5, por exemplo, tem uma arquitetura de CPU de 64 bits e eu não acho que alguém argumentaria a serio que ele pertence à mesma categoria de desempenho do Nintendo 64.

Bom, quase ninguém. Afinal, estamos na internet.

Mas 60 FPS é um número que faz sentido ainda hoje, e é impressionante para um hardware de 1983 com um processador de 1,79 MHz e um total de 2 KB de RAM principal. São dois quilobytes, não megabytes. Dificilmente vai ter um emoji no seu celular que ocupe menos espaço do que isso.

E aqueles 60 quadros davam aos programadores do NES uma coisa muito útil: tempo.

Se dois sprites alternassem sua visibilidade a cada frame, cada um apareceria 30 vezes por segundo, enquanto o restante do jogo poderia continuar sendo atualizado a 60 FPS. Claro que um flickering de 30 Hz é perfeitamente perceptível ao olho humano e ainda que as TVs de tubo suavizavam a aparência de certos efeitos graças à como sua exibição analógica funcionava, ainda dava pra notar. 

Então não tinha quantidade de magica suficiente no mundo que a Konami podia fazer para eliminar o flikering inteiramente, mas eles o que eles fizeram foi administrar o flickering para que o jogo continuasse jogavel. Uma coisa é o seu boneco parecer oco em alguns quadros de animação, outra é inimigos ou balas ficarem invisiveis — o que acontecia mais do que vc poderia esperar no Nintendinho, e eu estou assumindo que vc já espera bastante.

E num jogo como Contra, dificil pra caceta que vc morre com QUALQUER contato (pq aparentemente a única esperança da humanidade contra a invasão alien é o personagem do Samuel L. Jackson em Corpo Fechado), essa é a diferença entre sobreviver e arremessar o controle pela sala porque algum filho da puta atirou em você com uma bala que só existia em outra dimensão.

E essa também não era a única maneira como a Konami mantinha as coisas sob controle, o jogo também utilizava os tiles do cenário para representar estruturas grandes e relativamente estáticas em vez de desperdiçar preciosos slots de sprites — sim, a maioria dos chefes, do ponto de vista do jogo, são cenário. E como os programadores precisavam ter um controle muito fino do que acontecia em cada linha, o jogo não podia apenas spawnar inimigos aleatoriamente: os spawn points são cuidadosamente escolhidos para não fazer o hardware pedir as contas.

Em outras palavras, os desenvolvedores da Konami não estavam simplesmente tentando espremer mais inimigos dentro do NES e torcendo pelo melhor, como muitas desenvolvedoras faziam na época. Eles decidiam quantos inimigos deveriam existir em determinado momento, onde deveriam aparecer, como deveriam se mover e de que maneira seus gráficos disputariam os recursos disponíveis do hardware. A ação pode parecer caótica para o jogador, mas todos os seus movimentos foram friamente calculados.

Mas eu preciso dizer que é óbvio que isso não funciona 100% perfeito também, né?

Contra ainda tem flickering. Ainda tem slowdown. Coloque dois jogadores na tela com Spread Guns, alguns inimigos e tiros suficientes, e mais cedo do que tarde o NES vai te olhar e mandar um: "Estou cansado, chefe". Existe um limite para o que uma programação inteligente consegue fazer antes que o hardware lembre a todo mundo quem realmente manda. E nenhuma quantidade de Código Konami — não aquele de cima, cima, baixo, baixo, esquerda, direita, esquerda, direita, B, A — consegue ignorar totalmente a limitação de hardware.

Ainda assim, é impossível não admirar a engenhosidade envolvida e a quantidade absolutamente ofensiva de trabalho necessária para fazer uma coisa dessas funcionar.

Hoje você pode pedir a uma inteligência artificial que escreva uma rotina de rotação de prioridade de sprites, sair para tomar um mocha latte e voltar... para descobrir que ela inventou com absoluta confiança três instruções para o processador que não devia, uma delas envolvendo assassinar seus doguinho enquanto vc dorme. Cada geração tem seus próprios problemas, eu suponho... mas de qualquer forma, o fato é que em 1988 alguém precisava sentar e escrever a porcaria toda na unha em Assembly, testá-la no hardware de verdade, descobrir por que o nono sprite continuava desaparecendo e então fazer todo o resto do jogo funcionar ao redor dessas limitações sem comprometer a ação.

E tudo isso ainda precisava caber no mesmo jogo que o comportamento dos inimigos, a detecção de colisões, os dados das fases, as músicas, os efeitos sonoros, as animações e todo o resto necessário para fazer um videogame. A versão americana de Contra espremia seus dados de programa e gráficos em míseros 128 KB de ROM e mesmo o cartucho japonês de Famicom tendo 256 KB... mano, 128KB a mais não é exatamente um latifundio virtual né?

Esse é o tipo de coisa que passa despercebida quando discutimos jogos antigos apenas em termos de como eles se comparam aos modernos. Você olha para Contra hoje e vê um bando de soldadinhos minúsculos correndo por aí e atirando balinhas minúsculas em outros soldadinhos minúsculos, e talvez não pense muito a respeito. Mas, uma vez que vc entende do que o NES era capaz e quantas gambiarras os desenvolvedores tinham que negociar com o hardware, a coisa toda começa a parecer menos um simples jogo e mais um exercício extremamente elaborado de enganar a máquina a fazer algo que ela muito preferia não estar fazendo.

Em 1988, Contra era um jogo divertido pra caceta.
Em 2026, é um testemunho impressionante do trabalho artesanal por trás do desenvolvimento de videogames.

MATÉRIA NA SUPER GAME POWER
EDIÇÃO 96 (Outubro de 2002)