O PORTE IMPOSSÍVEL , O MILAGRE DE INDIANA JONES AND THE INFERNAL MACHINE NO N64
(PARTE 2)
Pode-se dizer que o desenvolvedor Core Design simplesmente transformou os filmes de Indiana Jones em um jogo e substituiu Harrison Ford por Lara Croft quando criou Tomb Raider.Ironicamente, também se poderia argumentar que no ano passado a LucasArts retribuiu o favor ao lançar o
Indiana Jones e a Infernal Machine para PC oficialmente licenciados - um jogo que lembrava tanto a aparência de Tomb Raider que era inegável. Infelizmente para os jogadores de PC, embora o produto fornecesse um enredo forte e mundos habilmente projetados e repletos de quebra-cabeças dignos do nome do Dr. Jones, ele também sofria consideravelmente com as mesmas deficiências do de Croft; em particular, um sistema de controle terrivelmente desorganizado e uma boa quantidade de código cheio de bugs para inicializar.
"Aproxime-se do presente. LucasArts se juntou ao desenvolvedor Factor 5 para trazer The Infernal Machine para os proprietários de Nintendo 64 - só que desta vez sem as falhas inerentes à versão para PC. Para seu crédito, a empresa foi amplamente bem-sucedida. Indy 64 não sacrifica nada da versão para PC, exceto por muitas de suas frustrações. Parece tão bom, senão melhor, e graças a um esquema de controle totalmente redesenhado, parece como deveria para começar - mais intuitivo, mais estreito, mais rápido e totalmente mais equilibrado. Todos os quebra-cabeças e design de nível superior do título para PC, entretanto, permanecem perfeitamente intactos."
Jogabilidade
Você jogou Tomb Raider. Imagine que Lara Croft não fosse tão voluptuosa. Agora imagine que ela usasse um chapéu e carregasse um chicote. Bem-vindo a Indiana Jones e a Máquina Infernal. O design por trás do jogo não é original, mas traz alguns novos elementos para o gênero de ação e aventura repleto de quebra-cabeças e há variedade suficiente para manter os jogadores felizes por um longo tempo.
Indy viaja por mais de 17 níveis diferentes resolvendo quebra-cabeças, eliminando inimigos e coletando artefatos inestimáveis. Ele pode usar uma variedade de armas e dispositivos - tudo, desde uma arma padrão e facão a uma espingarda, mais leve e, sim, até mágica. Ao longo do caminho, nosso herói também terá que descer rios de barco em uma jangada, atravessar desertos em um jipe, pular, escalar, nadar, rastejar, chicotear, balançar e deslizar até a vitória. A seleção é louvável. Na versão para PC do jogo, tarefas simples, como usar armas, eram uma tarefa árdua, pois tudo estava confinado a diferentes teclas. Para o "porte" N64, a LucasArts e a Factor 5 tomaram conhecimento de
The Legend of Zelda: Ocarina of Timeesquema de item do botão C de e copiei-o. Não há nenhuma vergonha, realmente - ele arrasou e funciona tão brilhantemente no mundo de Indy. Utilizando-o, selecionar um item é tão simples quanto apertar um dos três botões C. Por exemplo: C-esquerdo puxa o chicote do Dr. Jones enquanto C-direito tira sua arma e C-desce o isqueiro. Enquanto isso, C-up é usado para um modo de visualização livre no qual os jogadores podem simplesmente olhar ao redor em seu ambiente - útil quando um está preso.
Outra grande inovação em relação ao esquema de controle da versão para PC é a inclusão de um recurso adicional que se tornou popular com o título Zelda de Miyamoto: o z-trigger lock-on. Quando a arma de Indy é sacada, os jogadores podem travar em um inimigo com o botão R, momento em que Dr. Jones pode simplesmente bombardear seu inimigo e continuar a atirar com um ângulo de câmera fixo. Funciona esplendidamente - assim como funcionou para Link em suas batalhas. É uma adição aparentemente simples que, na verdade, ajuda muito a tornar a sensação da aventura mais intuitiva, dando ao jogador mais confiança em sua habilidade.
Mas nem tudo está bem na nova aventura de Indiana. Certas deficiências da versão para PC ainda são evidentes no N64. O controle, embora melhorado muito, ainda é estranho. Indy é como Lara Croft em seus movimentos - lento. Ele não é um acrobata capaz de pular de uma saliência em outra, deslizando em encostas e mergulhando com perfeita precisão através de uma janela em um abismo. Em vez disso, ele deve ser virado, cuidadosamente posicionado e, então, ter permissão para ir em frente, mas mesmo assim não há garantia de que os jogadores irão derrotar com sucesso qualquer objetivo de manipulação que eles esperavam. Como Tomb Raider, um certo grau de paciência é necessário para jogar com Indy, e se você nunca gostou dos movimentos de Lara, também não vai gostar dos do Dr. Jones. Além disso, existem problemas ocasionais com a detecção de colisão. Indiana ricocheteou em uma saliência que tínhamos a intenção de que ele agarrasse antes e, da mesma forma, ele foi pego em uma pedra durante o rafting ou preso em uma parede durante a exploração, não nos deixando escolha a não ser reiniciar. Esses exemplos são raros, mas dignos de nota.
Os layouts dos níveis são quase idênticos aos encontrados na versão para PC; mundos enormes e temáticos com quebra-cabeças enormes e extensos que desencadeiam novos quebra-cabeças, que por sua vez desbloqueiam novos quebra-cabeças. Indy deve lutar contra tigres, atropelar hienas com seu jipe, evitar pedras que estouram jangadas nas corredeiras, pular lava fervente, quebrar paredes com magia, atirar em soldados russos mortos, andar em carrinhos de minas e evitar ser envenenado por répteis e insetos nojentos. Ele deve viajar do topo de montanhas nevadas a desertos empoeirados, através de pirâmides subterrâneas, em florestas e em abismos escuros e subaquáticos que parecem continuar indo e vindo. Os jogadores não ficarão absolutamente entediados com a complexidade ou variedade que o jogo apresenta, e isso ajuda muito a aumentar o valor do replay. Outro reforço de replay, talvez mais importante, vem na forma do tesouro que Indy coleta.
Artefatos inestimáveis estão escondidos em todos os níveis do jogo e conforme o Dr. J os coleta, seu QI sobe. Depois que ele atinge um certo QI, um segredo muito, muito impressionante é desvendado. É definitivamente algo para o jogador mestre almejar e a boa notícia é que os jogadores podem voltar aos níveis já vencidos a qualquer momento para procurar e salvar tesouros.
Gráficos
Indiana Jones e a Máquina Infernal é um dos títulos mais bonitos que já enfeitaram um cartucho do Nintendo 64. LucasArts e Factor 5 na verdade melhoraram o visual de muitas maneiras em relação ao original para PC. Pense em mundos gigantescos e intrincadamente detalhados com trabalho de textura nítida e magnificamente ambiente que o fará se perguntar se é realmente um produto N64 e efeitos de iluminação que são tão impressionantes. Adicione um sistema de efeitos de partículas energéticos - algo que faltava no jogo para PC - que permite que pedras caiam das texturas conforme Indy sobe, ou chamas que lançam faíscas quando se dobram com o vento. Junte tudo com uma enorme arquitetura 3D e uma incrível quantidade de variação de nível para nível. Agora, para o kicker - tudo é executado no modo de alta resolução de 640x480, já que os jogadores possuem um pacote de expansão de 4 MB.
Na verdade, as únicas desvantagens reais para os gráficos são o sistema de animação e, ocasionalmente, a taxa de quadros. Indy anda, rasteja e sobe como se tivesse algo incrivelmente doloroso acampado em sua traseira - assim como na versão para PC. É o único aspecto do esforço de 64 bits que gostaríamos que tivesse sido abordado. A taxa de quadros, por sua vez, pode cair em grandes ambientes externos com vários inimigos na tela ao mesmo tempo, mas como a aventura é frequentemente confinada a áreas internas e não é configurada de uma forma que convoque dezenas de inimigos ao mesmo tempo, é raro que o a fluidez diminui para um grau perceptível.
As diferenças gráficas entre o N64 e o PC são muito menos dramáticas do que você pode imaginar. Capturamos nosso Indiana Jones e a Infernal Time Machine (PC) em um PIII de 600 MHz com um Riva TNT2 Ultra. Para ser justo, rodamos o PC com resolução de 640x480, já que a versão N64 funciona com a mesma resolução. A principal diferença que você verá imediatamente é a profundidade da cor nas texturas. O N64 é famoso por fazer cores muito suaves às vezes, se não forem o vermelho, o azul ou o amarelo primários. Assim, os desfiladeiros castanho-avermelhados acabaram por ser muito mais castanhos. Quando você realmente joga o jogo não é perceptível no N64 porque você não tem nada com que se comparar, mas sentimos a necessidade de mencionar isso porque as imagens contrastam mais nesta área. Além disso, sentimos que as texturas do N64 são absolutamente incríveis e chegam bem perto das usadas na versão para PC. Na verdade, o uso de texturas de Indy no N64 é um dos melhores que já vimos. Não necessariamente em termos de design de textura, mas certamente em termos de nitidez. Isso pode ser visto nas fotos.
Abaixo apresentamos algumas fotos para sua própria comparação
Uma viagem aos mistérios do N64 RCP
O microcódigo gráfico da obra-prima por trás da versão para Nintendo 64 de Indiana Jones e a Máquina Infernal e Star Wars Episódio I: Batalha por Naboo
Introdução
A Factor 5 costumava ser um dos melhores estúdios de desenvolvimento de jogos no final dos anos 90 / início dos anos 2000. Seus programadores, vindos do cenário de hackers e demos alemães, eram muito talentosos e, graças a uma colaboração com a Nintendo e a LucasArts, foram capazes de fornecer impressionantes conquistas gráficas no N64 e no GameCube.
Após o sucesso de Star Wars: Rogue Squadron em 1998, Factor 5 começou a trabalhar dois novos jogos, Indiana Jones and the Infernal Machine e Star Wars Episódio I: Battle para Naboo, com a intenção de apertar o Nintendo 64 ao seu melhor. Para isso, a Factor 5 decidiu desenvolver um “novo” microcódigo gráfico (e otimizar seu microcódigo de áudio chamado Musyx).
No final da vida comercial do N64, ambos os jogos foram lançados, tarde demais para atrair o favor da crítica e de um público já focado na próxima geração de consoles, o que significa que as conquistas técnicas injetadas nesses jogos foram infelizmente despercebido.
GlideN64, como seu predecessor Glide64, foi desenvolvido principalmente como um plugin de emulação de alto nível (HLE). Um microcódigo é uma biblioteca de comandos macro de alto nível (alto nível em comparação com os códigos operacionais do processador). A maneira LLE é executar esses comandos como o hardware real faria, instrução por instrução. O HLE implementa o que os comandos dessa biblioteca executam o mais rápido possível, sem executar o código do comando real.
Conforme explicado por Sergey em seu blog há alguns anos poucos jogos não puderam ser emulados graficamente no HLE como a documentação necessária para fazer isso estava indisponível. Ainda assim, alguns anos atrás, Sergey e eu começamos a fazer engenharia reversa e implementar microcódigos gráficos alfandegários.
Quando começamos nossa jornada para decifrar aquele usado por Indiana Jones e a Máquina Infernal e Star Wars Episódio I: Batalha por Naboo, ficamos impressionados com o quão bem escrito e otimizado ele foi e embora não possamos entender sua complexidade em detalhes, acreditamos que suas proezas merecem ser documentadas para a posteridade.
Observe que para entender a documentação abaixo, você deve estar familiarizado com a programação gráfica (OpenGL), hardware N64 e o microcódigo Fast3D. (
Ao contrário do que poderia ser sugerido pelo Factor5, o microcódigo gráfico de Indiana Jones e Battle de Naboo era
NÃO desenvolvido do zero. Ele foi obviamente desenvolvido com o código-fonte do microcódigo F3DEX fornecido pela Nintendo em seu SDK, que é apenas uma versão otimizada do microcódigo Fast3D usado por Super Mario 64. É claro que a maioria dos comandos gráficos foram reescritos junto com muitas adições importantes ( o tamanho do microcódigo é cerca de duas vezes maior que os outros), mas seu núcleo é bastante semelhante ao do primeiro jogo do console.
O que resta principalmente é a maneira de transformar os vértices de entrada em uma estrutura de dados de saída específica armazenada em um buffer dentro da Memória de Dados (DMEM) do RSP (Processador de Sinal de Realidade). Essas estruturas podem ser selecionadas por um comando de triângulo, formatadas em um comando de triângulo de baixo nível e então usadas pelo Reality Display Processor (RDP). O código usado a este respeito é comparável ao código usado no microcódigo F3DEX onde não há correspondência com o código de outros tipos de microcódigo (Turbo3D, ZSort) para fazer tal operação.
Outra evidência a este respeito é que o cabeçalho do comando (ou seja, 0xBC para o comando MoveWord, 0xBF para o comando de triângulo TRI1, etc.) são iguais ao microcódigo F3DEX.
Como uma consequência interessante, isso significa que, na verdade, nenhum dos microcódigos N64 foi escrito do zero por desenvolvedores terceirizados, mas apenas pela SGI ou pela Nintendo. No entanto, é verdade que apenas cerca de 20% do código está de alguma forma relacionado ao F3DEX, o que significa que este último foi usado como um ambiente viável para desenvolver os novos comandos repletos de recursos exclusivos.
I / Poucos recursos pendentes em comparação com o microcódigo F3DEX
A. O endereço DMEM é integrado diretamente ao comando gráfico
DMEM é uma pequena memória de 4kb que o microcódigo RSP usa para armazenar os dados recuperados da RDRAM. Os dados são usados pelo RSP para fazer os cálculos de acordo com a especificação de um comando.
No microcódigo F3DEX, o endereço DMEM não faz parte do comando em si, mas é um índice. O endereço DMEM real usado por este índice é armazenado no próprio DMEM na inicialização do microcódigo, oculto para os usuários finais. Neste microcódigo Indy / Naboo, o endereço DMEM é definido diretamente no comando. Este recurso exclusivo ajuda a economizar espaço no DMEM para outras finalidades.
Vamos dar um exemplo simples: o
comando 0xBC é um comando MoveWord, que simplesmente armazena palavras de 32 bits no DMEM. Como você deve estar ciente, as palavras movidas serão usadas posteriormente por outros comandos como parâmetros.
0xBC00014C
0x00000715
0xBC é o cabeçalho do comando, 0x14C é o endereço DMEM e 0x00000715 é a palavra armazenada neste endereço. Para comparação, em F3DEX:
0xBC000406
0x002D4CD0
0x06 é um mero sinalizador que é usado pelo microcódigo para localizar no DMEM um endereço DMEM base. Esse sinalizador pode variar dependendo do tipo de palavra a ser armazenada (ou seja, um endereço RDRAM de segmento). 0x0004 é adicionado a este endereço DMEM básico. Em nosso exemplo, o endereço DMEM básico é 0x160 + 0x004 = 0x164. Portanto, a palavra 0x002D4CD0 será armazenada no endereço DMEM 0x164.
B. O modo de geometria é um mero registro RSP
No microcódigo F3DEX, o modo Geometria é armazenado no DMEM e cada vez que ele precisa ser verificado ou alterado, ele deve ser carregado em um registro RSP, alterado e depois armazenado de volta. No microcódigo Indy / Naboo, há simplesmente um registro RSP inteiro dedicado ao modo de geometria. Isso significa que você tem um registro a menos, mas é uma maneira fácil de gerenciar o modo de geometria e também economizar um pouco de espaço no DMEM.
C. Brincando com listas de exibição
No microcódigo Indy / Naboo, a forma como as listas de exibição são gerenciadas é relativamente diferente do F3DEX.
- Execução de várias listas de exibição no mesmo nível hierárquico
No F3DEX original, as listas de exibição são relativamente diretas, de forma que são, como no OpenGL, gerenciadas hierarquicamente. Primeiro, você chama uma nova lista de exibição e, em seguida, uma lista de exibição aninhada, que também pode chamar uma lista de exibição aninhada.
Quanto a Star Wars: Rogue Squadron, um mecanismo inteligente foi desenvolvido para “pular” de uma lista de exibição para outra lista de exibição. No início de cada lista de exibição, em vez de ter o primeiro comando imediato a ser executado, você simplesmente tem um endereço RDRAM que pode ser chamado no final da lista de exibição pelo comando imediato 0xB5. Nesse caso, uma lista de exibição será recuperada do endereço RDRAM especificado. Esta lista de exibição carregada também contém um endereço RDRAM em seu início. Portanto, em vez de aninhar as listas de exibição, você passa de uma lista de exibição para outra no mesmo nível de hierarquia.
- Execução de uma lista de exibição sob condição
Esse mecanismo é incrível. O comando MoveWord (0xBC00058C) pode fornecer um endereço RDRAM. Ao executar alguns comandos imediatos que podem levar ao desenho de alguns gráficos (retângulos texturizados, triângulos), ANTES de serem realmente desenhados, uma lista de exibição aninhada é recuperada e executada a partir de tal endereço RDRAM. É o caso do comando RDP imediato 0xE4 / 0xE5, para triângulos não rejeitados, para partículas. Tal mecanismo vincula o desenho real de uma primitiva RDP a uma lista de exibição que define os parâmetros de tal desenho (ou seja, modo de combinação, outros modos, imagem de textura, bloco, etc.). E tal mecanismo ocorre SOMENTE quando o primitivo está para ser desenhado. Portanto, por exemplo, se um triângulo estiver fora da janela de visualização e, portanto, rejeitado, esta lista de exibição para a configuração do pipeline de pixel não será executada. Desta forma, o N64 RDP é usado apenas quando necessário!
D. Segmentação de memória inteligente
No F3DEX, o código gerencia a segmentação da memória através do uso do comando MoveWord. Com este método, o número de segmentos é limitado a 16 e requer o armazenamento das palavras no DMEM. No microcódigo Indy / Naboo, a segmentação da memória é gerenciada de forma diferente e de alguma forma como o mecanismo de “salto”, já explicado para a lista de exibição. No primeiro comando imediato 0x02 fornece um endereço RDRAM. Este é o endereço RDRAM do primeiro segmento. A primeira palavra neste endereço RDRAM é o endereço RDRAM do segmento seguinte. O tamanho de cada segmento é limitado a 0x100 bytes e quando um comando imediato solicita dados além do segmento, os dados restantes são recuperados do segmento seguinte, onde novamente a primeira palavra fornece o endereço RDRAM do segmento seguinte.
E. Estrutura de comando intrincada
No F3DEX, o tamanho do comando é fixado em duas meras palavras de 32 bits com a mesma finalidade exata. Em Indy / Naboo, o tamanho de um comando pode ser muito maior. Por exemplo, o maior comando imediato do microcódigo, que é usado para gerar os polígonos do terreno a partir de um mapa de altura, é composto por 16 palavras de 32 bits !!!!
0x05000000
0x217A800F
0x045ED4E3
0x00000000
0x000001E4
0xD642FE9B
0x00000000
0x00000000
0x00000000
0x00000000
0xFF000000
0xFF000000
0x00000000
0x00000000
0x00000000
0xEF5B0017
O mesmo comando imediato pode ter seu tamanho variando de acordo com uma bandeira dentro de tal comando. Por exemplo, o comando TRI 0xB4 para polígonos texturizados é maior do que para polígonos sombreados
.
TEXTURED TRIANGLES
0xB400
06 00
0x06000628
0x0C000408
0x06500678
0x07DD062C
0x07DD062C
0x0787062C
0x07DD062C
SHADED TRIANGLES
0xB400
04 00
0x06000628
0x0C000408
0x06500678
A bandeira do comando também pode alterar seu comportamento. Por exemplo, o comando TRI 0xB4 com sinalizador 0x06 é usado para triângulos texturizados com texturas regulares, mas o sinalizador 0x0E ativa a geração de coordenadas de textura para texturas reflexivas.
0xB400
0E 00
0x099809C0
0xACA0A4A8
0x09700948
0x7F0000B8
0x7F0000C0
0x7F0000B0
0x7F0000A8
Às vezes, o mesmo comando pode ter uma finalidade completamente diferente. Por exemplo, o comando 0x05 pode ser usado para gerar retângulos de textura, gerar partículas, gerar terreno a partir de um mapa de altura, gerar vértices específicos. Exceto para gerar gráficos, não há nada em comum entre esses comandos imediatos, na verdade.
II / Lista dos comandos com explicação de alto nível
Mesmo se pudéssemos decifrar o microcódigo, isso não significa que todos os parâmetros desses comandos foram totalmente apreendidos. Alguns, é claro, são bastante óbvios, mas alguns são usados em comandos muito grandes e complexos e, portanto, confusos.
Comando 0x01
O principal objetivo desse comando imediato é recuperar dados da RDRAM e, potencialmente, usar esses dados para computar novos dados.
A estrutura do comando é a seguinte:
0x01ODDDLL
0xBBAAAAAA
0x01 Cabeçalho do comando
O Opção do comando: para o mesmo DDD, a opção pode levar a outra parte do código
DDD Endereço DMEM onde os dados serão armazenados. TAMBÉM o código irá verificar e dependendo disso, irá rotear o código para uma porção específica do código, que irá então rotear novamente por O.
LL número de bytes a serem recuperados da memória
BB é um mero byte que pode ser usado de acordo para a rota que o comando tomará após ter recuperado os dados (ou seja, para o número de luzes)
AAAAAA Quando diferente de zero, os dados são recuperados desta memória RDRAM, quando há apenas 0x000000, os dados são recuperados de um segmento.
Portanto, o mesmo comando 0x01 pode ser usado para vários cenários, como:
Quando O é 0, o comando é como o comando F3DEX MoveMem, o que significa que ele simplesmente recupera dados de RDRAM e os armazena em DMEM.
Quando O é 1, o comando é como o comando F3DEX VTX, o que significa que os vértices são recuperados da RDRAM para o DMEM, transformados e armazenados em um buffer.
Quando O é 2, cálculos de iluminação são realizados. O comando recupera dados de RDRAM e calcula cores para vértices. As cores são armazenadas em um buffer de onde os comandos de triângulo as recuperam posteriormente. O sistema de iluminação é muito complexo, com muitas opções.
Quando O é 3, o comando define o número de luz e potencialmente recupera a estrutura de luz.
Quando O for 5, o comando recupera os vértices da RDRAM de forma específica para o DMEM, transforma-os e armazena-os em um buffer. Essa opção diz respeito a gráficos 2D onde triângulos são usados.
Comando 0x02
Ele define o endereço RDRAM do primeiro segmento utilizável pelo comando 0x01. Como já explicado, o endereço RDRAM do próximo segmento é a 1ª palavra do endereço RDRAM do segmento anterior.
Comando 0x05
Este comando gera primitivas de várias maneiras (de um mero retângulo de textura a partículas a triângulos usados para campo, etc.). O último byte da segunda palavra determina o modo do comando.
0x18 (2 palavras)
0x05XXXXXX
0xXXXXXX18
Este subcomando transforma os vértices selecionados pela matriz Modelview (0x010E403F) e os armazena em um buffer de vértice.
0x27 (6 palavras)
0x05XXXXXX
0xXXXXXX27
O subcomando gera vértices e alguns sinalizadores usados por outro subcomando 0x05.
0x24 (10 palavras)
0x05XXXXXX
0xXXXXXX24
O subcomando gera partículas (na verdade, pequenos retângulos de textura) a partir dos vértices / sinalizadores obtidos pelo subcomando 0x05 anterior.
0x15 (8 palavras)
0x05XXXXXX
0xXXXXXX15
O subcomando gera um mero retângulo de textura usando um vértice como centro de tal retângulo. É usado principalmente para explosões.
0x4F (2 palavras)
0x05XXXXXX
0xXXXXXX4F
Esse subcomando é uma mera sinalização usada pelo subcomando 0x0F para alterná-lo entre sua versão curta (4 palavras e a versão longa (16 palavras)
0x0F (4 ou 16 palavras)
0x05XXXXXX
0xXXXXXX0F
Tal sub -comando é usado para definir parâmetros para o subcomando 0x09 e 0x0C. Há uma versão curta e outra longa, ativada pelo subcomando acima.
0x09 e 0x0C (6 palavras)
0x05XXXXXX
0xXXXXXX0C
0x05XXXXXX
0xXXXXXX09
Ambos os subcomandos geram os triângulos para o solo no Episódio I de Star Wars: Batalha por Naboo (até 32 por subcomandos). Parece ser gerado a partir de um mapa de altura colorido.
Como você entende, o comando 0x05 é um conjunto de 8 subcomandos!
Comando 0x06
Este comando é igual ao comando gSPDisplayList em F3DEX.
Comando 0x07
Este comando é igual ao comando gSPBranchList em F3DEX.
Comando 0xB4 (4 ou 8 palavras)
É semelhante ao comando TRI2 em F3DEX, exceto que as coordenadas e índices de textura no buffer de cores fornecidos como parâmetros do comando.
Comando 0xB5
Este comando dispara um “salto” para outra lista de exibição previamente definida como a primeira palavra da lista de exibição atual.
Comando 0xB6
Este comando é igual ao comando gSPClearCeometryMode em F3DEX.
Comando 0xB7
Este comando é igual ao comando gsSPSetGeometryMode em F3DEX.
Comando 0xB8
Este comando termina uma lista de exibição.
Comando 0xB9
Este comando é semelhante ao comando gSPSetOtherMode em F3DEX (metade inferior)
Comando 0xBA
Este comando é semelhante ao comando gSPSetOtherMode em F3DEX (metade superior)
Comando 0xBB
Este comando é semelhante ao comando gSPTexture em F3DEX.
Comando 0xBC
Este comando é semelhante ao comando Moveword em F3DEX.
Comando 0xBD
Usado apenas na Batalha de Naboo. Ele define os OtherModes para os triângulos usados pelos comandos que geram o solo.
Comando 0xBE
Usado apenas na Batalha de Naboo. Ele define os OtherModes (junto com o comando imediato 0xBD) e as coordenadas de textura para cada triângulo que gera o solo. Em conjunto com os parâmetros definidos pelos subcomandos 0x05 -0x09 e 0x0C, ele também pode gerar esses triângulos (até 32 deles).
Comando 0xBF (4 ou 8 palavras)
É semelhante ao comando TRI1 em F3DEX, exceto que as coordenadas e índices de textura no buffer de cores fornecidos como parâmetros do comando.
Conclusão:
Com um microcódigo tão avançado, é claro que poucos jogos N64 podem competir graficamente com Indiana Jones e Star Wars Episódio I: Batalha por Naboo.
Como as imagens falam mais alto do que as palavras, aqui estão alguns exemplos impressionantes do excelente exploit gráfico.
A iluminação é absolutamente esplêndida em Indiana Jones e na Máquina Infernal.
Por exemplo, no início do nível chamado Vulcão, 12 fontes de luzes são usadas ao mesmo tempo !!
Em outro nível chamado Templo de Palawan, luzes pontuais esplêndidas são exibidas.
As partículas são usadas em muitos lugares sem qualquer desaceleração em Indiana Jones e na Máquina Infernal e no Episódio I de Guerra nas Estrelas: Batalha por Naboo. Um exemplo, entre muitos, seria a neve.
O terreno no Episódio I de Star Wars: Batalha por Naboo é enorme e sem neblina.
Alguns efeitos de grandes explosões são frequentemente mostrados no Episódio I de Star Wars: Batalha por Naboo.
Efeitos esplêndidos de mapeamento de reflexão às vezes são usados.
Como você pode ver, os dois jogos são simplesmente incríveis para um Nintendo 64. Tendo em mente que os jogos também usam o microcódigo de áudio Musyx, o console provavelmente mostrou com eles o melhor que pode oferecer. Também prova que programadores qualificados podem superar as limitações de uma máquina muito além das expectativas !!!
Veredito
Indiana Jones e a Máquina Infernal é o Tomb Raider que os proprietários do Nintendo 64 nunca tiveram. É uma aventura de ação e quebra-cabeça complexa, às vezes absolutamente difícil, com belos visuais e um enredo divertido. Felizmente, o título também foi muito melhorado em relação ao seu predecessor para PC. LucasArts e Factor 5 retrabalharam muito o esquema de controle para que ele seja muito mais intuitivo e adequado para jogos de console. Além disso, os visuais foram aprimorados de forma semelhante para permitir uma melhor iluminação e efeitos de partículas, sem mencionar um grau espetacular de detalhes de textura para um carrinho de 64 bits