Microcodes: O ponto fraco e forte do N64!

Esse é um dos aspectos mais obscuros do N64 e poucas pessoas têm conhecimento disso, embora isso, os microcodes são extremamente essenciais para o sistema e estão relacionados diretamente com a qualidade dos games, como vocês perceberão a seguir.

Antes de começar, caso você não tenha conhecimento do hardware do N64 e de como ele funciona, sugiro que leia antes os outros posts que tem aqui no blog que explicam um pouco sobre as estranhas do N64, esse conhecimento será útil para o que veremos hoje. Não se preocupe que não entrarem em detalhes em aspectos técnicos. Esse post só complementará o que já foi abordado nos outros posts.

Segue os links dos posts sobre o Hardware do N64:

Parte 1 – Introdução e processador


Parte 2 – Memória RAM


Parte 3 – RCP e gráficos


Comparação do Hardware N64 VS PlayStation

Agora vamos aos Microcodes

Desenvolver para o N64 não era a melhor coisa do mundo, é muito fácil ver comentários ou depoimentos de alguns desenvolvedores falando como era difícil criar um game para o sistema, sendo o obstáculo que o mais conhecido, a mídia do N64: o cartucho. Por ser uma mídia que tem pouca capacidade de armazenamento de dados, não era possível criar games gigantescos, com cutscenes, trilhas sonoras de alta qualidade (não que o N64 não fosse capaz de reproduzir músicas com qualidade de CD, a capacidade do cartucho e o processamento do N64 que impediam de se aproveitar o máximo do som) e etc.

Se o N64 está associado ao “borrão”, é por causa de sua limitação, os desenvolvedores só podiam usar texturas com 4KB de tamanho, o que eles faziam era pegar a imagem pequena e depois esticá-la o máximo possível, depois borrar ela para esconder o pixelado e o resultado disso já conhecemos, um anti-alisiang que pode mais atrapalhar do que ajudar (sobre assunto abordado em outro posts do blog).

De qualquer forma, algo bem interessante quanto ao hardware do N64 é que o RCP (Reality Co-Processor ou GPU) e o audio co-processor são programáveis através de microcode.

Microcode é uma técnica de escrever um código que fará a ponte entre o software e o hardware, no caso do N64 o Microcode é usado para dar instruções a RCP para que ela faça determinadas ações e tarefas, esse processo envolve outros dois componentes do N64, o Reality Signal Processor (RSP) e the Reality Display Processor (RDP). Com o Microcode é possível explorar mais a potência do hardware, para que ele faça mais efeitos e tenha mais polígonos.

 (Um esquema que mostra como funciona o N64, veja que o coração do console é o RCP, as setas indicação a via das informações)

O Microcode padrão do N64 foi desenvolvido pela SGI e Nintendo, o problema era que esse Microcode era muito básico, difícil de lidar e com uma documentação muito pobre (quase inexistente). Isso acabou afetando vários games, que acabaram tendo uma qualidade duvidosa e com vários bugs e glitches.

Sem querer entrar nesse assunto muito detalhadamente, existiu vários tipos de Microcode, o padrão do sistema é o Fast3D, que permite de 100.000 polígonos, sendo ele mais preciso do que rápido, o que a Nintendo usava era o Turbo3D que permitia ter 500.000 – 600.000 polígonos, todavia a Nintendo não recomendava o uso desse último pelo fato que o gráfico não ficava bom. Por exemplo, o modelo do Mario no game Super Mario 64 é composto por 700 polígonos.

Vamos ao exemplos!

 (Daqui para frente deixará de ser técnico e será mais tranquilo, eu prometo!)

Apesar disso, os estúdios poderiam muito bem criar o seu próprio Microcode caso quisessem. Foi o que a Rare fez! Como muitos devem saber o Donkey Kong 64 só precisa do Expansion Pak para evitar um bug, exceto por isso, não seria realmente necessário (O Donkey Kong 64 não está nem em alta-resolução, somente o logo da Rare no início do game está em 480p), agora Conker Bad Fur Day é um game impressionante, tecnicamente falando, tem gráficos bonitos, tem dublagem e cutscenes usando gráficos em tempo real, isso levanta a pergunta, como é que esse game é bom bonito e não precisa de Expansion Pak. Bem, parte da resposta está no Microcode que a Rare criou (muitas das melhorias do Conker se devem ao fato que a Rare teve tempo para trabalhar esse título, anos para ser mais exato, internamente a Rare era dividida em diversos grupos de pessoas que trabalhavam em projetos diferentes).

Não só a Rare fez isso, a Factor 5 fez algo ainda mais impressionante!

O port do game Indiana Jones do Pc para N64 foi trabalhoso, mas valeu a pena! O objetivo deles era ter o game em alta resolução e com gráficos bonitos, eles conseguiram colocar tudo que tinha na versão de Pc e um pouco mais, a versão de N64 tem músicas extras, eles criaram uma engine de luz e sombria em tempo real, câmera melhorada. A Factor 5 usou o cartucho quase como uma memória RAM adicional, então as fases são transmitidas, o que deixa tudo mais rápido. Além disso, eles conseguiram burlar a limitação de 4KB das texturas. Resumindo, o game do Indiana Jones: The Infernal Machine é um exemplo de como um bom time de desenvolvimento e um bom Microcode customizado conseguem realizar (e eles transformaram o cartucho em um ponto a favor).

