O que há de Novo?
Fórum Outer Space - O maior fórum de games do Brasil

Registre uma conta gratuita hoje para se tornar um membro! Uma vez conectado, você poderá participar neste site adicionando seus próprios tópicos e postagens, além de se conectar com outros membros por meio de sua própria caixa de entrada privada!

  • Anunciando os planos GOLD no Fórum Outer Space
    Visitante, agora você pode ajudar o Fórum Outer Space e receber alguns recursos exclusivos, incluindo navegação sem anúncios e dois temas exclusivos. Veja os detalhes aqui.


Os jogos mais avançados do Nintendo 64 [+Doom 1 e 2 do PC no Ultra 64][+DINOSAUR PLANET vazou página 42]

Carolíngio

Bam-bam-bam
Mensagens
3.696
Reações
14.285
Pontos
303
apaga ai e posta aqui

vlw man, postei lá.
 

Retroviews

Ei mãe, 500 pontos!
Mensagens
1.711
Reações
4.226
Pontos
704
Desenterraram um trailer perdido de Mother 3 do Nintendo 64, exibido na Spaceworld de 1997. Infelizmente sem som.




Curioso como não é muito diferente da versão de GBA. Os personagens e cenários são fáceis de se reconhecer. Na torcida para esse jogo ter a mesma sorte do Dinosaur Planet e aparecer algum dia, mesmo sabendo que não chegaram a terminar.
 

Gustavo Reis

Bam-bam-bam
Mensagens
1.262
Reações
2.377
Pontos
453
Desenterraram um trailer perdido de Mother 3 do Nintendo 64, exibido na Spaceworld de 1997. Infelizmente sem som.




Curioso como não é muito diferente da versão de GBA. Os personagens e cenários são fáceis de se reconhecer. Na torcida para esse jogo ter a mesma sorte do Dinosaur Planet e aparecer algum dia, mesmo sabendo que não chegaram a terminar.

Esse com certeza tem sido um dos mais esperados pela comunidade pra vazar, sempre vejo citação dele
 

sux

soteropolitano
Mensagens
15.277
Reações
27.574
Pontos
1.553
vPYUhrW.jpg
que raiva dessa fase maldita, pqp
 

Fabio Alexandre

Bam-bam-bam
Mensagens
1.299
Reações
2.142
Pontos
453
California Speed merecia uma versão no Dreamcast, que conseguiria fazer um Arcade Perfect.
Mas a versão N64 não ficou ruim, achei aceitável, conseguiram colocar todo o conteúdo no cartucho.
.
Não removeram nenhuma pista, considerando que o cartuchinho não deve ter nem 1/10 do espaço da versão Arcade.
Só deveriam ter colocado a opção de usar o Expansion Pack, pra aumentar a Resolução e o Draw Distance.
 


Gustavo Reis

Bam-bam-bam
Mensagens
1.262
Reações
2.377
Pontos
453
California Speed merecia uma versão no Dreamcast, que conseguiria fazer um Arcade Perfect.
Mas a versão N64 não ficou ruim, achei aceitável, conseguiram colocar todo o conteúdo no cartucho.
.
Não removeram nenhuma pista, considerando que o cartuchinho não deve ter nem 1/10 do espaço da versão Arcade.
Só deveriam ter colocado a opção de usar o Expansion Pack, pra aumentar a Resolução e o Draw Distance.
O jogo em si foi um bom port, apesar das censuras bestas que a Nintendo colocava, a parte do shopping por exemplo, não tem as pessoas pra atropelar kk
 

Jefferson Praxedes

Bam-bam-bam
Mensagens
2.051
Reações
7.547
Pontos
453
O PORTE IMPOSSÍVEL , O MILAGRE DE INDIANA JONES AND THE INFERNAL MACHINE NO N64
(PARTE 2)


203914



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


203922



Uma viagem aos mistérios do N64 RCP


203923

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 eraNÃ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.
  1. 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.
  1. 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 !!

53646122-b3927380-3c3a-11e9-9753-076891265654.png


Em outro nível chamado Templo de Palawan, luzes pontuais esplêndidas são exibidas.

53646188-dae94080-3c3a-11e9-817e-b3b7200c789a.png


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.

53647839-aa0b0a80-3c3e-11e9-86af-93e52ca222df.png

53647249-6b288500-3c3d-11e9-8267-49f93c491f1e.png


O terreno no Episódio I de Star Wars: Batalha por Naboo é enorme e sem neblina.

53647974-fe15ef00-3c3e-11e9-82d8-6138d38fa948.png


Alguns efeitos de grandes explosões são frequentemente mostrados no Episódio I de Star Wars: Batalha por Naboo.

53647747-79c36c00-3c3e-11e9-9fbb-546b15724390.png


Efeitos esplêndidos de mapeamento de reflexão às vezes são usados.

53648174-885e5300-3c3f-11e9-9a04-faa0dab14e56.png


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

203926
 
Ultima Edição:

