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

[jadersnes]

Galera, como que tá o sistema de emulação de NES pro N64 no Everdrive? Teve mais alguma atualização? Até um tempo atrás muitos jogos não rodavam por conta dos chips especiais que o Nintendinho usava. Já fizeram alguma melhoria no sistema?

 

[Ridge]

 

[ELTORO]

Achei insana essa hack do Kaze, olha o boss que ele fez no Ocarina of Time:

Desculpe mas pra mim essa é uma das piores listas já feitas do N64.
Cara colocou Shadows of Empire, Quake, e Body Harvest lá embaixo na lista.
Tá que não são jogos espetaculares mas existem outros bem piores, tipo o South Park que ele colocou várias posições na frente.

Teve vários outros aí tbm que ficaram lá embaixo, Turok (posição 150), Forsaken 64 (153), StarCraft (164), Pilotwings (129), Jet Force Gemini (120), Banjo Tooie (115)...
Dá nem pra acreditar que essa lista foi séria.

 

[BigJ]

Já devem ter comentado, mas um jogo que acho bem impressionante para o N64 é o Mickey's Speedway USA.



Produzido pela Rare (deve ter rolado um acordo entre a Nintendo e a Disney), este clone de Mario Kart é muito bonito (as texturas foram feitas com CGs estilizadas) e roda a constantes 30 FPS, pelo que notei.

Pra manter essa performance, a Rare usa bastante sprites 2D (também CGs pré-renderizados) nos veículos quando vistos de longe ou em detalhes, como os pneus dos karts (?) ou nos barris que guardam os itens especiais.

 

[ELTORO]

Já devem ter comentado, mas um jogo que acho bem impressionante para o N64 é o Mickey's Speedway USA.



Produzido pela Rare (deve ter rolado um acordo entre a Nintendo e a Disney), este clone de Mario Kart é muito bonito (as texturas foram feitas com CGs estilizadas) e roda a constantes 30 FPS, pelo que notei.

Pra manter essa performance, a Rare usa bastante sprites 2D (também CGs pré-renderizados) nos veículos quando vistos de longe ou em detalhes, como os pneus dos karts (?) ou nos barris que guardam os itens especiais.

Apesar de ser bem melhor que o MK64.
Eu não acho esse jogo impressionante justamente por dos personagens serem em sprites. Não consigo curtir esse visual.

Se fosse em 60FPS aí já acharia diferente.

Edit :
Ou será que estou viajando e os personagens são em 3D?
Agora confesso que fiquei confuso

 

[BigJ]

Os pilotos e carros de Mickey's Speedway são 3D, mas com alguns detalhes em 2D, como os pneus.

Mas quando os pilotos adversários ficam distante do jogador, são substituídos por sprites 2D.

 

[ELTORO]

Os pilotos e carros de Mickey's Speedway são 3D, mas com alguns detalhes em 2D, como os pneus.

Mas quando os pilotos adversários ficam distante do jogador, são substituídos por sprites 2D.

Entendi, então eu tava viajando mesmo

Mas fico pensando se não dava pra melhorar a performance mais ainda.
Eu vi o jogo rodando em 60FPS (por emulador) e achei bem mais agradável.
Seria que o N64 aguentaria?

PS: vendo o vídeo de novo, o que achei legal é que tem até umas folhas caindo no meio da pista, da primeira vez não tinha reparado isso.
Final de semana vou baixar e dar uma jogada, nunca cheguei a jogar muito esse jogo.

Edit:
Achei um cara que está otimizando o Diddy Kong Racing, deu um pulo absurdo de performance:

 

[Jefferson Praxedes]

Nessa screenshot da pra ver claramente que apenas as rodas são feitas de sprites.
A técnica de LOD ainda é usada até hoje , me lembro bastante do BloodBorne e Elden Ring em telas com muitos inimigos os mais distantes ficam assim hehe.

 

[kimsnk]

Já devem ter comentado, mas um jogo que acho bem impressionante para o N64 é o Mickey's Speedway USA.



Produzido pela Rare (deve ter rolado um acordo entre a Nintendo e a Disney), este clone de Mario Kart é muito bonito (as texturas foram feitas com CGs estilizadas) e roda a constantes 30 FPS, pelo que notei.

Pra manter essa performance, a Rare usa bastante sprites 2D (também CGs pré-renderizados) nos veículos quando vistos de longe ou em detalhes, como os pneus dos karts (?) ou nos barris que guardam os itens especiais.

esse jogo é muito bom e dificil também kkk mais fizeram um trabalho muito bom o jogo diverte.

 

[Jefferson Praxedes]

 

[Jefferson Praxedes]

 

[Wolkaiser]

O uso do cartucho de expansão do 64 para Donkey Kong 64 foi exclusivamente para adicionar iluminação dinâmica ao jogo.

 

[Falkner]

essa disgraça é a única coisa que falta pro meu n64
mas me recuso a pagar 350 nisso

 

[kimsnk]

essa disgraça é a única coisa que falta pro meu n64
mas me recuso a pagar 350 nisso

Tem hora que penso em comprar mais e foda um acessório que apenas 2 jogos realmente necessitam dele para ser jogado e as melhorias que dão em outro games são quase nada só se achar bem mais em conta.

 

[Fabio Alexandre]

Quando comprei o Expansion Pack em 2015 por 70 Reais já achei caro,...... ridículo os preços que estão cobrando hoje.
.
Outro acessório que acho essencial hoje pra quem tem o N64 é o Rumble Pak com Mod para não precisar de pilhas.
Lá na época de lançamento quando comprei o Star Fox 64 com Rumble Pak, usei pouquíssimo ele por gastar pilhas demais.
.
E com esse Mod sem o peso das pilhas, o Rumble tem uma força muito maior e não pesa tanto o controle na mão.
Estou aproveitando bastante, na época acho que testei só uns 5 jogos com ele, e jogar com Vibração faz muita diferença em alguns jogos.

 

[Wolkaiser]

A maioria dos jogos não tem muita utilidade, acaba tendo a penalização de derrubar o framerate por mais resolução.

 

[Fabio Alexandre]

Lembram se do 3DO M2, a expansão do console de 32 bits 3DO que transformaria ele num console de 64 bits,........ acabou sendo cancelado.
Na E3 de 1995 a 3DO apresentou um vídeo que alegava ser feito em tempo real pelo aparelho, claramente um vídeo pré-renderizado.
.

