sexta-feira, 23 de julho de 2010

Inside - N64 - Parte 3

Posted by | julho 23, 2010

Olá, embora um pouco atrasado em relação ao tempo entre as duas ultimas colunas, mas estou aqui, e conforme prometido, irei falar sobre o RCP e os problemas de programação no N64.//

3- O RCP, a linguagem e as dificuldades.

O N64 possuía um outro grande diferencial em relação aos concorrentes, ele possuía um Co-processador o RCP (Reality Co-Processor) que diferente do caso do Saturn, o RCP funcionava bem, foi manufaturado pela Silicon Graphics e era capaz de processar vetores, fazer anti-aliasing (Efeito que reduz o pixeamento e o efeito serrilhado dos gráficos) em tempo real, consegue manter o framerate alto mesmo com gráficos complexos, possui um excelente mapeador de texturas (Responsável por aplicar as texturas armazenadas no cartucho nos gráficos 3D), e conseguia dar a sensação de profundidade nos gráficos em tempo real.

O que tudo isso quer dizer?

Você leitor, se lembra da ultima vez que o seu N64(não considerando emuladores) te deixou na mão? Lembra da ultima vez em que o seu gráfico foi gerado sem texturas e as texturas foram aparecendo depois? (Eu lembro da ultima vez que o meu PS2 fez isso com as texturas, no jogo Bully por exemplo, é super comum).

Não se lembra? Você deve isso ao RCP, o grandioso e maldito co-processador do N64, que com todo o seu poder, era um dos maiores méritos e problemas do console; embora fosse poderoso, o RCP acabava reduzindo a memória para carregamento de texturas para apenas 2kb, que no fim forçava os produtores de jogos a reduzir a qualidade das texturas para que elas pudessem ser carregadas; na prática isso prejudicou muito os estúdios menores, menos experientes e até mesmo aqueles que possuíam menos contato com a Nintendo, forçando-os a lançar jogos com texturas simples, enquanto pouquíssimos estúdios, por exemplo a Rare e a própria Nintendo, puderam usar uma técnica de sobreposição de texturas para melhorar os gráficos do jogo, (fato permitido apenas pelo fato de o console utilizar cartuchos, visto que o tempo de carregamento de um cd daria o "efeito Bully" nesses jogos), esse truque foi utilizado por jogos como Perfect Dark, Banjo-Tooie e Conker's Bad Fur Day.

Haviam problemas com falta de padrão no gerenciamento da resolução de tela, e muitas vezes as empresas tiveram problemas com o gerenciamento da RAM no console, como programador, eu digo que programar para uma plataforma sem Garbage Collector(sistema que retira da RAM os dados que não terão mais utilidade no código fonte) é realmente uma tarefa extremamente detestável, recomendo que qualquer leitor conheça programação tente programar algo num MSX ou computador semelhante, sem ficar controlando o uso da RAM.

Acima de tudo o código fonte dos jogos do N64 era escrito em linguagem C (Isso permitiu a criação de um dos primeiros emuladores do N64, que era basicamente um interpretador de linguagem C com as bibliotecas (arquivos específicos) para cada jogo); a linguagem permitia que a maioria das outras dificuldades de programação fossem contornadas com o próprio código, utilizando extensões da linguagem C em bibliotecas extras, incluídas no cartucho, até mesmo para gerenciar melhor a RAM.

Em resumo, o N64 é um Hardware tão complexo quanto poderoso, que quando bem utilizado, era capaz de gerar maravilhas, porém quando mal usado gerava jogos toscos e de aparência bizarra. O RCP era um processador fantástico, mas até hoje muito pouco do funcionamento dele é conhecido, deve ter até um pouco de magia negra nele.//

Foto do RCP:



Bem por hoje é só, na próxima edição, ao invés de continuar narrando aspectos do Hardware, eu irei postar o primeiro projeto da coluna, próxima quinta(29/07/10), Como Transformar o RF Switch ou cabo genérico em um Adaptador AV.//

---

Siga-nos em nossas outras redes sociais:

https://pt-br.facebook.com/n64brasil/https://goo.gl/rqRuvKhttps://www.instagram.com/n64brasil/

Compartilhar este artigo
Google ( 4 )

© 2009-22 N64 Brasil | Template: Yanku-template