Jefferson Praxedes

Bam-bam-bam
Mensagens
2.051
Reações
7.547
Pontos
453

Falkner

Ei mãe, 500 pontos!
Mensagens
7.634
Reações
10.622
Pontos
753

*ka

Mil pontos, LOL!
Mensagens
11.780
Reações
11.470
Pontos
1.344
Minha TV tem componente, mas vc usa em uma de tubo né?
Consegue testar em uma full hd ou coisa do tipo?
Para ficar bom em tv moderna fullhd ou com resolução mais alta, creio que seja necessário um upscaler bom, pois nesse caso do rgb a resolução continuará baixa, mas deve ficar menos pior que no composto.
 

Falkner

Ei mãe, 500 pontos!
Mensagens
7.634
Reações
10.622
Pontos
753
Para ficar bom em tv moderna fullhd ou com resolução mais alta, creio que seja necessário um upscaler bom, pois nesse caso do rgb a resolução continuará baixa, mas deve ficar menos pior que no composto.

estava fazendo as contas aqui e ia ficar na faixa dos R$ 800,00 um gbs control(ou ossc)+cabo scart+mod rgb :kcaro:kcaro
 

Jefferson Praxedes

Bam-bam-bam
Mensagens
2.051
Reações
7.547
Pontos
453
As TVs mais modernas vai ter um trabalho para lidar com resoluções de 480i para baixo , fica tudo estivado, mesmo em componente vai ficar bem lavada a imagem . Como o @*ka falou melhor caminho é um OSSC , podes pegar do Aliexpress mesmo ! A hora que a minha de tubo de pau eu vou pegar um também !
 

Sega&AMD

Ei mãe, 500 pontos!
Mensagens
13.708
Reações
13.742
Pontos
803
Pode ser que alguém aqui não conheça. Esse é SM64 versão nativa do PS2, um port feito por um fã e está sendo comparado com a versão N64, impressionante, claro é de se imaginar que o ps2 possa fazer bem mais o grande ponto aqui é que o jogo foi codificado por um homebrew e está de parabéns, o cpu do ps2 EE tem um parentesco com o cpu do N64 portanto era natural que alguém conseguisse o port. No mais Mario 64 ainda é um ótimo jogo.

 
Ultima Edição:

Warrior Of Light

Bam-bam-bam
Mensagens
1.213
Reações
4.520
Pontos
453
Editado pq postei no tópico errado :brbr

vlw man, postei lá.
Tenho que fazer 2 reviews de jogos do Game Cube que já selecionei, Bloody Roar e TimeSplitters 3. Os outros que o pessoal comentou eu dei uma rápida olhada na geometria e texturização para ver a possibilidade de futuramente entrarem na lista, mas não eram muito avançados tecnicamente, muitas vezes a arte acaba elevando o nível gráfico do jogo para outro patamar. O problema está sendo o tempo mesmo, pois uma postagem mais aprofundada mostrando geometria, texturas, efeitos e outras coisas demoram 6 horas no mínimo (outras tem que picar em partes devido ao número de detalhamento do jogo).
 
Ultima Edição:

Sega&AMD

Ei mãe, 500 pontos!
Mensagens
13.708
Reações
13.742
Pontos
803
O problema está sendo o tempo mesmo, pois uma postagem mais aprofundada mostrando geometria, texturas, efeitos e outras coisas demoram 6 horas no mínimo (outras tem que picar em partes devido ao número de detalhamento do jogo).

Qual a sua metodologia para distinguir o avançado do artístico sobretudo no gamecube ? e para separar os quesitos técnicos e obter os dados relevantes aos gráficos ?

por exemplo self shadowing da para saber vendo/jogando mas tem coisa que não tem jeito sem um post mortem do dev na falta disso é preciso você próprio destrinchar os dados, a pergunta é: qual tem sido sua metodologia. contagem poligonal mesmo dependendo de como é averiguada não é segura, também pode não ser relevante, nem mesmo o que diz alguns devs deve ser levado como o grão de sal pois podem estar fazendo jogo de palavras para vender o próprio peixe como o cara da EA que disse na época que o Saturn suportava 60.000 polígonos em Daytona enquanto o ps1 podia ir muito além fazendo 300.000 ou seja ele ludibriou o pessoal induzindo-os ao erro propositalmente, mas como no período ninguém sabia de nada e isso foi tido por verdade por anos.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.213
Reações
4.520
Pontos
453
Qual a sua metodologia para distinguir o avançado do artístico ? e para separar os quesitos técnicos e obter os dados ? por exemplo self shadowing da para saber vendo/jogando mas tem coisa que não tem jeito sem um post mortem do dev, é preciso você próprio destrinchar os dados.
Emuladores de debug, programa de ripar modelos 3D e texturas, programa de contagem de cores, programa para abrir modelos 3D e programa de medir frame-rate.