.
.
Dizem que esse jogo FPS cancelado, se tornou o jogo Disruptor lançado pela Insomniac para o Play1 em 1996, pois descobriram muita semelhança nos assets.
.

.
.
Fico pensando se a Insomniac tivesse mirado o desenvolvimento desse jogo para o N64, será que ele conseguiria reproduzir razoavelmente esse visual do vídeo ??
Lembrando que o N64 tem games com visual super avançados pra sua época, como Turok 2 e Perfect Dark, sem falar da impressionante Demo de Mega Texturas.
.

 

[Warrior Of Light]

Já devem ter comentado, mas um jogo que acho bem impressionante para o N64 é o Mickey's Speedway USA.



Produzido pela Rare (deve ter rolado um acordo entre a Nintendo e a Disney), este clone de Mario Kart é muito bonito (as texturas foram feitas com CGs estilizadas) e roda a constantes 30 FPS, pelo que notei.

Pra manter essa performance, a Rare usa bastante sprites 2D (também CGs pré-renderizados) nos veículos quando vistos de longe ou em detalhes, como os pneus dos karts (?) ou nos barris que guardam os itens especiais.

Mickey´s Speedway USA usa algumas das mesmas técnicas do Mario Kart 64, apesar disso, é bem mais avançado, pois tirando algumas técnicas replicadas (como sprites nas rodas e em outros objetos) é outro jogo que usa micro-código para aumentar os limites poligonais e melhorar desempenho, quase tudo é 3D e roda a 30 FPS. Mickey no kart possui 272 polígonos e 176 vértices.





Se fôssemos fazer uma comparação direta, o ideal seria Crash Team Racing, que também usa das mesmas técnicas do Mickey´s Speedway USA (rodas dos karts e outros objetos em 2D). Tem praticamente a mesma geometria e roda em 30 FPS também. Crash no kart possui os mesmos 272 polígonos (sem a sombra do corredor, com a sombra adiciona-se 2 polígonos pra colar a textura de sombra), mas apesar disso, muito mais vértices, com 816 (vértices também exigem processamento).





Existe um motivo para esses jogos usarem sprites nas rodas dos karts ao invés de 3D, que vai além de poupar processamento, na verdade está mais ligado a capacidade geométrica desses consoles, se cada kart tivesse 4 rodas em 3D teriam muito mais polígonos do que os próprios karts, agora multiplica para todos os corredores na tela, seria algo inviável e essa era a única solução, pois extrapolaria a capacidade de processar polígonos da GPU.

Apenas uma única roda totalmente em 3D não teria menos de 200 polígonos nunca. Se quer um exemplo disso (onde os "karts" são todos em 3D) seria Star Wars Episode I: Racing, que tudo é 3D incluindo todos os objetos arredondados e circunferências das naves (usando micro-código de alta capacidade poligonal). Mas aqui estamos falando de umas das poucas dev´s que dominaram quase que completamente o N64. O corredor Ben Quadinaros e sua nave possuem 1.234 polígonos e 1.087 vértices (todos corredores ficam nessa média poligonal, alguns até mais).