E não paramos aqui! Ainda temos o Star Wars Rogue Squadron e Battle for Naboo. Com o Microcode customizado, foi possível criar uma paisagem em alta resolução para o Rogue Squadron, que é o segundo game a se beneficiar do uso do Expansion Pak (o primeiro é o Turok 2: Seed of Evil). Já com o Battle for Naboo, a Factor usou o que aprendeu com o Rogue Squadron, mas preferiram começar do zero com um novo Microcode, o objetivo deles era ter um game que rodasse em alta resolução, com paisagens bonitas (efeitos de clima incluso) e com um framerate constante, com isso Battle for Naboo tem um draw distance maior que o seu predecessor, com chuva e neve que podem ter 3.000 partículas sem prejudicar o framerate.

Outro caso de Microcode customizado é o game World Driver Championship do estúdio Boss Game Studio, uma desenvolvedora especializada em games de corrida para o N64. Com o uso do Microcode, a BGS conseguiu no WDC: modelos de alta contagem de polígonos, um draw distance grande, texturas de alta qualidade, efeito Doppler com áudio MP3 (N64 tem suporte a diversos formatos de áudio) e efeito realista de tempo. E a cereja do bolo é que o game tem suporte à alta resolução sem o uso do Expansion Pak! Isso sem comprometer o framerate do game!!! Isso é algo que muito games não conseguiam fazer mesmo com o Expansion Pak!

Muitos já devem ter notado o padrão: Indiana Jones The Infernal Machine, Star Wars Rogue Squadron, Battle for Naboo e World Driver Championship são games que tem problemas para serem emulados. Isso é por causa justamente do Microcode. Eu deixarei aqui a lista de compatibilidade atual do Project (http://pj64wiki.com/index.php?title=N64_Official_Game_List), atualmente eles até funcionam melhor!

Até a Trevas tem o seu charme?

Talvez, também podemos incluir nesse panteão a Silicon Knights, onde, originalmente, estava desenvolvendo o Eternal Darkness para o N64, nunca saberemos como esse game ficaria no N64 depois de pronto, porém, através de relatos da época,  como da IGN (clique aqui) e do próprio desenvolvedor, Denis Dyack, o Eternal Darkness não precisava de Expansion Pak para ter alta resolução, quando eles mostraram esse game para a Nintendo, eles não acreditaram nesse feito e até abriram a porta de expansão para constatar que realmente só estava o Jumper Pak. Além disso, o Eternal Darkness era totalmente 3D, diferente do Resident Evil e contava com 30fps constantes. Porém, não podemos confirmar como a Silicon Knight conseguiu tal feito no N64, se foi através de muita compressão e chips especiais ou se realmente estava usando um Microcode excelente!

Mesmo sem ser lançado oficialmente, Eternal Darkness deve ser um dos feitos, se não o mais impressionantes da biblioteca do N64!

E o que aprendemos aqui?

A arquitetura do N64 não foi uma das mais bem desenvolvidas, mesmo que o N64 tenha sido divulgado como um console de 64-bits, seu funcionamento era na verdade em 32-bits (não estamos falando de gráficos, sim de processamento, ou melhor ainda, BUS da memória), tudo isso criava uma latência grande no console, o espaço de armazenamento do cartucho só piorava ainda mais a situação!

Jogue o microcode mal feito e documentado, temos uma receita para o desastre! Não é a toa que muitas Thirds sofreram para desenvolver para o N64 (não joguem toda culpa no cartucho).

Ainda sim, como tudo na vida, sempre existe um jeito! E se o estúdio soubesse trabalhar, conseguiria ‘tirar leite de pedra’ no N64, principalmente se ele fizesse o seu próprio microcode. Temos bons exemplos que mostram que o N64 tinha potencial muito grande, games como a série Star Wars da Factor 5, alguns games da Rare e WDC da Boss Games mostram que era sim possível extrapolar o limite do N64 (Factor 5 era tão habilidosa que foi ela que fez a compressão do áudio no Pokémon Stadium, veja na tela título).

Sendo assim, podemos perceber que uma parcela da ‘culpa’ na qualidade dos games do N64 se deve justamente ao próprio N64 em si! Ainda sim, o N64 não se compara ao desenvolvimento de games para o Saturn (que é ainda pior para se desenvolver! O que não estou dizendo que o Saturn é pior que o N64 em games!).

Se a Nintendo e SGI tivessem feito o N64 bom uma melhor organização dos componentes internos (o N64 sofreu adiantamentos no seu lançamento) e tivesse desenvolvido um Microcode padrão melhor, a história poderia ser muito bem diferente e hoje o N64 poderia ter uma biblioteca de games mais vasta e com uma qualidade ainda maior. Sinceramente, as vezes, até parece que a Nintendo não aprendeu a lição (Sim! Estou me referindo ao Wii e Wii U).

Espero que tenham gostado de mais um artigo sobre o hardware do N64 e de como ele funciona! Deixem o seu comentário e até a próxima!

---

Siga-nos em nossas outras redes sociais:

Compartilhar este artigo