O critério é olhar todo o conjunto, carga poligonal, resolução e quantidade de texturas, efeitos, iluminação/sombreamento, resolução do jogo, física, parte sonora e desempenho. Tem jogo que a geometria é baixa, assim como a resolução das texturas, etc. Mas possui o visual bonito, usando texturas bem desenhadas e coloridas (mesmo em resoluções menores), cenários que apresentam boa modelagem mesmo com poucos polígonos (usando gráficos pré-renderizados), ou usando de algum efeito (como reflexos usando a imagem do frame-buffer) ou iluminação/sombreamento dinâmico (que acabam destacando o jogo visualmente), mas que já eram usados em hardwares mais fracos e que do ponto de vista técnico não exigem muito do processador, memória e placa de vídeo, mas apelam para o talento artístico e para programação inteligente dos desenvolvedores.

O que o desenvolvedor ou empresa falou (assim como o que está na especificação técnica do hardware) tem que ser confirmado na prática usando programas, se bater com o que foi falado pelo dev ou com o bechmark significa que é verídico, caso contrário é questão de marketing. Normalmente é bom ter pelo menos 2 fontes em que as informações estão de acordo (como 2 programadores diferentes falando sobre o mesmo assunto por exemplo), em seguida é desmontar o jogo pra ver se é aquilo mesmo.
 
Ultima Edição:

Amigo Bolha

Mil pontos, LOL!
Mensagens
21.325
Reações
29.451
Pontos
1.424
Pode ser que alguém aqui não conheça. Esse é SM64 versão nativa do PS2, um port feito por um fã e está sendo comparado com a versão N64, impressionante, claro é de se imaginar que o ps2 possa fazer bem mais o grande ponto aqui é que o jogo foi codificado por um homebrew e está de parabéns, o cpu do ps2 EE tem um parentesco com o cpu do N64 portanto era natural que alguém conseguisse o port. No mais Mario 64 ainda é um ótimo jogo.


O pessoal já fez engenharia reversa no código fonte do Mario 64. Tem um port nativo pra PC também e o código foi bem estudado.
Em teoria da pra fazer port do Mario para o que quiser agora, igual Doom, basta ter vontade e conhecimento.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.213
Reações
4.520
Pontos
453
Nós chegamos a comentar aqui sobre o Ray-Tracing no Nintendo 64, sendo que em sua maioria (99%) eram polígonos espelhados, Perfect Dark também usa da mesma técnica, tem partes onde o cenário inteiro é refletido no chão, tanto as paredes como os sofás, pilares e outros objetos são polígonos duplicados, muito impressionante também.

213434

Porém, tem algumas partes onde usaram RAY-TRACING EM TEMPO REAL, como algumas poças d’água, realmente não dá pra usar algo tão pesado em grande escala (ainda mais em hardwares daquela época), note que no chão não existem polígonos duplicados, apenas um quadrado com 2 polígonos invertidos onde a textura da poça d’água é colada em cima.

213436

Mas de fato que o efeito foi usado, como a própria Rare anunciou antes do lançamento do jogo (no trailer de 1998 na ECTS), bem como outros feitos impressionantes, sombreamento dinâmico e sistema próprio de inteligência artificial muito avançada.




213438

Conker herdou muitas coisas como o sombreamento dinâmico, driver de som e até mesmo o sistema de partículas, porém, o Ray-Tracing presente em algumas poças d’água foi retirado, onde eles optaram em usar polígonos duplicados em tudo, o que não deixa de ser impressionante, Conker tem uma geometria muito alta pra época, tanto os personagens como cenários possuem muitos polígonos, além de processar tudo de uma vez, pois o cenário está completamente alocado na memória, não existe descarte de polígonos, note que atrás da parede tem os wireframes dos ratos e objetos dentro do bar sendo processados, além das paredes mais ao fundo, nenhum outro jogo da geração colocou tantos polígonos em tela (tirando Battle For Naboo), a quantidade de wireframes é algo totalmente surreal pra época, tudo rodando a 30/25 FPS, fazendo jus ao hardware do Ultra 64.

213432
 
Ultima Edição:

Jefferson Praxedes

Bam-bam-bam
Mensagens
2.051
Reações
7.547
Pontos
453
Impressiomante mesmo ! Perfect Dark tem um único raio de luz para cada sala sempre que uma fonte de luz aparece (Explosões, tiros) que colore a referida sala com aquela mesma. É por isso que eles mencionam o ray tracing nas imagens promocionais da época.

213443

Tecnicamente falando além dos reflexos um único raio, que coloria cada sala dependendo das luzes que aconteciam lá dentro. Seja explosões, armas alienígenas, faíscas leves ou tiros normais. O ray tracing não é apenas reflexos, é como as superfícies reagem às fontes de luz e isso na época projetando para hoje que virou uma trend pra vender placa de vídeo , a Rare gostava de usar todos os recursos do console seus jogos mesmo.

213444

Reflexo no vidro da mesa e luz atingindo a sala de forma real
 
Topo Fundo