Factor 5 foi bem além da Rare e muitas outras no N64, pois otimizou demais seus micro-códigos, a ponto de reescrevê-los praticamente do zero (como disseram numa entrevista a IGN). Tanto que hoje você vê vários jogos da Rare (dentre outras dev's) tendo seus micro-códigos otimizados para melhorar desempenho (o próprio Diddy Kong Racing postado acima), e em alguns casos até portam pra outro micro-código mais rápido (como fizeram no caso do Doom 64).

O uso do cartucho de expansão do 64 para Donkey Kong 64 foi exclusivamente para adicionar iluminação dinâmica ao jogo.

O que desmente algo falado a muito tempo (que enganou até a mim), onde no caso de Donkey Kong 64 seria apenas usado para correção de bug (memory leak), onde o jogo travava por conta desse vazamento de memória. Ao contrário do que disseram por longa data, o Expansion Pak em DK64 é de ótima utilidade, pois iluminação dinâmica naquela época era como ouro puro, semelhante ao Ray-Tracing nos dias atuais.

Existem outros jogos que também fazem ótimo uso, como Road Rash 64 (que dobra o desempenho de 30 para 60 FPS), Army Man 1 e 2 (aumento de resolução e frame-rate), Command & Conker (aumento de resolução e frame-rate) , Pokemon Stadium 2 (aumento de resolução sem piorar desempenho), Quake II (melhora de cores deixando a imagem mais nítida e aumento de frame-rate), etc.

Fiz uma postagem no tópico sobre os jogos que se beneficiam do Expansion Pak e quais fazem mau uso (página 48):

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

A Nintendo eram bem contra jogos 'cross-gen' nessa época, né? Difícil um game de SNes ser relançado pro N64. Tirando games anuais de esporte (NBA-NFL-NHL e etc), acho que não teve um game do SNes que saiu no N64, pelo que me lembro. Mas estou jogando o Jurassic Park do Super Nes e até queria que...

forum.outerspace.com.br

Quando comprei o Expansion Pack em 2015 por 70 Reais já achei caro,...... ridículo os preços que estão cobrando hoje.
.
Outro acessório que acho essencial hoje pra quem tem o N64 é o Rumble Pak com Mod para não precisar de pilhas.
Lá na época de lançamento quando comprei o Star Fox 64 com Rumble Pak, usei pouquíssimo ele por gastar pilhas demais.
.
E com esse Mod sem o peso das pilhas, o Rumble tem uma força muito maior e não pesa tanto o controle na mão.
Estou aproveitando bastante, na época acho que testei só uns 5 jogos com ele, e jogar com Vibração faz muita diferença em alguns jogos.

70 reais acho algo "bem aceitável" (ainda mais em 2015), até mesmo na época que era bem mais caro o preço estava aceitável (onde custava 78,99), muito por conta do produto, era memoria RAM e vários jogos podiam se beneficiar posteriormente, RAM na época custava absurdos (nem vou comparar os preços de RAM no PC). Caro mesmo eram os jogos, que custavam em torno de 150,00 e esse foi um grande problema, pois era o preço do salário em 2000 e ainda tinha que competir contra outro console que a pirataria reinava, eram 3 CD's por 10,00 (o consumidor fazia a festa).

 

[Fabio Alexandre]

 

[Warrior Of Light]

Rumble Pak foi uma das revoluções que o N64 trouxe para os consoles. MVG tá gostando mesmo do N64, talvez pelo fato dele ser desenvolvedor e ver como o pessoal está ligado em 220v nesse cenário homebrew, algo que é realmente um fenômeno, devido a complexidade de programar no N64.

Saiu novo micro-código (Tiny3D) para usar no libdragon (que aos poucos vem se tronando um SDK excelente), tá realmente muito rápido para processamento 3D.



Nesse novo micro-código você agora tem um pipeline 3D completo para renderizar cenas 3D completas, incluindo funções para modelagem de objetos, Iluminação do ambiente com mais 8 fontes de luz independentes (para iluminação local e dinâmica), vértices comuns ou coloridas ao mesmo tempo, fácil de compilar numa API de linguagem C. Vamos aos benchmarks poligonais.

- 1.800 polígonos em 60 FPS (108 mil polígonos por segundo)
- 5.184 polígonos em 30 FPS (155,5 mil polígonos por segundo)

Nada mal para algo que está chegando agora, e isso significa mais homebrews de alta qualidade.

Faz um bom tempo que estou querendo mostrar algumas coisas sobre o Star Wars Episode I: Battle for Naboo, mas o micro-código é complexo demais para fazer debug, no entanto, consegui ripar os gráficos e analisar tudo para ver se era tudo aquilo que os desenvolvedores disseram em entrevistas.

Começando pelo Droid Fighter, que disseram ter 200 polígonos.

IGN64: In the levels that take place in outer space there are a lot of vehicles on the screen. Can you comment on any of the actual numbers involved? Amount of aircraft? Polygon numbers?

Factor 5: That's up to 30 fighters and wingmen in those space battles. A droid fighter has roughly 200 polygons.

De fato, ele possui 207 polígonos e 143 vértices.



Ele também disse sobre ter 30 naves na tela ao mesmo tempo na fase de batalha aérea (Battle for Naboo), e conferindo aqui eu contabilizei 27 naves ao total (sendo 7 wingman e 20 droid fighter), durante a batalha aparecem mais alguns droid fighter, portanto, também está dentro do que ele disse.




Sobre o sistema de 3.000 partículas (usado nas fases de chuva e neve), sem ficar sofrendo de slowdowns e sem usar a CPU.

IGN64: It looks like Battle for Naboo uses a much improved particle effects system. Many of the things that spark or explode do so in a varied manner. Did you bribe the N64 to tell you all its secrets?

Factor 5: If simple bribery would have done it. It was long nights with the dev-kits and some very unafraid programmers, who had the crazy idea to write a particle system for the RSP co-processor in microcode. We started it for Indy's snow levels because we needed huge amounts of snow on screen but when it was done we used it in both games all over the place. The rain and the snow have up to 3000 particles at any given time without any slowdown and without using the CPU at all. Many of the explosions have particles added and even the fountains in Theed are made up of them.

Outra verdade, pois apesar de não ter como ripar as partículas (elas estão sendo processadas em tempo real ao invés de serem todas armazenadas na RAM), você pode olhar o que está acontecendo no código, além disso, você pode olhar a porcentagem de uso da CPU e o desempenho. A CPU (r4300i) sempre fica em torno de 86% de uso, independente de terem ou não partículas nos cenários.



Sobre não ficar sofrendo de slowdowns (mesmo com 3 mil partículas) vamos falar na postagem mais abaixo, pois tem outra entrevista dele falando sobre o desempenho.

Vamos conferir as texturas. Disseram que o jogo possui um horizonte ilimitado e boa variedade de paisagens e texturas.

GN64: Battle of Naboo contains a lot of diversity when it comes to environments. Was this a prime objective from the beginning? Because we feel the variety is well worth it.

Factor 5: Oh certainly. We have had our plans for landscape engines since the mid-90s, so each game with landscape technology from us tries to achieve more of that original goal. One of the things we really got under control in Naboo was the unlimited horizon and nice variety in landscape types and textures. You also start to see a few trees here and there. The N64 really is stretched out at this point, but luckily there are other things around the corner.

Além do horizonte (draw distance) ser enorme a variação de paisagens e texturas é realmente muito alta, aqui somente as texturas de algumas árvores, terreno e gramado, e ainda está faltando ripar algumas.



Justamente nessa postagem (de outra entrevista) ele afirma não terem problemas de desempenho, mesmo no modo de alta resolução (usando o Expansion Pak).

It’s much more technologically advanced than Rogue Squadron and squeezes out every last bit from the N64. RSP-based particles and physics systems, a much deeper draw distance, indoor/city levels – the team pulled out all the stops. Plus, we had truly mastered the use of the N64 Expansion Pak at that point, giving players higher resolution without a compromise in framerate.

Aqui novamente ele estava certo, pois o jogo roda em constantes 30 FPS com 3 mil partículas e tudo mais, com raros casos de perca de desempenho, algo bem imperceptível mesmo, pois na grande maioria do tempo o jogo roda em 30 FPS.



Nessa mesma entrevista ele fala diversas coisas a respeito do PS1, que ele não seria capaz de replicar o mesmos cenários com menos quantidade de RAM e dos seus gráficos com dithering e instáveis, além disso, falaram porque acontecia do N64 ter menos capacidade geométrica, além do som ruim devido as ferramentas ruins (e usando o micro-código porco da Nintendo), tanto que refizeram tudo do jeito deles, novas ferramentas e novo driver de som (MusyX), algo de conhecimento geral hoje em dia.

Factor 5 also worked on Indiana Jones and the Infernal Machine. Can you tell us more about how that project began? How happy were you with how the game turned out?

I was a huge fan of Indiana Jones and the Fate of Atlantis and I had high hopes for a Tomb Raider-type Indy game being written and directed by Hal Barwood. Unfortunately, the technology and control for the PC version never came together, and the final product, while having a great story and writing, and good level design, was clunky to play and behind the times. There was a PlayStation version in parallel development, and at some point, it became clear that the PlayStation wouldn‘t have the internal memory to handle the levels, so the project was cancelled.

The jump to 3D was hard. We had to learn everything new: cameras, controls, the spatial orientation of the player and 3D-object animation. Everything was very different from 2D games. A lot of teams gave up during the transition. It didn’t help that we didn’t exactly enjoy the PlayStation. It had very crude graphics with lots of pixels, very unstable rendering of the 3D world and was, in several ways, actually a step backwards from the sophisticated, artistic look of 2D games of the era. It was especially bad for landscape rendering.

When we heard about the N64 and its Silicon Graphics-based capabilities, we were extremely excited. We had a Silicon Graphics Indy in the office for our 3D object creation and animation, so we knew that the look of the N64 would be much more sophisticated.

They chose Hoth because it could be represented by very few 3D objects and mostly flat terrain. They described the architecture of the N64 to us in detail. Coming from the PlayStation, we quickly realised that the N64’s micro-code generated far fewer polygons than the PlayStation was capable of. We were also really shocked by the extremely limited features of its RSP [Reality Signal Processor] sound driver.

The N64 in the early days was the polar opposite. We saw the turnaround times that the Shadows of the Empire team had to endure and decided that it was so inefficient that we wanted a completely different approach. We reached out to our PlayStation development hardware partners SN Systems, who are a part of Sony nowadays, but were independent then. We proposed to collaborate on an alternative N64 dev kit and software toolchain, completely circumventing Silicon Graphics’ tools. We focussed on the software toolchain, whereas SN Systems was responsible for the hardware – essentially an N64 cartridge with memory connected to a regular PC so we could work as efficiently as we had for all prior platforms. We luckily never had to use the original development environment.

Sobre as capacidades do PS1 contra o N64 todos já sabemos. PS1 realmente não poderia replicar esse jogo, pois cada cenário tem uma geometria absurda, onde usaram até tesselation, tornando cada cenário open-world um verdadeiro monstro em geometria. Inclusive usaram tesselantion principalmente na água, e por isso ela pode ser completamente animada.

Aqui temos 3.254 polígonos e 1.887 vértices (somente do terreno), isso em 30 FPS = 97.620 polígonos (tirando as partículas e as naves).



Em outra entrevista afirmam usar várias texturas de alta resolução em todas as texturas (lembrando que a resolução máxima é 64x64 pixels para cada textura), usando uma ferramenta que eles mesmos desenvolveram, para burlar os 4KB do cache de texturas, além disso como as texturas se atualizam e cobrem os polígonos conforme o jogador anda pelo cenário.

Factor 5: We are using every trick possible in terms of optimal use of the 4K texture cache for every single texture. The programmers figured out the weirdest texture formats to get every texture to maximum resolution. An elaborate tool analyzes each original source texture and tries to come up with the best texture format for it on the N64. The tool also allows manipulating and choosing these texture formats by hand, something which we had to do in a lot of cases.

The sheer amount of textures was possible due to the streaming from the cartridge. While the player is running through the level, the program figures out which parts of the level need to be streamed in and does that in the background. So the amount of textures and size of levels is only limited by the cartridge, not the RAM of the N64. To achieve this, we had to rewrite not only all of the microcode but also quite a bit of the N64s operating system.

Mais uma vez tudo é verdade, olhei praticamente todas as texturas desse jogo e quase todas tem tamanho de 64x64 pixels, além disso, todas são texturas de 32 bits, ou seja o máximo que o N64 é capaz de fazer em termos de texturas.



Outra coisa que eu queria destacar é que tudo é texturizado (o que eles também mencionam), eles não ficam usando polígonos coloridos misturados com polígonos texturizados. Ainda tem outra forma de olhar, pelo debug todas as texturas estão sempre se atualizando, a cada movimento das naves.



Por fim, eles afirmando novamente o horizonte ilimitado que o jogo proporciona, da alta resolução aliada ao bom desempenho, da grande quantidade e resolução das texturas, além de falarem sobre o jogo não ter FOG (neblina), dentre outras coisas que somente a Factor 5 proporcionou ao N64.

IGN64: From a technical standpoint, what have you pulled off with Indy that most other N64 games simply aren't doing?

Factor 5: The high resolution and still having a really high framerate, the amount and resolution of the textures, the quality of the orchestral music and the environmental audio for sound effects, the real-time light and the particle system are the main technical qualities. You also get unlimited view-depth without any annoying fog.

Tudo aqui já foi confirmado anteriormente, faltando somente mostrar alguns pontos pra finalizar. Sobre o FOG eu também testei e de fato não há, não existe FOG nesse jogo, o horizonte é bem longo e você não se depara com nenhuma neblina para mascarar os fundos dos cenários.

Na terceira fase por exemplo, você pode confundir polígonos ainda não texturizados mais ao fundo ou aos redores com FOG, o que acontece porque o jogo já extrapolou o limite de polígonos texturizados nas partes open-world, tendo que deixar alguns polígonos sem texturas mesmo, mas não confundir com FOG que é outra coisa completamente diferente.

Bem lá no fundo na parte cinza parece FOG, mas são os polígonos ainda não texturizados.



Comprovando isso com o modelo desse cenário, as partes verdes são os polígonos texturizados e as partes cinzas e roxas os polígonos ainda não texturizados, o que comprova a veracidade de todas as texturas irem se atualizando para cobrirem os polígonos dos cenários, como eles disseram anteriormente.




Resumindo, tudo o que eles falaram era verdade. Não teve marketing e nem mentira pra vender o jogo através de informações falsas ou para se mostrarem como programadores melhores do que os outros. Se eles falaram é porque realmente fizeram, sem a necessidade de inflamarem os números reais.

Pra completar a postagem vou colocar aqui 2 modelos de naves, Police Cruiser e Naboo Fighter, ambos com alta geometria (padrão do jogo).





Todas as entrevistas na íntegra. Muito bom quando os desenvolvedores são honestos, pois alguns chegam até a usar vídeos pré-renderizados pra dizerem que são os gráficos dos jogos que serão lançados, enganando todo mundo antes mesmo do jogo ser lançado.

Interview: Battling the N64 - IGN

If you own a Nintendo 64 then there is a good chance you've played Star…

www.ign.com

Interview: Factor 5's Julian Eggebrecht On Star Wars, Indiana Jones And Choosing N64 Over PS1

"Our games were treated like first-party games"

www.timeextension.com

Bringing Indy to N64 - IGN

Nintendo 64 has long been without an appropriate title to fill the…

www.ign.com

 

[ELTORO]

Rumble Pak foi uma das revoluções que o N64 trouxe para os consoles. MVG tá gostando mesmo do N64, talvez pelo fato dele ser desenvolvedor e ver como o pessoal está ligado em 220v nesse cenário homebrew, algo que é realmente um fenômeno, devido a complexidade de programar no N64.

Saiu novo micro-código (Tiny3D) para usar no libdragon (que aos poucos vem se tronando um SDK excelente), tá realmente muito rápido para processamento 3D.



Nesse novo micro-código você agora tem um pipeline 3D completo para renderizar cenas 3D completas, incluindo funções para modelagem de objetos, Iluminação do ambiente com mais 8 fontes de luz independentes (para iluminação local e dinâmica), vértices comuns ou coloridas ao mesmo tempo, fácil de compilar numa API de linguagem C. Vamos aos benchmarks poligonais.

- 1.800 polígonos em 60 FPS (108 mil polígonos por segundo)
- 5.184 polígonos em 30 FPS (155,5 mil polígonos por segundo)

Nada mal para algo que está chegando agora, e isso significa mais homebrews de alta qualidade.

Faz um bom tempo que estou querendo mostrar algumas coisas sobre o Star Wars Episode I: Battle for Naboo, mas o micro-código é complexo demais para fazer debug, no entanto, consegui ripar os gráficos e analisar tudo para ver se era tudo aquilo que os desenvolvedores disseram em entrevistas.

Começando pelo Droid Fighter, que disseram ter 200 polígonos.



De fato, ele possui 207 polígonos e 143 vértices.

Visualizar anexo 385670

Ele também disse sobre ter 30 naves na tela ao mesmo tempo na fase de batalha aérea (Battle for Naboo), e conferindo aqui eu contabilizei 27 naves ao total (sendo 7 wingman e 20 droid fighter), durante a batalha aparecem mais alguns droid fighter, portanto, também está dentro do que ele disse.

Visualizar anexo 385690


Sobre o sistema de 3.000 partículas (usado nas fases de chuva e neve), sem ficar sofrendo de slowdowns e sem usar a CPU.



Outra verdade, pois apesar de não ter como ripar as partículas (elas estão sendo processadas em tempo real ao invés de serem todas armazenadas na RAM), você pode olhar o que está acontecendo no código, além disso, você pode olhar a porcentagem de uso da CPU e o desempenho. A CPU (r4300i) sempre fica em torno de 86% de uso, independente de terem ou não partículas nos cenários.

Visualizar anexo 385671

Sobre não ficar sofrendo de slowdowns (mesmo com 3 mil partículas) vamos falar na postagem mais abaixo, pois tem outra entrevista dele falando sobre o desempenho.

Vamos conferir as texturas. Disseram que o jogo possui um horizonte ilimitado e boa variedade de paisagens e texturas.



Além do horizonte (draw distance) ser enorme a variação de paisagens e texturas é realmente muito alta, aqui somente as texturas de algumas árvores, terreno e gramado, e ainda está faltando ripar algumas.

Visualizar anexo 385678

Justamente nessa postagem (de outra entrevista) ele afirma não terem problemas de desempenho, mesmo no modo de alta resolução (usando o Expansion Pak).



Aqui novamente ele estava certo, pois o jogo roda em constantes 30 FPS com 3 mil partículas e tudo mais, com raros casos de perca de desempenho, algo bem imperceptível mesmo, pois na grande maioria do tempo o jogo roda em 30 FPS.

Visualizar anexo 385680

Nessa mesma entrevista ele fala diversas coisas a respeito do PS1, que ele não seria capar de replicar o mesmos cenários com menos quantidade de RAM e dos seus gráficos com dithering e instáveis, além disso, falaram porque acontecia do N64 ter menos capacidade geométrica, além do som ruim devido as ferramentas ruins (e usando o micro-código porco da Nintendo), tanto que refizeram tudo do jeito deles, novas ferramentas e novo driver de som (MusyX), algo de conhecimento geral hoje em dia.









Sobre as capacidades do PS1 contra o N64 todos já sabemos. PS1 realmente não poderia replicar esse jogo, pois cada cenário tem uma geometria absurda, onde usaram até tesselation, tornando cada cenário open-world um verdadeiro monstro em geometria. Inclusive usaram tesselantion principalmente na água, e por isso ela pode ser completamente animada.

Aqui temos 3.254 polígonos e 1.887 vértices (somente do terreno), isso em 30 FPS = 97.620 polígonos (tirando as partículas e as naves).

Visualizar anexo 385682

Em outra entrevista afirmam usar várias texturas de alta resolução em todas as texturas (lembrando que a resolução máxima é 64x64 pixels para cada textura), usando uma ferramenta que eles mesmos desenvolveram, para burlar os 4KB do cache de texturas, além disso como as texturas se atualizam e cobrem os polígonos conforme o jogador anda pelo cenário.



Mais uma vez tudo é verdade, olhei praticamente todas as texturas desse jogo e quase todas tem tamanho de 64x64 pixels, além disso, todas são texturas de 32 bits, ou seja o máximo que o N64 é capaz de fazer em termos de texturas.

Visualizar anexo 385704

Outra coisa que eu queria destacar é que tudo é texturizado (o que eles também mencionam), eles não ficam usando polígonos coloridos misturados com polígonos texturizados. Ainda tem outra forma de olhar, pelo debug todas as texturas estão sempre se atualizando, a cada movimento das naves.

Visualizar anexo 385706

Por fim, eles afirmando novamente o horizonte ilimitado que o jogo proporciona, da alta resolução aliada ao bom desempenho, da grande quantidade e resolução das texturas, além de falarem sobre o jogo não ter FOG (neblina), dentre outras coisas que somente a Factor 5 proporcionou ao N64.



Tudo aqui já foi confirmado anteriormente, faltando somente mostrar alguns pontos pra finalizar. Sobre o FOG eu também testei e de fato não há, não existe FOG nesse jogo, o horizonte é bem longo e você não se depara com nenhuma neblina para mascarar os fundos dos cenários.

Na terceira fase por exemplo, você pode confundir polígonos ainda não texturizados mais ao fundo ou aos redores com FOG, o que acontece porque o jogo já extrapolou o limite de polígonos texturizados nas partes open-world, tendo que deixar alguns polígonos sem texturas mesmo, mas não confundir com FOG que é outra coisa completamente diferente.

Bem lá no fundo na parte cinza parece FOG, mas são os polígonos ainda não texturizados.

Visualizar anexo 385712

Comprovando isso com o modelo desse cenário, as partes verdes são os polígonos texturizados e as partes cinzas e roxas os polígonos ainda não texturizados, o que comprova a veracidade de todas as texturas irem se atualizando para cobrirem os polígonos dos cenários, como eles disseram anteriormente.


Visualizar anexo 385713

Resumindo, tudo o que eles falaram era verdade. Não teve marketing e nem mentira pra vender o jogo através de informações falsas ou para se mostrarem como programadores melhores do que os outros. Se eles falaram é porque realmente fizeram, sem a necessidade de inflamarem os números reais.

Pra completar a postagem vou colocar aqui 2 modelos de naves, Police Cruiser e Naboo Figher, ambos com alta geometria (padrão do jogo).





Todas as entrevistas na íntegra. Muito bom quando os desenvolvedores são honestos, pois alguns chegam até a usar vídeos pré-renderizados pra dizerem que são os gráficos dos jogos que serão lançados, enganando todo mundo antes mesmo do jogo ser lançado.

Interview: Battling the N64 - IGN

If you own a Nintendo 64 then there is a good chance you've played Star…

www.ign.com

Interview: Factor 5's Julian Eggebrecht On Star Wars, Indiana Jones And Choosing N64 Over PS1

"Our games were treated like first-party games"

www.timeextension.com

Bringing Indy to N64 - IGN

Nintendo 64 has long been without an appropriate title to fill the…

www.ign.com

E pensar que alguns juravam que esse jogo era lotado de fog.
Bom saber que com o tempo a verdade foi esclarecida.

 

[ELTORO]

Achei doidera esses reflexos no Rally Challenge 2000

 

[Seu Oscar]

Achei doidera esses reflexos no Rally Challenge 2000

Isso é em tempo real?

 

[ELTORO]

Isso é em tempo real?

Sim tudo em tempo real.
Olha aqui:

 

[ELTORO]

Mickey´s Speedway USA usa algumas das mesmas técnicas do Mario Kart 64, apesar disso, é bem mais avançado, pois tirando algumas técnicas replicadas (como sprites nas rodas e em outros objetos) é outro jogo que usa micro-código para aumentar os limites poligonais e melhorar desempenho, quase tudo é 3D e roda a 30 FPS. Mickey no kart possui 272 polígonos e 176 vértices.

Visualizar anexo 381512
Visualizar anexo 381513


Se fôssemos fazer uma comparação direta, o ideal seria Crash Team Racing, que também usa das mesmas técnicas do Mickey´s Speedway USA (rodas dos karts e outros objetos em 2D). Tem praticamente a mesma geometria e roda em 30 FPS também. Crash no kart possui os mesmos 272 polígonos (sem a sombra do corredor, com a sombra adiciona-se 2 polígonos pra colar a textura de sombra), mas apesar disso, muito mais vértices, com 816 (vértices também exigem processamento).


Visualizar anexo 381516
Visualizar anexo 381517

Existe um motivo para esses jogos usarem sprites nas rodas dos karts ao invés de 3D, que vai além de poupar processamento, na verdade está mais ligado a capacidade geométrica desses consoles, se cada kart tivesse 4 rodas em 3D teriam muito mais polígonos do que os próprios karts, agora multiplica para todos os corredores na tela, seria algo inviável e essa era a única solução, pois extrapolaria a capacidade de processar polígonos da GPU.

Apenas uma única roda totalmente em 3D não teria menos de 200 polígonos nunca. Se quer um exemplo disso (onde os "karts" são todos em 3D) seria Star Wars Episode I: Racing, que tudo é 3D incluindo todos os objetos arredondados e circunferências das naves (usando micro-código de alta capacidade poligonal). Mas aqui estamos falando de umas das poucas dev´s que dominaram quase que completamente o N64. O corredor Ben Quadinaros e sua nave possuem 1.234 polígonos e 1.087 vértices (todos corredores ficam nessa média poligonal, alguns até mais).

Visualizar anexo 381521

Factor 5 foi bem além da Rare e muitas outras no N64, pois otimizou demais seus micro-códigos, a ponto de reescrevê-los praticamente do zero (como disseram numa entrevista a IGN). Tanto que hoje você vê vários jogos da Rare (dentre outras dev's) tendo seus micro-códigos otimizados para melhorar desempenho (o próprio Diddy Kong Racing postado acima), e em alguns casos até portam pra outro micro-código mais rápido (como fizeram no caso do Doom 64).



O que desmente algo falado a muito tempo (que enganou até a mim), onde no caso de Donkey Kong 64 seria apenas usado para correção de bug (memory leak), onde o jogo travava por conta desse vazamento de memória. Ao contrário do que disseram por longa data, o Expansion Pak em DK64 é de ótima utilidade, pois iluminação dinâmica naquela época era como ouro puro, semelhante ao Ray-Tracing nos dias atuais.

Existem outros jogos que também fazem ótimo uso, como Road Rash 64 (que dobra o desempenho de 30 para 60 FPS), Army Man 1 e 2 (aumento de resolução e frame-rate), Command & Conker (aumento de resolução e frame-rate) , Pokemon Stadium 2 (aumento de resolução sem piorar desempenho), Quake II (melhora de cores deixando a imagem mais nítida e aumento de frame-rate), etc.

Fiz uma postagem no tópico sobre os jogos que se beneficiam do Expansion Pak e quais fazem mau uso (página 48):

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

A Nintendo eram bem contra jogos 'cross-gen' nessa época, né? Difícil um game de SNes ser relançado pro N64. Tirando games anuais de esporte (NBA-NFL-NHL e etc), acho que não teve um game do SNes que saiu no N64, pelo que me lembro. Mas estou jogando o Jurassic Park do Super Nes e até queria que...

forum.outerspace.com.br

70 reais acho algo "bem aceitável" (ainda mais em 2015), até mesmo na época que era bem mais caro o preço estava aceitável (onde custava 78,99), muito por conta do produto, era memoria RAM e vários jogos podiam se beneficiar posteriormente, RAM na época custava absurdos (nem vou comparar os preços de RAM no PC). Caro mesmo eram os jogos, que custavam em torno de 150,00 e esse foi um grande problema, pois era o preço do salário em 2000 e ainda tinha que competir contra outro console que a pirataria reinava, eram 3 CD's por 10,00 (o consumidor fazia a festa).

Me surgiu uma dúvida : será que não daria pra otimizar os polígonos pra fazer as rodas?
E mascarar o aspecto "quadrado" utilizando algum efeito (como motion blur)?

Não digo que seria mais efetivo, porque 2D daquele jeito fica com aparência melhor (quando bem feito igual no Mickey ou Crash).
Mas lembrei que no jogo Rocket, o jogo tem uma espécie de mini-bug, e ficou muito bom o modelo, com rodas em 3D (acho que cada roda tem 14 polígonos x 4 = 56):

Outra pergunta, o jogo Speed Punks de PS1 utiliza sprites nas rodas ou são polígonos?

 

[Warrior Of Light]

Me surgiu uma dúvida : será que não daria pra otimizar os polígonos pra fazer as rodas?
E mascarar o aspecto "quadrado" utilizando algum efeito (como motion blur)?

Não digo que seria mais efetivo, porque 2D daquele jeito fica com aparência melhor (quando bem feito igual no Mickey ou Crash).
Mas lembrei que no jogo Rocket, o jogo tem uma espécie de mini-bug, e ficou muito bom o modelo, com rodas em 3D (acho que cada roda tem 14 polígonos x 4 = 56):

Outra pergunta, o jogo Speed Punks de PS1 utiliza sprites nas rodas ou são polígonos?

Teria como otimizar usando menos polígonos, como nos carrinhos do Rocket, mas ficaria com essa aparência quadrada. Até daria pra deixar menos quadrado adicionando polígonos menores entre as vértices que fazem as ligações entre os polígonos das rodas, mas o aspecto quadrado só sumiria se usassem muitos deles.

Acredito que color blending seria uma melhor opção do que motion blur, pois você estaria mesclando as cores das texturas nas rodas (sem deixar a imagem desfocada), e usando texturas transparentes também, para simular iluminação nas rodas e ajudar a mascarar o aspecto quadrado.

De qualquer forma, a melhor escolha é usar sprites (texturas), pois economiza nos polígonos, no processamento e ainda deixa a roda totalmente arredondada. Ainda tinha a vantagem de não ter que ficar modelando muito, se fosse pra modelar otimizando o máximo possível daria muito mais trabalho e tempo gasto.

Speed Punks também usa sprites (texturas) nas rodas, mas ao contrário dos outros eles colocaram texturas transparentes pra simular iluminação nas rodas.




Na imagem abaixo a mesma cena com as texturas das rodas sem a transparência ativada.

 

[ELTORO]

Teria como otimizar usando menos polígonos, como nos carrinhos do Rocket, mas ficaria com essa aparência quadrada. Até daria pra deixar menos quadrado adicionando polígonos menores entre as vértices que fazem as ligações entre os polígonos das rodas, mas o aspecto quadrado só sumiria se usassem muitos deles.

Acredito que color blending seria uma melhor opção do que motion blur, pois você estaria mesclando as cores das texturas nas rodas (sem deixar a imagem desfocada), e usando texturas transparentes também, para simular iluminação nas rodas e ajudar a mascarar o aspecto quadrado.

De qualquer forma, a melhor escolha é usar sprites (texturas), pois economiza nos polígonos, no processamento e ainda deixa a roda totalmente arredondada. Ainda tinha a vantagem de não ter que ficar modelando muito, se fosse pra modelar otimizando o máximo possível daria muito mais trabalho e tempo gasto.

Speed Punks também usa sprites (texturas) nas rodas, mas ao contrário dos outros eles colocaram texturas transparentes pra simular iluminação nas rodas.


Visualizar anexo 386935

Na imagem abaixo a mesma cena com as texturas das rodas sem a transparência ativada.

Visualizar anexo 386936

Bom post.
Pelo que você disse então valia mais a pena tentar um esquema parecido com o Speed Punks. Pois fica com aparência bem boa, parecendo tridimensional, e fluida.

 

[Warrior Of Light]

Bom post.
Pelo que você disse então valia mais a pena tentar um esquema parecido com o Speed Punks. Pois fica com aparência bem boa, parecendo tridimensional, e fluida.

Seria a melhor alternativa, caso não queira gastar muitos polígonos nas rodas.

Conker faz isso, color blending e texturas transparentes em volta de superfícies quadradas, a fim de deixá-las arredondadas. Dessa forma você mescla as cores das texturas umas nas outras e disfarça mais ainda para tirar o aspecto quadrado aplicando transparências.

Aqui o conceito é o mesmo do que poderia ser feito nas rodas e do que disse acima, porém, está sendo usado no chão, no gramado em volta da placa "Nasty Nice" circulado em vermelho. Sem color blending e transparecias ficaria quadrado igual no chão riscado em azul, pois não tem nada mascarando.

 

[Jefferson Praxedes]

 

[Gustavo Reis]

Seria a melhor alternativa, caso não queira gastar muitos polígonos nas rodas.

Conker faz isso, color blending e texturas transparentes em volta de superfícies quadradas, a fim de deixá-las arredondadas. Dessa forma você mescla as cores das texturas umas nas outras e disfarça mais ainda para tirar o aspecto quadrado aplicando transparências.

Aqui o conceito é o mesmo do que poderia ser feito nas rodas e do que disse acima, porém, está sendo usado no chão, no gramado em volta da placa "Nasty Nice" circulado em vermelho. Sem color blending e transparecias ficaria quadrado igual no chão riscado em azul, pois não tem nada mascarando.

Visualizar anexo 386953

 

[Jefferson Praxedes]

 

[Jefferson Praxedes]

Eu sinceramente fico estupefato diante da complexidade e dos estudos e pesquisas feitos do Mario 64 , esse jogo literalmente é um grande marco da cultura dos video games, toda vez que eu vejo esses vídeos dissecando suas mecânicas como de universo paralelo, velocidade do Mario que ele cria durante horas, videos de pegar estrela sem pular , pressionar o A pela metade XD, e agora o cara consegue fazer essa mega produção de mais de 3:40 hrs (Maior que o filme do Titanic) falando e explicando o porque das paredes invisíveis no jogo.

Quanto mais eu vejo isso mais eu entendo o quão matematicamente e fisicamente complexo foi programar esse jogo.

A Nintendo mostrou pro mundo como fazer um game em 3D de verdade, eu considero ele um dos games mais importantes da história.

Sou feliz pois tive o prazer de ver o salto de 2D pra 3D no calor do momento! O qual essa geração de agora nunca mais vai ter esse mérito na vida, a não ser que a tecnologia avance para quarta dimensão um dia.

Bônus:

https://www.adrenaline.com.br/games/jogar-super-mario-64-estimula-a-massa-cinzenta-do-hipocampo-no-cerebro-de-adultos-mostra-estudo/

 

[ELTORO]

Caiu na net:

 

[Warrior Of Light]

Bom vídeo. Para complementar outro vídeo dizendo como burlar todas essas limitações no N64.



Pena não ter algum vídeo sobre como burlar as limitações do PS1, mas talvez eu faça uma postagem relacionada a isso.

Eu sinceramente fico estupefato diante da complexidade e dos estudos e pesquisas feitos do Mario 64 , esse jogo literalmente é um grande marco da cultura dos video games, toda vez que eu vejo esses vídeos dissecando suas mecânicas como de universo paralelo, velocidade do Mario que ele cria durante horas, videos de pegar estrela sem pular , pressionar o A pela metade XD, e agora o cara consegue fazer essa mega produção de mais de 3:40 hrs (Maior que o filme do Titanic) falando e explicando o porque das paredes invisíveis no jogo.

Outro vídeo sobre as paredes invisíveis em Mario 64 para complementar, explicado de forma resumida.

Caiu na net:

Esse jogo é impressionante, até usa micro-código, F3DEX-2 (o mesmo que foi muito usado pela RARE).

Algumas coisas me chamaram atenção nesse jogo, primeiramente os menus, são muito bem detalhados e nítidos. Esse menu da tela de título usa incríveis 184 texturas, algumas delas de 16 bits RGBA (transparentes) e todas elas possuem tamanho de 9x9 pixels. Usaram muitas texturas pequenas para dar todo esse detalhamento, tanto que parece um desenho feito a mão.



No menu de pausa usaram 41 texturas de vários tamanhos, incluindo texturas de 16 bits RGBA (transparentes), com tamanho de 32x64 pixels.




O jogo tem resolução interna de 320x240 e faz upscaling pra 640x480.

Roda com 1.142 polígonos por frame em 30 FPS (34.260 polígonos por segundo). Não é o tipo de jogo que usa muitos polígonos, mas foca muito mais em texturas, pois apela muito nesse quesito, focando no uso de muitas texturas de variados tamanhos.




Tex rects mostrado acima não é o numero de texturas em tela, mas o comando que carrega as texturas para a tela, ou seja, usaram 40 comandos de display de texturas nessa parte. No entanto, essa parte tem 109 texturas diferentes, de várias bitagens (4, 8 e 16 bits) e tamanhos (até 64x64 pixels, que é o máximo permitido).



O uso da CPU fica em torno de 85-92% e o RCP fica entre 7-15%. Não é um jogo que usa muito o RCP, pois não tem alta geometria, sendo mais focado no level design do que na "explosão de polígonos", tendo em vista que esse micro-código permite geometria altíssima.

Outros pontos são os tiros, que deixam as marcas onde acertam, a movimentação suave do personagem (com muitas similaridades com Tomb Raider), texturas que simulam bumb-mapping e outros detalhes como partículas e outros itens animados no cenário (como folhas). Tinha potencial pra ser um grande jogo.

 

[ELTORO]

Bom vídeo. Para complementar outro vídeo dizendo como burlar todas essas limitações no N64.



Pena não ter algum vídeo sobre como burlar as limitações do PS1, mas talvez eu faça uma postagem relacionada a isso.



Outro vídeo sobre as paredes invisíveis em Mario 64 para complementar, explicado de forma resumida.





Esse jogo é impressionante, até usa micro-código, F3DEX-2 (o mesmo que foi muito usado pela RARE).

Algumas coisas me chamaram atenção nesse jogo, primeiramente os menus, são muito bem detalhados e nítidos. Esse menu da tela de título usa incríveis 184 texturas, algumas delas de 16 bits RGBA (transparentes) e todas elas possuem tamanho de 9x9 pixels. Usaram muitas texturas pequenas para dar todo esse detalhamento, tanto que parece um desenho feito a mão.

Visualizar anexo 389685Visualizar anexo 389687

No menu de pausa usaram 41 texturas de vários tamanhos, incluindo texturas de 16 bits RGBA (transparentes), com tamanho de 32x64 pixels.

Visualizar anexo 389686Visualizar anexo 389688


O jogo tem resolução interna de 320x240 e faz upscaling pra 640x480.

Roda com 1.142 polígonos por frame em 30 FPS (34.260 polígonos por segundo). Não é o tipo de jogo que usa muitos polígonos, mas foca muito mais em texturas, pois apela muito nesse quesito, focando no uso de muitas texturas de variados tamanhos.


Visualizar anexo 389690

Tex rects mostrado acima não é o numero de texturas em tela, mas o comando que carrega as texturas para a tela, ou seja, usaram 40 comandos de display de texturas nessa parte. No entanto, essa parte tem 109 texturas diferentes, de várias bitagens (4, 8 e 16 bits) e tamanhos (até 64x64 pixels, que é o máximo permitido).

Visualizar anexo 389695

O uso da CPU fica em torno de 85-92% e o RCP fica entre 7-15%. Não é um jogo que usa muito o RCP, pois não tem alta geometria, sendo mais focado no level design do que na "explosão de polígonos", tendo em vista que esse micro-código permite geometria altíssima.

Outros pontos são os tiros, que deixam as marcas onde acertam, a movimentação suave do personagem (com muitas similaridades com Tomb Raider), texturas que simulam bumb-mapping e outros detalhes como partículas e outros itens animados no cenário (como folhas). Tinha potencial pra ser um grande jogo.

Rapaz...
Depois do seu post vou ser obrigado a jogar isso !

Uma pena que foi cancelado, parece que seria jogão com gráficos bem avançados.

Uma coisa, será que o framerate é estável em 30FPS ou tem quedas?
Se for é algo incomum, porque lembro que jogos mais pesados de TPS tipo Jet Force Gemini tinham muitas quedas de frame.