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

[Sega&AMD]

vejo que ficou bom no N64 (afinal era jogo dele) não vejo como não poderia ficar muito bom em algum console intermediário entre N64 e GC, um Dreamcast talvez fizesse um versão decente desse jogo.



Acho um salto similar porém levemente maior ao do shadowman porém, cada um desses jogos acima foi construído para o console, o shadow man do DC cultivava o código do n64



Numa hipotética versão DC teríamos maior resolução e melhores texturas porém ainda se pareceria com a versão Dinossaur planet numa versão PS2 hipotética poderia ter quase ou toda experiência starfox adventures salvo algum recurso gráfico excusivo do hardware do cube.

 

[Jefferson Praxedes]

 

[Warrior Of Light]

O primeiro chefe de Dinosaur Planet (Scales's Galleon) tem 1.426 polígonos e 4.278 vértices.



Todas as partes do chefe que se movimentam são feitas a parte, mas na hora da renderização todas são agrupadas.



Abaixo a contagem.



More will come... HOHOHOHO!!!

 

[Warrior Of Light]

 

[Warrior Of Light]

As partículas que fazem a chuva e neve são feitas por muitos polígonos, visível no modo wireframes, você também pode conferir a porcentagem de uso do processador (r4300i), chip gráfico (GFX) e frame-rate (DL/s).



Ao ripar a geometria podemos ver os polígonos que fazem a neve.



Fox tem 905 polígonos e 2.715 vértices, Tricky tem 458 polígonos e 1.374 vértices, a planta tem 74 polígonos e 222 vértices.




Mas o que eu quero ripar mesmo é esse T-Rex enorme, devido a seu tamanho e ótima modelagem deve ser o recordista de polígonos dentre os chefes vistos nos consoles da época disparadamente.

 

[Jefferson Praxedes]

 

[Warrior Of Light]

Como mostrado anteriormente o jogo não tem descarte polígonal, aqui mais uma tela mostrando que o tudo o que está por detrás da parede tbm é processado, dá pra ver a sala de teleporte atrás do muro.



Outra coisa impressionante, tudo no jogo é feito com polígonos, árvores, partículas, placas, cercas e até as folhas que caem das arvores, elas tbm estão sempre se movendo, não são polígonos estáticos. Nada está no mesmo nível disso, a cada análise uma proeza da RARE é mostrada.

A cerca possui 39 polígonos e 117 vértices e a árvore 325 polígonos e 975 vértices. Não estou contabilizando as folhas que caem, chegando a mais de 100 polígonos somente das folhas quando você bate na árvore.



Muitas árvores podem ser vistas simultaneamente, assim como muitos objetos, é uma explosão de polígonos em tela.



O Pterodáctilo (CloudRunner) tem 278 polígonos e 834 vértices, abaixo ele e as partículas da chuva.

 

[Jefferson Praxedes]

Eu sou fan do Goldeneye mas esse game merece uma atenção também , a EUROCON fez um bom trabalho !

 

[rickrj]

Caraca hein, parabens pelos posts, altíssimo nível !!!!!!!

 

[Warrior Of Light]

Caraca hein, parabens pelos posts, altíssimo nível !!!!!!!

Obrigado amigo!!!

Isso aqui tá dando um trabalho, principalmente ripar a geometria do Dinosaur Planet, eu não sabia que tinham tantos users que curtem a Sega ou Sony acompanhando, o pessoal costuma pregar uma rivalidade que já acabou faz tempo, eu tbm já fui hater no passado hahaha, hoje eu não ligo mais pra esse negócio de defender empresa, só gosto dos jogos dela e faço as análises, eu prefiro muito mais que users assim acompanhem as postagens, do que alguns Nintendistas egocêntricos que não interagem com nada (eu tbm não faço questão).

O que eu vejo com isso é que todo lado tem pessoas boas e ruins (isso não tem nada a ver com gostar de uma determinada marca), e que a comunidade retro é a melhor de todas, continue por aqui, pois é bem vindo (assim como todos os outros users que vêm acompanhando e aprovando o nosso esforço), só está meio complicado gerar conteúdo pra 3 tópicos agora.

 

[Axel Stone]

Infelizmente não corrigiu as informações falsas de números de polígonos nas comparações com o PS1, que inclusive está na primeira página e várias outras páginas depois, mesmo mostrando o erro. Uma pena, pois pode levar pessoas à acreditar em algo falso.

 

[Warrior Of Light]

Infelizmente não corrigiu as informações falsas de números de polígonos nas comparações com o PS1, que inclusive está na primeira página e várias outras páginas depois, mesmo mostrando o erro. Uma pena, pois pode levar pessoas à acreditar em algo falso.

Olha cara, eu não sei o que acontece com você, ao invés de mandar uma MP pra conversarmos sobre o assunto prefere vir aqui pra causar, parece muita inveja da sua parte, na sua cabeça você está certo e que sua palavra é a verdade, eu andei conversando com alguns programadores e conferindo algumas ripagens deles, inclusive o Itália64 (Conker64) que ripa polígonos a mais de uma década, e só me confirmaram o que eu já havia dito antes.

Você disse que ripou os cenários do PS1 (Resident Evil 2) com algoritmo de profundidade, mas isso não procede, a complexidade é tanta que nem os caras que estão no cenário ripando modelos nos 4 cantos do mundo ainda fizeram, pois isso iria levar alguns LONGOS meses, tanto que em nenhum site de modelos 3D tem os cenários ripados (como o Model Resource), ainda não existe plugin que permite extrair os modelos em forma de triangulos, se ripar diretamente da ISO obterá os dados com profundidade, mas terá que fazer manualmente convertendo os modelos em algum formato (WRL, OBJ, DAE, ETC) em que eles mostrem todos os triangulos e não apareçam em forma de quads, o que pouco importa no fim das contas, pois o Blender não conta quads, 1 quad pro Blender são 2 triangulos, não importando se a imagem esteja mostrando quads ou triangulos.

E como eu disse anteriormente as ripagens dos modelos de Resident Evil 2 do PS1 são referentes aos modelos processados em 1 frame, internamente o modelo no PS1 tem mais polígonos, mais frames, porém, na hora de renderizar a GPU descarta os mesmos, diminuindo o número de polígonos REAIS, ou seja, a sua ripagem mostra como são os modelos dentro da ISO (isso se voce realmente ripou os cenários em "algumas semanas"), não como eles são renderizados na tela, isso é o que interessa, o número em tempo real de polígonos sendo processados, como a infomação é enviada para a tela, não o que está internamente. Eu ainda te disse que sua ripagem não estava errada, mas não era o que acontecia no momento da renderização, voce não tinha compreendido isso, se voltar 2 páginas atrás vera os 2 modelos do Leon no PS1 e N64 lado a lado (de uma captura feita diretamente dos consoles), dá pra ver claramente que os modelos no PS1 tem geometria menor, tirando os filtros de correção do N64 que deixam os modelos mais limpos.



Não basta saber ripar modelos 3D, tem que entender o funcionamento dos hardwares também, como os periféricos funcionam internamente e como a renderização acontece, isso ajuda a não se confundir e sair tirando conclusões precipitadas, passar bem.

 

[Axel Stone]

Olha cara, eu não sei o que acontece com você, ao invés de mandar uma MP pra conversarmos sobre o assunto prefere vir aqui pra causar, parece muita inveja da sua parte, na sua cabeça você está certo e que sua palavra é a verdade, eu andei conversando com alguns programadores e conferindo algumas ripagens deles, inclusive o Itália64 (Conker64) que ripa polígonos a mais de uma década, e só me confirmaram o que eu já havia dito antes.

Você disse que ripou os cenários do PS1 (Resident Evil 2) com algoritmo de profundidade, mas isso não procede, a complexidade é tanta que nem os caras que estão no cenário ripando modelos nos 4 cantos do mundo ainda fizeram, pois isso iria levar alguns LONGOS meses, tanto que em nenhum site de modelos 3D tem os cenários ripados (como o Model Resource), ainda não existe plugin que permite extrair os modelos em forma de triangulos, se ripar diretamente da ISO obterá os dados com profundidade, mas terá que fazer manualmente convertendo os modelos em algum formato (WRL, OBJ, DAE, ETC) em que eles mostrem todos os triangulos e não apareçam em forma de quads, o que pouco importa no fim das contas, pois o Blender não conta quads, 1 quad pro Blender são 2 triangulos, não importando se a imagem esteja mostrando quads ou triangulos.

E como eu disse anteriormente as ripagens dos modelos de Resident Evil 2 do PS1 são referentes aos modelos processados em 1 frame, internamente o modelo no PS1 tem mais polígonos, mais frames, porém, na hora de renderizar a GPU descarta os mesmos, diminuindo o número de polígonos REAIS, ou seja, a sua ripagem mostra como são os modelos dentro da ISO (isso se voce realmente ripou os cenários em "algumas semanas"), não como eles são renderizados na tela, isso é o que interessa, o número em tempo real de polígonos sendo processados, como a infomação é enviada para a tela, não o que está internamente. Eu ainda te disse que sua ripagem não estava errada, mas não era o que acontecia no momento da renderização, voce não tinha compreendido isso, se voltar 2 páginas atrás vera os 2 modelos do Leon no PS1 e N64 lado a lado (de uma captura feita diretamente dos consoles), dá pra ver claramente que os modelos no PS1 tem geometria menor, tirando os filtros de correção do N64 que deixam os modelos mais limpos.

Visualizar anexo 176541

Não basta saber ripar modelos 3D, tem que entender o funcionamento dos hardwares também, como os periféricos funcionam internamente e como a renderização acontece, isso ajuda a não se confundir e sair tirando conclusões precipitadas, passar bem.

Ah não com essa conversa de novo não. Eu já mostrei, repeti, provei mais de uma vez.

Me falaram que não era má fé e se estivesse errado iriam corrigir os posts. Infelizmente não é isso que aconteceu.

 

[Warrior Of Light]

Ah não com essa conversa de novo não. Eu já mostrei, repeti, provei mais de uma vez.

Me falaram que não era má fé e se estivesse errado iriam corrigir os posts. Infelizmente não é isso que aconteceu.

Mas não tem nada pra ser corrigido, voce pode postar 10.000 imagens e ficar repetindo isso eternamente se quiser, não prova absolutamente nada, continua fazendo de conta que não entendeu (ou realmente não conseguiu entender) o procedimento de como a renderização da imagem no PS1 funciona, quando a imagem é enviada para a tela tem descarte poligonal, mesmo com um programador falando a respeito disso, além da captura direta estar bem escancarada mostrando tudo, o importante é como funciona na prática, não dentro de uma ISO.

Tem que entender da parte técnica, não basta ripar um modelo, eu te aconselho a baixar alguns PDF's sobre o hardware do PS1, conversar com alguns programadores, baixar alguns Debug's e aprender suas funções para assim começar a compreender o seu funcionamento, antes eram 3 te contra-argumentando, agora são 4 palavras contra a sua (inclusive 1 programador), algumas páginas atrás eu errei, quando falei sobre o SCUMMVM, mas já admiti meu erro, eu não tenho problemas quanto a isso, mas você não aceita ser corrigido, quando se fala no funcionamento do hardware você fica perdido, não entende, e sem opcões volta a falar do modelo de uma ISO (que perde geometria na renderização), pois não entende do restante do assunto.

Nada mais precisa ser dito, não vou te dar mais audiência, pelo bom funcinamento do tópico e em consideração aos users que tem acompanhado.

 

[Axel Stone]

Mas não tem nada pra ser corrigido, voce pode postar 10.000 imagens e ficar repetindo isso eternamente se quiser, não prova absolutamente nada, continua fazendo de conta que não entendeu (ou realmente não conseguiu entender) o procedimento de como a renderização da imagem no PS1 funciona, quando a imagem é enviada para a tela tem descarte poligonal, mesmo com um programador falando a respeito disso, além da captura direta estar bem escancarada mostrando tudo, o importante é como funciona na prática, não dentro de uma ISO.

Tem que entender da parte técnica, não basta ripar um modelo, eu te aconselho a baixar alguns PDF's sobre o hardware do PS1, conversar com alguns programadores, baixar alguns Debug's e aprender suas funções para assim começar a compreender o seu funcionamento, antes eram 3 te contra-argumentando, agora são 4 palavras contra a sua (inclusive 1 programador), algumas páginas atrás eu errei, quando falei sobre o SCUMMVM, mas já admiti meu erro, eu não tenho problemas quanto a isso, mas você não aceita ser corrigido, quando se fala no funcionamento do hardware você fica perdido, não entende, e sem opcões volta a falar do modelo de uma ISO (que perde geometria na renderização), pois não entende do restante do assunto.

Nada mais precisa ser dito, não vou te dar mais audiência, pelo bom funcinamento do tópico e em consideração aos users que tem acompanhado.

Você compara emuladores. Pior, no PS1 o emulador a captura não tem eixo Z e não tem como ver o modelo em 3D, os polígonos atrás do modelo se perde. Até mesmo contagem poligonal de um emulador para o outro diferencia.

Fiz o rip direto do arquivo. Mesma quantidade de polígonos. Não foi suficiente.
Mostrei o wireframe do framebuffer e claramente dá pra ver a mesma quantidade de polígonos. Não foi suficiente.
Fiz o rip do emulador combinando 3 frames para obter o eixo Z. E parece que não foi suficiente.
Citei um dev do MAME e parece que não foi suficiente.

Ou seja, nada que prove o que você acha que é nunca será suficiente.

Mas fato é fato. E que a quantidade poligonal mostrada dos jogos de ps1, incluíndo a primeira página está errada é fato.

 

[Warrior Of Light]

Você compara emuladores. Pior, no PS1 o emulador a captura não tem eixo Z e não tem como ver o modelo em 3D, os polígonos atrás do modelo se perde. Até mesmo contagem poligonal de um emulador para o outro diferencia.

Fiz o rip direto do arquivo. Mesma quantidade de polígonos. Não foi suficiente.
Mostrei o wireframe do framebuffer e claramente dá pra ver a mesma quantidade de polígonos. Não foi suficiente.
Fiz o rip do emulador combinando 3 frames para obter o eixo Z. E parece que não foi suficiente.
Citei um dev do MAME e parece que não foi suficiente.

Ou seja, nada que prove o que você acha que é nunca será suficiente.

Mas fato é fato. E que a quantidade poligonal mostrada dos jogos de ps1, incluíndo a primeira página está errada é fato.

"Fiz o rip direto do arquivo. Mesma quantidade de polígonos. Não foi suficiente."

1) Pode ripar diramente do arquivo quantas vezes quiser, o modelo do arquivo não tem a mesma geometria do modelo renderizado em tempo real. Realmente não é o suficiente.

"Mostrei o wireframe do framebuffer e claramente dá pra ver a mesma quantidade de polígonos. Não foi suficiente."

2) Mostrou o wireframe do frame-buffer dentro do Maya, de um modelo ripado da ISO, não de um modelo processado em tempo real no PS1, onde tem descarte poligonal e você ignora, algo que já foi explicado e na imagem da captura direta dá pra ver claramente que o modelo tem menos geometria, logo está trocado 6 por meia dúzia. Realmente não foi o suficiente.

"Fiz o rip do emulador combinando 3 frames para obter o eixo Z. E parece que não foi suficiente."

3) Está trocando 6 por meia dúzia novamente, PS1 não tem Z-Buffer e nenhum plugin é capaz de interpretar as imagens com eixo Z, além disso, não existe nenhuma ferramenta que adiciona eixo Z numa imagem sendo processada de dentro da memória do PS1 processando o jogo em real time, somente se for ripando diretamente da ISO onde os dados são fixos e depois adicionando o eixo Z com script dentro do Software de modelagem, isso é uma mentira sem tamanho, e ainda tem a cara de pau de falar que ripou os cenários em "algumas semanas", algo que nem os ripadores de polígonos espalhados mundo afora não fizeram, na verdade, eles demoram MESES pra ripar 1 modelo com eixo Z diretamente da ISO, se considerarmos o cenário todo o tempo estimado é muito maior devido a complexidade, tanto que nem se tem os cenários ripados no Models Resource. Realmente, parece não ser o suficiente.



"Citei um dev do MAME e parece que não foi suficiente."

4) De nada adiantou, eu citei um programador que ripa modelos a uma década, que faz demos para o N64 e PS1, que testa o hardware de ambos a tempos, ou seja, tem muito mais propriedade e bagagem pra falar. Realmente, parece não ser o suficiente.

Não apresentou nada que prove até agora, fato não é seu ponto de vista, para ser fato tem que entender sobre o hardware, não apenas ripar um modelo, sua ripagem não está errada, mas você não sabe como o PS1 renderiza uma imagem, então pra você o mesmo modelo da ISO é o mesmo modelo que está sendo processado na tela, quanto a isso não tem mais o que dizer, é algo que você não rebateu e evitou tocar, somente negou.

 

[Axel Stone]

"Fiz o rip direto do arquivo. Mesma quantidade de polígonos. Não foi suficiente."

1) Pode ripar diramente do arquivo quantas vezes quiser, o modelo do arquivo não tem a mesma geometria do modelo renderizado em tempo real. Realmente não é o suficiente.

"Mostrei o wireframe do framebuffer e claramente dá pra ver a mesma quantidade de polígonos. Não foi suficiente."

2) Mostrou o wireframe do frame-buffer dentro do Maya, de um modelo ripado da ISO, não de um modelo processado em tempo real no PS1, onde tem descarte poligonal e você ignora, algo que já foi explicado e na imagem da captura direta dá pra ver claramente que o modelo tem menos geometria, logo está trocado 6 por meia dúzia. Realmente não foi o suficiente.

"Fiz o rip do emulador combinando 3 frames para obter o eixo Z. E parece que não foi suficiente."

3) Está trocando 6 por meia dúzia novamente, PS1 não tem Z-Buffer e nenhum plugin é capaz de interpretar as imagens com eixo Z, além disso, não existe nenhuma ferramenta que adiciona eixo Z numa imagem sendo processada de dentro da memória do PS1, somente se for ripando diretamente da ISO e depois adicionando o eixo Z com script dentro do Software de modelagem, isso é uma mentira sem tamanho, e ainda tem a cara de pau de falar que ripou os cenários em "algumas semanas", algo que nem os ripadores de polígonos espalhados mundo afora não fizeram, na verdade, eles demoram MESES pra ripar 1 modelo com eixo Z diretamente da ISO, se considerarmos o cenário todo o tempo estimado é muito maior devido a complexidade, tanto que nem se tem os cenários ripados no Models Resource. Realmente parece não ser o suficiente.



"Citei um dev do MAME e parece que não foi suficiente."

4) De nada adiantou, eu citei um programador que ripa modelos a uma década, que faz demos para o N64 e PS1, que testa o hardware de ambos a tempos, ou seja, tem muito mais propriedade e bagagem pra falar. Realmente parece não ser o suficiente.

Não apresentou nada que prove até agora, fato não é seu ponto de vista, para ser fato tem que entender sobre o hardware, não apenas ripar um modelo, sua ripagem não está errada, mas você não sabe como o PS1 renderiza uma imagem, então pra você o mesmo modelo da ISO é o mesmo modelo que está sendo processado na tela, quanto a isso não tem mais o que dizer, é algo que você não rebateu, só negou.

Falou, falou e confirmou o que eu já falei. PS1 não tem Z-buffer, o rip é uma imagem plana. Comparar modelos poligonais de uma imagem plana, que não mostra polígonos na parte de trás, com imagem 3D é totalmente errado.

Refutando o restante. Sim o modelo ripado é o mesmo ingame, o que é óbvio, e facilmente compravado por wireframes. O que leva a outro erro falado, o modelo wireframe é do próprio buffer do emulador em tempo real.

Falar por exemplo que o modelo do Leon no N64 tem quase 3x a quantidade de polígonos do PS1, é uma tremenda desinformação. Pior, teve a audácia de falar que um modelo no N64 tem a mesma quantidade poligonal de toda a cena com inimigos no PS1. Qualquer um pode ver que isso não é verdade, nem sei porque eu tivo o trabalho de ripar e ainda refazer a cena toda o que deu o maior trabalho por algo tão óbvio que é visto à olho nu.

E querer saber mais que dev de emulador, minha nossa.

 

[Warrior Of Light]

Falou, falou e confirmou o que eu já falei. PS1 não tem Z-buffer, o rip é uma imagem plana. Comparar modelos poligonais de uma imagem plana, que não mostra polígonos na parte de trás, com imagem 3D é totalmente errado.

Refutando o restante. Sim o modelo ripado é o mesmo ingame, o que é óbvio, e facilmente compravado por wireframes. O que leva a outro erro falado, o modelo wireframe é do próprio buffer do emulador em tempo real.

Falar por exemplo que o modelo do Leon no N64 tem quase 3x a quantidade de polígonos do PS1, é uma tremenda desinformação. Pior, teve a audácia de falar que um modelo no N64 tem a mesma quantidade poligonal de toda a cena com inimigos no PS1. Qualquer um pode ver que isso não é verdade, nem sei porque eu tivo o trabalho de ripar e ainda refazer a cena toda o que deu o maior trabalho por algo tão óbvio que é visto à olho nu.

E querer saber mais que dev de emulador, minha nossa.

Desde o princípio eu falei que o PS1 não tinha Z-Buffer, o que interessa é que o Blender não conta quad, não importando se a imagem é plana ou não. Ele contabiliza todos os quads como triângulos.

Sobre o modelo, eu não falei em momento algum que o modelo ripado é diferente do modelo in-game, eu falei que o modelo na ISO possui uma geometria e na renderização outra, pois a GPU descarta polígonos no momento da renderização, a palavra de um programador que faz demos e vive testando tanto o PS1 como o N64 tem mais propriedade do que qualquer outra coisa.

E sobre a cena do PS1 com pouca geometria comparada ao modelo do Leon no N64, eu fiz questão de pegar uma parte com pouquíssimos polígonos para comparar, onde o cenário é completamente vazio e com apenas 1 inimigo andando, o zumbi é bem low-poly e o cenário pré-renderizado, não tem quase nada de polígonos, inclusive todas as ripagens do RE2 de PS1 que eu usei são do programador, mas se isso irrita não é minha culpa.

Você perdeu seu tempo ripando modelo mesmo, pois não consegui rebater nada.

 

[Axel Stone]

Desde o princípio eu falei que o PS1 não tinha Z-Buffer, o que interessa é que o Blender não conta quad, não importando se a imagem é plana ou não. Ele contabiliza todos os quads como triângulos.

Sobre o modelo, eu não falei em momento algum que o modelo ripado é diferente do modelo in-game, eu falei que o modelo na ISO possui uma geometria e na renderização outra, pois a GPU descarta polígonos no momento da renderização, a palavra de um programador que faz demos e vive testando tanto o PS1 como o N64 tem mais propriedade do que qualquer outra coisa.

E sobre a cena do PS1 com pouca geometria comparada ao modelo do Leon no N64, eu fiz questão de pegar uma parte com pouquíssimos polígonos para comparar, onde o cenário é completamente vazio e com apenas 1 inimigo andando, o zumbi é bem low-poly e o cenário pré-renderizado, não tem quase nada de polígonos, inclusive todas as ripagens do RE2 de PS1 que eu usei são do programador, mas se isso irrita não é minha culpa.

Você perdeu seu tempo ripando modelo mesmo, pois não consegui rebater nada.

Quem não está conseguindo rebater é você. Não tem como comparar um rip 2D sem a coordenada Z com um rip 3D. Não dá. É óbvio que a contagem será errada.

É algo tão óbvio que no olho daria pra ver.

Você não admite estar errado, esse é o problema. Errar faz parte, altere os dados errados do PS1 e bola pra frente, pois o tópico tem ótimas informações do N64.

 

[Warrior Of Light]

Quem não está conseguindo rebater é você. Não tem como comparar um rip 2D sem a coordenada Z com um rip 3D. Não dá. É óbvio que a contagem será errada.

É algo tão óbvio que no olho daria pra ver.

Você não admite estar errado, esse é o problema. Errar faz parte, altere os dados errados do PS1 e bola pra frente, pois o tópico tem ótimas informações do N64.

Sim, errar faz parte, se você realmente tivesse me convencido do contrário eu voltaria atrás com a palavra, o Blender risca todos os quads na hora da contabilizar a geometria de uma ripagem 2D, transformando tudo que é quad em polígonos, inclusive eu já errei aqui em falar que o SCUMMVM rodava pelo DOS e voltei atrás sem nenhum problema, obrigado pelo elogio sobre o tópico.

E desculpe se fui ofensivo, mas está dando trabalho demais pra gerar este conteúdo, a paciência já esta curta por causa disso, você poderia ter me mandando MP pra falarmos sobre o assunto, pois esse tipo de discussão tumultua demais. Eu tbm sou daqueles que implica pra passar a informação de forma verídica, ainda mais quando quem me ensinou a ripar modelos foi um cara que tenho muita consideração e um dos que mais entende desses consoles atualmente, ele tem testado o hardware do N64 e PS1 de diversas formas, já fez muitos testes e demos, como os 1900 sprites do Mario, scrolling de tiles com 8 backgrounds, background do Last Blade 2, Symphony of the Night, etc.

 

[Warrior Of Light]

Testes feitos no Nintendo 64 - Itália64/Conker64 (libdragon)

TESTE 1: EXPLOSÕES
Explosões aleatórias na tela usando texturas de 16bits (32x32) com RDP.



Desempenho sem otimizações:
410 a 60fps (NTSC)
507 a 50fps (PAL)

TESTE 2: EXPLOSÕES
MAIORES Em vez de explosões de 2 KB, elas são em torno de 122x96 (22 KB), então elas são divididas em várias partes para caber no cache de 4 KB (eu não uso a função stride no libdragon, é mais lento do que gerenciar texturas únicas), eu me pergunto se há é uma maneira fácil de usar texturas de 4 ou 8 bits com libdragon (elas são limitadas a 16 bits a 32 bits).



CONTROLES
A - Aumentar
B - Diminuir
Início -
Z mínimo -
C máximo - limpar buffer com RDP (teste 1,2)
C esquerdo - limpar buffer com CPU (teste 1,2)
C baixo - não limpar (teste 1,2 )
R - Retângulos de cor (teste 3)


BAIXAR
https://mega.nz/#!R9YEwBSD!_7jzjJd0UXLLDIgvKNxVt0pwtKhSdyJ46QhFRMG7EWA

TESTE 3:
Retângulos SNOW RDP (não texturizados) de 4x4 com uma cor azul.



Desempenho:
5120 retângulos a 60 fps
6430 retângulos a 50 fps

TESTE
Uma tabela de cores é escrita no buffer, o mouse lê a cor do buffer e a mostra no retângulo.



CONTROLES
Joystick - Mouse
A - Definir a cor de fundo com a cor selecionada
R - Alternar fontes de letras brancas ou pretas
Z - Redefinir cores de fundo e letras

BAIXAR
https://mega.nz/#!g5IRgYwA!Mk-vrgPmAi0HhN5aPKPLNDNVnbtdgxFkGXTkmGBmZcg

LAST BLADE 2
Background com efeitos de distorção, número de frames, frame-rate, etc.



Uma GIF com melhor qualidade.



Como ainda não tenho efeitos raster (buffer), tive que usar texturas horizontais gigantes (320x4), para que eu possa mover os blocos separadamente.

- Libdragon não permite texturas além de 256 de largura, elas são repetidas neste ponto ou espelhadas dependendo das configurações.

O efeito é gerado em tempo real (em vez de tabelas) e pode ser editado:
C esquerda / C direita = onda
C acima / C abaixo = raio
A / B = Velocidade
R = ocultar texto

BAIXAR
https://mega.nz/#!UpIBkJBb!TqZc9F3V8lZS ... 9zsYVEpews

IRIDION 3D

Mais pessoas interessadas na cena N64 podem ser ótimas

, o principal problema com o áudio é a falta de threads no libdragon e a falta de suporte RSP (para mixagem rápida de áudio ao invés da CPU), eu acho que essas coisas poderiam ser implementadas com o tempo.

Fiz um exemplo do recurso de inversão, replicando um pouco o efeito do Iridion 3D (GBA) que de fato usa uma pequena parte da tela, então os tiles são espelhados.



O GBA usa uma pequena área e rola, então tive que definir 256x240 com bordas pretas.



Os sprites são conjuntos de 172x8 carregados apenas uma vez no TMEM para serem espelhados, parece que demora um pouco para carregar, são 480 arquivos e cerca de 1,30 MB para a animação completa (texturas de 16 bits ainda), posso encontrar um método para acelerar até isso.

O exemplo é parecido com este.



BAIXAR
https://mega.nz/#!NowTCZiR!zjdeRzSzBwgw ... fheN_Z8p1Q

SYMPHONY OF THE NIGHT

Pontos de controle:
Esta função traz um centro virtual para as coordenadas X / Y mais suporte para sprites de junção múltipla, sprites espelhados são alinhados, as texturas escaladas tentarão se alinhar igualmente, mas agora há um pequeno problema com a precisão.

As texturas na libdragon são alinhadas em 0,0, imagem à esquerda, no centro a animação usando coords personalizados para os eixos X / Y, a imagem direita mostra o número de retângulos, às vezes eles podem caber TMEM (32x64) ou dividir em partes

Exemplo de programa:



CONTROLES
A - Espelho horizontalmente
B - Espelho verticalmente
Z - Atrasa a animação 1 segundo
L - Interrompe a animação por um momento
C para cima / baixo - Escala Y
Dpad - Joysticks - Move o ponteiro de referência

BAIXAR
https://mega.nz/#!s0ATnZga!IdDcgNhDe8j1 ... FXlAFuXN_A

 

[Warrior Of Light]

EXPLOSÕES COM TRANSPARÊNCIA

Outras coisas que eu adoraria adicionar, pelo menos eu quero que o RDP as desenhe:

• Mistura Alfa para texturas
• Mistura Alfa para cores (para fade on / fade off da tela ou outros efeitos)
• Sprites Rotativos
• Corrigir Sprite RDP Scale X
• Raster effects X / Y (estilo Mega Drive)
• Additive Blending (faça a mistura de cores com a CPU e depois desenhe com RDP se não for suportado), já fiz um teste de pc, mas tenho que portar o código.

TILEMAPS NO NINTENDO 64

Fiz upload de um pequeno beta do "Sprite64", mas ele precisa de alguns testes de bet, vou explicar um pouco todos os recursos.

Entrada: pasta png (solte todos os pngs aqui, irá ignorar qualquer outro arquivo ou subpasta)
Saída: pasta sprite ( texturas sprite N64 )

INCLUIR CÓDIGO
Se habilitada a ferramenta irá gerar arrays de todos os dados gerados.

INCLUIR PNG
Faça uma réplica PNG das texturas convertidas também, além de outros recursos.

ZLIB
As texturas compactadas terão extensão .zsprite em vez de .sprite, ele precisa do zlib no N64 , não tenho certeza se consigo encontrar um já portado.

GRUPO / SEPARADO
Grupo: Tudo na mesma pasta, as texturas serão nomeadas em ordem, começando de 0 em sprites e 1 em tilemaps (0 está vazio).
Separado: Cada conversão png tem sua própria pasta (útil quando muitos sprites)

OPTIMIZE
A ferramenta usará o tamanho TMEM certo com base na preferência de desempenho, um exemplo:

Limites Libdragon:

• Tamanho horizontal: as texturas têm que ser pares, a ferramenta corrige tamanhos desiguais adicionando espaço vazio.
• Tamanho vertical: as texturas podem ser de qualquer um destes tamanhos: 4,8,16,32,64,128,256
• Tamanho máximo: 256 largura ou altura

OPTIMIZE L / R
Com base nas texturas otimizadas geradas, a ferramenta tentará encontrar qualquer área vazia para o melhor resultado.

Optimize L: Optimize da esquerda, isso pode causar problemas de alinhamento, mas eu fiz uma solução alternativa no libdragon.
Optimize R: Optimize da direita, nenhum problema encontrado.

Melhorias:
Textura original de 68x69: 18,3 KB (32 bits)
Conversão de textura (68x72, 9 etapas * 8 altura): 19,1 KB
Otimizar R: 14,8 KB
Otimizar L + R: 11,2 KB
Zlib: 1,60 KB

* Otimizar funciona diferentemente no modo de 16 bits.

RGB
tornará transparente a entrada de cor para todos os arquivos PNG, também suporta canal alfa transparente.

PNG PARA TILEMAP
Irá converter um png em um mapa de blocos enquanto converte os blocos em texturas N64 .

Se include png estiver habilitado irá gerar:

• Uma cópia do mapa completo
• Uma cópia de todos os tiles
• Um tileset de todos os tiles gerados

Se o código de inclusão estiver habilitado irá gerar:
- Diferentes matrizes do tilemap como arquivos .c (código .c)

CUSTOM
Permite um tamanho customizado válido, mesmo que seja além de 4KB TMEM, caso desejemos usar renderização de software.

CHECK TILE
Irá verificar se o tile é repetido espelhando e gerando flags.c se algum for encontrado. Conjunto de tilemaps.

Exemplo de tile SMB.

De 8x8 (mas queremos texturas maiores no N64 para melhor desempenho)

Conjunto de tiles de 16x16, menos correspondência de bloco, mas melhor desempenho.

Exemplo Golden Axe II.

Conjunto de blocos de 16x16, blocos espelhados deduzidos.

• blocos que são completamente transparentes serão deduzidos.
• Se verificar bloco e incluir código estiverem desabilitados, todos os blocos do mapa serão gerados. (já que não conhecemos a matriz)

PNG PARA SPRITE
A segunda etapa da ferramenta é o visualizador de animador e o editor de CP.

O GIF é um pouco autoexplicativo.

Tick é o atraso da animação.
O modo de exibição fornece uma referência fantasma para um alinhamento mais rápido.
Rect mostra todos os retângulos e o número de texturas geradas para aquele png concreto.
BG muda o fundo, então podemos testar se um sprite tem "pixels transparentes escondidos" dentro.

Controles:
F1 - Normal tamanho da janela
F2 - tamanho duplo
Esquerda / Direita - Anim esquerda ou direita
Cima / Baixo (mouse wheelup / wheeldown) - Zoom
teclas numéricas - Entrada
mouse para qualquer outra coisa

BAIXAR

File on MEGA

mega.nz

TESTES DE SCROLLING
Então fiz alguns testes com rolagem de tiles.

Usei o mesmo mapa SMB que tenho mostrado (blocos de 16 x 16 para preencher uma tela de 320 x 240, em vez de 256 x 240), tex de 16 bits, com os seguintes resultados:

• 132 fps
• 172 fps (última verificação de textura)
• 273 fps (remover o céu azul texturizar e substituí-la por um retângulo de preenchimento de tela inteira)
• 318 fps (desativar texturas de liberação )

Ao olhar os resultados, parece que a verificação de textura básica melhora o desempenho, mas isso dependerá muito do mapa, o preenchimento é bonito rápido, uma estratégia de textura melhor pode aumentar o fps.


BAIXAR
https://mega.nz/#!84AU1TwJ!jkMuXQgISfD3 ... yxkmXVFk_E

Para este segundo mapa, usei texturas de 64x32 ou 32x64, 7 camadas de rolagem com velocidade relativa, 16 bits tex.



BAIXAR
https://mega.nz/#!g0BWnTbA!TgkCuPlWfxNH ... WUdi9I2yhU


MAIS TESTES DE SCROLLING
Testando algum tipo de otimização de rolagem (Symphony of the Night).

Este mapa é um bom exemplo, tem 6 camadas de rolagem, mas principalmente cobertas pela camada principal:



Desempenho:

• 90fps (rolagem principal - blocos de 16x16)
• 116fps (blocos de 64x32)

Cada bloco verifica uma lista binária para descartar os blocos cobertos (isso pode ser muito lento, não tenho certeza se poderia ser mais rápido gerar listas de cada camada e, em seguida, verificá-los em 1 etapa ou verificar cada bloco válido).



Desempenho:

• 159 fps (principal rolagem - blocos de 32x32)
• 178fps (blocos de 64x32)

Se blocos de 64x32 forem usados, isso é menos eficaz, mas ainda mais rápido na maioria das áreas de rolagem (algumas outras são mais lentas), então isso oscila entre 178 e 130 no pior caso.



Esses mapas parecem carregar mais rápido se houver menos arquivos para carregar, mesmo se eles pesarem mais em tamanho (16x16 306 KB vs 64x32 536 KB).

CONTROLES

• Joystick
• Z para desativar a camada principal

BAIXAR
https://mega.nz/#!t4RSQCpT!gEQYQ_SJGDnq ... WrDE8DRDJQ

Adicionada lista de exibição para rolagem de desenho em ordem de textura, usa qsort (A função qsort() é uma função em C utilizada para ordenação de arrays).



Teste:

• 104fps (blocos de 16x16)
• 169fps (com ordem de textura )

BAIXAR
https://mega.nz/#!R9R2RAQC!vLy-XwgGz6lR ... nRSJCzG2y0

ALPHA BLENDING TEST
Pequeno teste que mostra 32 níveis de transparência no modo 1 ciclo (modo 16 bits / RDP).



CONTROLES
A - Flip Sprite
Z - Habilitar / Desabilitar mistura de aditivos
L / R - Controle Alfa
Joy -
Botões de rolagem C - Escala X / Y (zoom)

BAIXAR
https://mega.nz/#!g4ZlELCY!1Wbgx4wzpJal ... yY9zFcOHvY

TEXTURAS DE 4/8 BIT ADICIONADAS
A implementação ainda não foi concluída, eu segui os exemplos ASM de Krom para fazê-lo, por alguma razão trabalhando junto com libdragon ele falha em mostrar qualquer textura acima de 1 KB (2 KB no máximo, os próximos 2 KB são para TLUT), então eu não posso fazer 64x64 Texturas de 4 bits (2 pixels de bytes) ou 64x32 texturas de 8 bits ainda, mas estou trabalhando para consertá-las.

Fiz apenas o lado RDP, essas texturas não serão compatíveis com o software de renderização do libdragon (graphics.c).

TESTE 1: EDITOR DA PALETA
Este teste usa um sprite de 4 bits (1 ciclo, 2x dimensionado), você pode escolher uma cor e substituir qualquer cor da paleta (botão A).



Ao pressionar L inicia uma rotação automática da paleta, você pode interrompê-la a qualquer momento com R.



Pressione Iniciar para a paleta padrão.

Tive problemas com invalidar cache neste teste concreto (a paleta não atualiza), o problema foi resolvido substituindo -O2 por -Os nas opções do compilador.

BAIXAR
https://mega.nz/#!l4JFxIiB!jTS5TAQl8-0b ... K0QbAGOKSw

TESTE 2: TESTE DE DESEMPENHO
Mesmo teste Golden Axe feito anteriormente, texturas de 4 bits 16x16, 1 paleta única, já que todo o mapa usa apenas 1 das 4 paletas de Mega Drive.



4 bits espelhado (com o alinhamento de otimização atual)
x = 0 - 166 fps
x = 194 - 161 fps
x = 974 - 143 fps
x = 1552 - 169 fps

16 bits espelhado (mesmo alinhamento)
x = 0 - 161 fps
x = 194 - 156 fps
x = 974 - 138 fps
x = 1552 - 163fps

No geral parece ser uma pequena melhoria quando todos os tiles usam a mesma paleta, poderia ser bastante interessante verificar este mapa com tiles 64x64.

BAIXAR
https://mega.nz/#!5x4zAYrT!6xAwSK76h8Ga ... pHDGAumUSc


More will come...

 

[Jefferson Praxedes]

Potencial 2D no N64 foi pouco explorado mesmo, poderia ter muitos portes de jogos de luta entre outros





Os melhores exemplos pra mim seria o Mischief Makers e o Yoshis Story

 

[T-Rexz]

Vi a animação de explosão do GoldenEye 007... e aproveitando pra perguntar uma coisa bem curiosa:
Porque as várias fumaças formadas, após vários tiros do lançador de granadas, quando passa no meio delas, o jogo fica "lento" (que é quando cai qps), daí ao sair da fumaça, o jogo normaliza. Poderia explicar isso para gente??

 

[Jefferson Praxedes]

Vi a animação de explosão do GoldenEye 007... e aproveitando pra perguntar uma coisa bem curiosa:
Porque as várias fumaças formadas, após vários tiros do lançador de granadas, quando passa no meio delas, o jogo fica "lento" (que é quando cai qps), daí ao sair da fumaça, o jogo normaliza. Poderia explicar isso para gente??

Então o desenvolvimento do Goldeneye começou antes mesmo do N64 sair em produção, ou seja eles tiveram que criar o game sem as specificações do hardware apenas com os devkits que tinham mais memoria que o console original, ou seja quando saiu o console para eles testarem eles tiveram que ir diminuindo o uso de memoria e a qualidade dos assets, outro fator é que o codigo não foi bem otimizado porque era a primeira vez que os caras faziam um jogo na vida e pegar o hardware do 64 logo de cara assim não deve ter sido fácil, , fizeram milagre, esse efeito de fumaça é o percursor da fumaça volumétrica, um efeito pesado ja no começo dos anos 2000 , inclusive eu lembro de uns games de PC ter a opção de desligar porque o FPS caia bastante mesmo.

Esse time do Goldeneye não era tão bom em otimizar o microcodigo como os outros da Rare, por isso Perfect Dark precisa do Expansor para jogar a campanha single player

Conforme os desenvolvedores adicionavam mais recursos, o jogo acabou usando toda a memória extra nos consoles de depuração. Como resultado, o jogo ficou grande demais para caber nos 4 MB de memória de acesso aleatório (RAM) do Nintendo 64. Os desenvolvedores logo perceberam que não eram capazes de otimizá-lo e decidiram fazer uso do Nintendo 64 Expansion Pak, que aumenta a RAM do Nintendo 64 de 4 MB para 8 MB de memória principal contígua, para suportar a maioria dos recursos do jogo. Depois de jogar a versão de lançamento do jogo, Hollis ficou impressionado com a ampla gama de opções multiplayer, que ele descreveu como "uma vasta gama de recursos que eu nunca planejei". Doak, no entanto, observou que "GoldenEye praticamente exauriu o desempenho da máquina. Era difícil levá-la adiante.

 

[Jefferson Praxedes]

GoldenEye 007 obtém um aumento de desempenho com o novo mod Tournament Edition



Desenvolvido por Wreck no N64 Vault, este novo mod foi projetado para otimizar o desempenho do GoldenEye 007.

Existem duas versões, ambas totalmente gratuitas para download. E eles até funcionam em um console N64 original.

O que GoldenEye 007 Tournament Edition faz?

GoldenEye 007 Tournament Edition apresenta uma série de otimizações destinadas a reduzir a lentidão. Embora o mod afete todo o jogo, ele foi criado principalmente com o modo multijogador em mente.

Essas melhorias só são possíveis fazendo concessões em outras áreas. Especificamente, reduzindo a quantidade de coisas que o jogo precisa renderizar na tela a qualquer momento.

Mas o efeito indireto é realmente mínimo, graças ao Wreck ter adotado algumas abordagens muito inteligentes.

Por exemplo, o jogo agora só desenha as partes visíveis da arma quando você as possui. Não é uma mudança perceptível - a menos que você empunhe duas armas.

Mesmo assim, isso afeta apenas o modo single-player, já que a dupla empunhadura não é possível no multiplayer.

O GoldenEye 007 original usa dois modelos para a maioria dos personagens: uma versão de baixo e alto polígono. Qual você vê depende de quão perto você está do personagem. Também varia de acordo com o personagem.


Isso ajuda no desempenho, mas o Wreck deu um passo adiante. Agora, a distância em que os modelos de polígonos baixos são renderizados é muito menor para todos os personagens.

E muito parecido com a otimização de armas, é quase imperceptível durante toda a ação - pelo menos em um console N64.

Colisões de balas e efeitos de explosão também foram reduzidos. Em particular, as explosões liberam metade da quantidade de fumaça que antes.

Com ou sem música?
GoldenEye 007 Tournament Edition vem em duas versões. Ambos são idênticos, exceto que um deles não tem música.

Não se sabe se realmente melhora o desempenho, mas dá ao N64 menos para processar. Portanto, você pode querer considerar isso apenas no caso.

Afinal, outros jogos N64, como Mario Kart 64, adotam essa abordagem no modo multijogador pelo mesmo motivo.

É uma experiência mais tranquila? Vamos testar!

Usando os códigos do GameShark para monitorar a taxa de quadros, consegui comparar o desempenho do GoldenEye 007 Tournament Edition com o do jogo original.

Não parece ser a maneira mais precisa de medir isso, mas ainda dá uma boa indicação.

Abaixo, incluí o que descobri nos modos de jogador único e multijogador. Observe que o jogo exibe a taxa de quadros em hertz, como você pode ver nas imagens.

Teste de jogador único
A missão Dam do GoldenEye 007 parecia a escolha ideal para testes. Possui uma boa combinação de grandes áreas abertas e seções estreitas e fechadas.

Tanto o jogo original quanto a edição de torneio conseguiram, muito ocasionalmente, atingir 30 quadros por segundo (FPS).

Original Edição de Torneio
Geralmente, ambas as versões rodavam a 15 FPS, mas o jogo original cai com mais frequência para 12 FPS. Mesmo assim, não há realmente muito nele.

A taxa de quadros mais baixa registrada (excluindo cutscenes) foi de 10 FPS para GoldenEye 007 e 12 FPS para Tournament Edition.

Teste de dois jogadores
Para este teste, escolhi o mapa Bunker. Ele só suporta até três jogadores e por isso é um dos mapas mais exigentes.

Eu também optei por Power Weapons, já que disparar vários RCP-90s é uma receita para desaceleração.

Original Edição de Torneio
Curiosamente, este teste forneceu resultados semelhantes ao experimento de um jogador. O jogo alcançou 30 FPS muito raramente, e na maioria das vezes ficou em torno da marca de 15 a 20 FPS.

No entanto, o jogo original caiu com mais frequência para 12 FPS durante o combate. Além disso, o Tournament Edition caiu para apenas 10 FPS em seu nível mais baixo, enquanto o original caiu para 6 FPS em um ponto.

Teste de quatro jogadores
Qual a melhor maneira de fazer o teste de estresse do que colocar quatro jogadores no mapa do Templo relativamente aberto com lançadores de foguetes?

A descoberta mais chocante aqui foi que o Tournament Edition conseguiu cair para 5 FPS, enquanto o original só caiu para 6 FPS. Mas, como você pode ver nas imagens comparativas, há muito mais coisas acontecendo na tela no Tournament Edition.

Original Edição de Torneio
Ambas as versões atingem um máximo de 20 FPS com quatro jogadores. O jogo geralmente fica em torno de 15 FPS quando os jogadores estão em áreas separadas, mas cai para 12 FPS se todos os personagens puderem ver uns aos outros.

No entanto, as melhorias do Tournament Edition não têm muito impacto no combate. Em ambos, a taxa de quadros era normalmente de 6 a 8 FPS durante a ação aquecida.

Resumo do teste
GoldenEye 007 Tournament Edition não é um mod de mudança de jogo. Mas geralmente você pode esperar uma experiência um pouco mais suave com ele.

Wreck listou outras otimizações potenciais que gostariam de fazer. Dado o que já foi alcançado, é possível que possamos ver um contraste muito maior entre as duas versões no futuro.

O GoldenEye 007 Tournament Edition possui outros recursos?
O mod também inclui muitas melhorias de qualidade de vida.

Felizmente, todos os mapas multijogador são desbloqueados desde o início e suportam até quatro jogadores.

Existem também mais personagens para escolher e os jogadores podem até optar por jogar como a mesma pessoa. Algumas delas são, na verdade, opções alternativas de fantasias para personagens existentes.

Wreck alterou os pontos de desova e ajustou o modo Flag Tag para atualizar o jogo para jogadores veteranos.

Uma das mudanças mais notáveis é a ausência de Oddjob.

De acordo com a regra há muito estabelecida, mas não escrita, escolhê-lo é trapaça. Portanto, só faz sentido que agora ele se foi.

Aparentemente, ainda é tecnicamente possível escolhê-lo - mas apenas sendo um trapaceiro sujo!

Como posso jogar GoldenEye 007 Tournament Edition?
Vá ao N64 Vault para baixar o patch GoldenEye 007 Tournament Edition.

Em seguida, você precisa aplicá-lo a uma ROM GoldenEye 007 (provavelmente uma versão NTSC) usando o Delta Patcher .

Para jogar em um console N64, você precisará de um flashcart como um EverDrive 64 . Também é possível jogar o mod em emuladores.

Esse mod já saiu faz tempo acho que se usar ele mais o patch que remove o Anti Aliasing da pra deixar mais fluido ainda

 

[T-Rexz]

GoldenEye 007 obtém um aumento de desempenho com o novo mod Tournament Edition



Desenvolvido por Wreck no N64 Vault, este novo mod foi projetado para otimizar o desempenho do GoldenEye 007.

Existem duas versões, ambas totalmente gratuitas para download. E eles até funcionam em um console N64 original.

O que GoldenEye 007 Tournament Edition faz?

GoldenEye 007 Tournament Edition apresenta uma série de otimizações destinadas a reduzir a lentidão. Embora o mod afete todo o jogo, ele foi criado principalmente com o modo multijogador em mente.

Essas melhorias só são possíveis fazendo concessões em outras áreas. Especificamente, reduzindo a quantidade de coisas que o jogo precisa renderizar na tela a qualquer momento.

Mas o efeito indireto é realmente mínimo, graças ao Wreck ter adotado algumas abordagens muito inteligentes.

Por exemplo, o jogo agora só desenha as partes visíveis da arma quando você as possui. Não é uma mudança perceptível - a menos que você empunhe duas armas.

Mesmo assim, isso afeta apenas o modo single-player, já que a dupla empunhadura não é possível no multiplayer.

O GoldenEye 007 original usa dois modelos para a maioria dos personagens: uma versão de baixo e alto polígono. Qual você vê depende de quão perto você está do personagem. Também varia de acordo com o personagem.


Isso ajuda no desempenho, mas o Wreck deu um passo adiante. Agora, a distância em que os modelos de polígonos baixos são renderizados é muito menor para todos os personagens.

E muito parecido com a otimização de armas, é quase imperceptível durante toda a ação - pelo menos em um console N64.

Colisões de balas e efeitos de explosão também foram reduzidos. Em particular, as explosões liberam metade da quantidade de fumaça que antes.

Com ou sem música?
GoldenEye 007 Tournament Edition vem em duas versões. Ambos são idênticos, exceto que um deles não tem música.

Não se sabe se realmente melhora o desempenho, mas dá ao N64 menos para processar. Portanto, você pode querer considerar isso apenas no caso.

Afinal, outros jogos N64, como Mario Kart 64, adotam essa abordagem no modo multijogador pelo mesmo motivo.

É uma experiência mais tranquila? Vamos testar!

Usando os códigos do GameShark para monitorar a taxa de quadros, consegui comparar o desempenho do GoldenEye 007 Tournament Edition com o do jogo original.

Não parece ser a maneira mais precisa de medir isso, mas ainda dá uma boa indicação.

Abaixo, incluí o que descobri nos modos de jogador único e multijogador. Observe que o jogo exibe a taxa de quadros em hertz, como você pode ver nas imagens.

Teste de jogador único
A missão Dam do GoldenEye 007 parecia a escolha ideal para testes. Possui uma boa combinação de grandes áreas abertas e seções estreitas e fechadas.

Tanto o jogo original quanto a edição de torneio conseguiram, muito ocasionalmente, atingir 30 quadros por segundo (FPS).

Original Edição de Torneio
Geralmente, ambas as versões rodavam a 15 FPS, mas o jogo original cai com mais frequência para 12 FPS. Mesmo assim, não há realmente muito nele.

A taxa de quadros mais baixa registrada (excluindo cutscenes) foi de 10 FPS para GoldenEye 007 e 12 FPS para Tournament Edition.

Teste de dois jogadores
Para este teste, escolhi o mapa Bunker. Ele só suporta até três jogadores e por isso é um dos mapas mais exigentes.

Eu também optei por Power Weapons, já que disparar vários RCP-90s é uma receita para desaceleração.

Original Edição de Torneio
Curiosamente, este teste forneceu resultados semelhantes ao experimento de um jogador. O jogo alcançou 30 FPS muito raramente, e na maioria das vezes ficou em torno da marca de 15 a 20 FPS.

No entanto, o jogo original caiu com mais frequência para 12 FPS durante o combate. Além disso, o Tournament Edition caiu para apenas 10 FPS em seu nível mais baixo, enquanto o original caiu para 6 FPS em um ponto.

Teste de quatro jogadores
Qual a melhor maneira de fazer o teste de estresse do que colocar quatro jogadores no mapa do Templo relativamente aberto com lançadores de foguetes?

A descoberta mais chocante aqui foi que o Tournament Edition conseguiu cair para 5 FPS, enquanto o original só caiu para 6 FPS. Mas, como você pode ver nas imagens comparativas, há muito mais coisas acontecendo na tela no Tournament Edition.

Original Edição de Torneio
Ambas as versões atingem um máximo de 20 FPS com quatro jogadores. O jogo geralmente fica em torno de 15 FPS quando os jogadores estão em áreas separadas, mas cai para 12 FPS se todos os personagens puderem ver uns aos outros.

No entanto, as melhorias do Tournament Edition não têm muito impacto no combate. Em ambos, a taxa de quadros era normalmente de 6 a 8 FPS durante a ação aquecida.

Resumo do teste
GoldenEye 007 Tournament Edition não é um mod de mudança de jogo. Mas geralmente você pode esperar uma experiência um pouco mais suave com ele.

Wreck listou outras otimizações potenciais que gostariam de fazer. Dado o que já foi alcançado, é possível que possamos ver um contraste muito maior entre as duas versões no futuro.

O GoldenEye 007 Tournament Edition possui outros recursos?
O mod também inclui muitas melhorias de qualidade de vida.

Felizmente, todos os mapas multijogador são desbloqueados desde o início e suportam até quatro jogadores.

Existem também mais personagens para escolher e os jogadores podem até optar por jogar como a mesma pessoa. Algumas delas são, na verdade, opções alternativas de fantasias para personagens existentes.

Wreck alterou os pontos de desova e ajustou o modo Flag Tag para atualizar o jogo para jogadores veteranos.

Uma das mudanças mais notáveis é a ausência de Oddjob.

De acordo com a regra há muito estabelecida, mas não escrita, escolhê-lo é trapaça. Portanto, só faz sentido que agora ele se foi.

Aparentemente, ainda é tecnicamente possível escolhê-lo - mas apenas sendo um trapaceiro sujo!

Como posso jogar GoldenEye 007 Tournament Edition?
Vá ao N64 Vault para baixar o patch GoldenEye 007 Tournament Edition.

Em seguida, você precisa aplicá-lo a uma ROM GoldenEye 007 (provavelmente uma versão NTSC) usando o Delta Patcher .

Para jogar em um console N64, você precisará de um flashcart como um EverDrive 64 . Também é possível jogar o mod em emuladores.

Esse mod já saiu faz tempo acho que se usar ele mais o patch que remove o Anti Aliasing da pra deixar mais fluido ainda

Interessante isso daí... mas tem como converter em um cartucho físico, tipo uma repro (existe pra N64)?? Pois prefiro jogar em um console, já que sinto melhor com o controle de N64.

 

[Jefferson Praxedes]

Interessante isso daí... mas tem como converter em um cartucho físico, tipo uma repro (existe pra N64)?? Pois prefiro jogar em um console, já que sinto melhor com o controle de N64.

No aliexpress se voce entrar em contanto com um vendedor e enviar a rom já patcheada talvez eles façam uma customizada com label para você, mas com quase o mesmo preço voce pega um everdrive de uma vez, eu te mando a rom prontinha por PM , ai podes até conferir o Dinossaur Planet e todos e outros games com melhorias no hardware original sem nada de emulação =D

 

[Warrior Of Light]

Na libdragon padrão, você pode renderizar triângulos 2D não sombreados, usando a cor de mistura.



Agora estou tentando fazer triângulos texturizados para girar sprites, vai funcionar quando eu atualizar os coeficientes de textura de acordo, estou planejando mais efeitos com triângulos.



Eu também consertei o modo de 32 bits , as texturas neste modo tiveram que ser definidas para 1 ciclo para serem exibidas com o RDP ou travamentos do sistema (eles funcionaram na renderização do software em exemplos do libdragon, mas isso é muito lento).

O modo de 32 bits suporta texturas de 4,8,16 e 32 bits.
O modo 16 bits suporta texturas de 4,8,16 e 32 bits também (eles são convertidos na hora). Esta é uma tela construída com texturas de 32 bits do modo 16x16 32 bits no cen64.



Modo de 16 bits com texturas de 32 bits, as cores são reduzidas conforme você pode ver faixas no céu.



TESTE DE DESEMPENHO
Este teste é mario scroll novamente com 3 configurações diferentes:

mesmo local
modo de 16 bits, 16x16 16bits textura de cópia = 333 fps
modo de 16 bits, 16x16 16bits textura de 1 ciclo = 266 fps
modo de 32 bits, 16x16 16bits textura de 1 ciclo = 211 fps

Textura de 1 ciclo diminui um pouco o slowdown, 32 bits O modo é muito lento também, talvez para alguns efeitos especiais ou introduções, mas eu ficaria no modo de 16 bits para 2D.

BAIXAR
https://mega.nz/#!5gIiAACS!V--UGTsV7FUL ... wxZF7xzuDA

Outras coisas a consertar:

• O buffer triplo não está funcionando, você obtém velocidade total em vez de sincronizar o vídeo
• AA desativado causa falhas em

60 Hz (PAL parece bom) - Corrige a velocidade de carregamento, carrega 1200 peças / arquivos de 512 bytes = 47 segundos

• As texturas de 4, 8 e 32 bits usam apenas metade do TMEM (esta é a principal prioridade)
• As cores da paleta são enviadas de uma maneira diferente, para fazer upload de 16 cores você deve enviar 64 (4 vezes mais)

• As texturas de 16 bits podem usar 4 KB de TMEM, surpreendentemente as texturas de 16 bits eram as únicas suportadas no RDP pela libdragon.
• Os problemas de paleta e textura estão relacionados ao TMEM.

Correção de textura Thx Espozo 32bit TMEM
Agora o 4KB de TMEM pode ser usado para texturas de 32 bits (32x32)

TESTE

Scroll de 32x32 tiles texturas de 32bit, 320x240x32bit, cada tile tem uma textura diferente.

Desempenho:
16x16 = 51-55fps
32x32 = 72-76fps

Nenhuma otimização foi possível além de desabilitar a limpeza do framebuffer, repetir texturas de 32 bits pode ser necessário para manter um bom desempenho.

O teste usa 300 tiles em vez de 1200, o que reduziu o tempo de carregamento para 3 ou 4 segundos.

BAIXAR
https://mega.nz/#!w1IFWD4A!k4F3BoVzp1vQ ... YDrw-acxPM

Correção do combinador de cores
Parece que retângulos e triângulos texturizados têm combinações de cores diferentes, alguns funcionam para retângulos enquanto os triângulos se parecem com isto:



Eu encontrei uma combinação compatível para retângulos e triângulos para cada efeito, agora os triângulos podem fazer mistura alfa, intensificar, etc.

Testes de desempenho (sem falhas em nenhum deles):

Mario scroll
On - 333fps
Off - 342fps

Goldenaxe scroll
On - 167fps
Off - 172fps

Fillrate test
On - 1280 16x32 sprites a 50fps
Off - 1320 a 50fps

EFEITOS DE FRAMEBUFFER ADICIONADOS
Existem vários jogos que usam diferentes efeitos de framebuffer, como Mario Kart 64 para a tela de fundo, embora fosse uma boa ideia ter algumas funções para permitir isso:

Esta função lê o buffer e gera texturas de 16 bits rapidamente, ela lê apenas os pixels necessários para construí-la.

Possui 3 modos de textura:
0 - Tela cheia em 1 textura de 32x32 (relação de respeito de qualquer resolução)
1 - Metade superior no tamanho máximo de textura (em torno de 64x32)
2 - Metade inferior

O exemplo de Mario Kart tem uma taxa de atualização muito lenta, eu poderia melhorar a função de selecionar uma taxa de atualização para aumentar o desempenho ao custo de salvar as texturas na memória, uma opção para selecionar uma área de concreto poderia ser ótima também.

Este é mais flexível e permite uma cópia de buffer 1: 1 de qualquer tamanho de textura compatível em qualquer posição da tela.

Uma vez que a textura é carregada no TMEM pode ser desenhada normalmente, qualquer efeito pode ser aplicado, neste exemplo uma linha de texturas são invertidas com escala azul para simular o reflexo de gelo ou água.



Miseteyaru, Kusanagi no kobushi wo!!!

 

[Jefferson Praxedes]

Agora o sonho de muitos de jogar o Mario 64 com os gráficos de render do material promocional do game já pode ser realizado:







Pow ficou melhor que o remake do Goldeneye XD

 

[T-Rexz]

Agora o sonho de muitos de jogar o Mario 64 com os gráficos de render do material promocional do game já pode ser realizado:







Pow ficou melhor que o remake do Goldeneye XD

Aquele remake que saiu pro Wii é bonito visualmente, mas cara... sinceramente, está mais para um outro jogo do que remake. Dps saiu para 360 e PS3 e, mesmo assim, continua outro jogo. Ainda prefiro o original que é muito bom!!!

 

[Jefferson Praxedes]

Baixem esse mod antes que a Nintendo ....

 

[Warrior Of Light]

Mais testes no Nintendo 64.

Eu fiz uma página github, não é um clone / fork do github libdragon original, ainda estou aprendendo como funciona, então este é apenas um teste, mas eu fiz upload de alguns arquivos entretanto.

Github:
https://github.com/conker64/libdragon

Os interessantes são rdp.c & rdp.h, há um exemplo de TLUT também, continuarei adicionando mais exemplos.

Nas ferramentas você pode encontrar uma atualização do Sprite 64.

Para 4 e 8 bits use PNG TO TILEMAP de no máximo 64x32x4bit ou 32x32x8 bits texturas, elas ainda não estão fixas e PNG TO SPRITE tentará atingir o tamanho máximo para cada sprite.

EXEMPLO DE INCÊNDIO ADICIONADO

Este exemplo apresenta alguns efeitos fornecidos pelas novas funções libdragon.

• Deformação S da área do framebuffer concreto
• Desfoque usando vários níveis alfa

CONTROLES
Segure Z - Para fazer o efeito de desfoque,
pressione A - Para gerar fogo (até 99, as variáveis de incêndio são compartilhadas com desfoque e recicladas quando maximizado)
Pressione Iniciar - Excluir fogo

BAIXAR (com fonte)
https://github.com/conker64/libdragon/t ... mples / fire


Trabalhando em mais truques do framebuffer, este precisa ser limpo antes do upload, já que o framebuffer é enviado como textura para manipulação, outros efeitos podem ser aplicados como flip reverso, redimensionamento ou máscara com cores invisíveis.

Outros efeitos que estou interessado em replicar (como ondas expansivas):

ADICIONADO DITHER
Outro presente na build de compilação do RDP.

Dither rgb aleatório aplicado na superfície do céu, pode ser útil para efeito de filme ou filtro Silent Hill.

Dither rgb aleatório + teste rdp_rgba_scale.

EM BREVE: Tutorial de como programar no Nintendo 64 pelo libdragon.

Kaizoku ou ni, ore wa naru!!!

 

[Jefferson Praxedes]

To gostando bastante desse mod do Mario aqui, tá uma lindeza , ainda mais sabendo que eles conseguiram as imagens originais das texturas kk, esses leak da Nintendo saiu muita coisa boa

A nintendo ainda tinha todos esses assets intactos me indago porque não lançaram um remake descente ao menos, já que o Mario é o icone mor da empresa

Aqui saiu um update dia 10 com algumas coisas a mais

 

[Warrior Of Light]

Libdragon é uma biblioteca para programação no N64 , porém é muito limitada, até o momento o sprite flip não era nem possível, então eu comecei a aprimorá-la / adicionando novos recursos.

Então fiz uma ferramenta para conversão de texturas e um mecanismo de ladrilho.

Estou mudando em breve para libn64, a lib de Marathon (autor do CEN64), estou trabalhando com Krom para portar a maioria dos recursos RDP para libn64, temos um rdp.c para todas as chamadas RDP internas e rdp_functions.c para funções mais amigáveis (estilo libdragon).

Krom está trabalhando na lib 3D que vai ser bem legal, agora toda a matemática é feita pela CPU e desenhada pelo RDP, uma vez que tudo seja portado e seu estável será movido para o RSP para mais velocidade.

Libn64 é muito rápido e tem suporte a threads.

Em relação à libdragon, fiz algumas correções.

CORREÇÃO DE PALETA
Uma paleta pode ser selecionada agora de 0 a 15 em texturas de 4 bits

SOLUÇÃO DE TEXTURA DE 4BIT
Texturas de 64x64x4bit podem ser usadas agora (2 KB completos), por alguma razão quando a textura ocupa 2 KB sobrescreve a área TLUT, e a textura não será exibida, no entanto, se definirmos a paleta 2 ou superior, os dados permanecerão intocados.

Fiz mais uma vez um teste de rolagem Goldenaxe, mas desta vez com texturas de 64x64x4bit.
x = 0 - 232 fps
x = 194 - 212 fps
x = 974 - 204 fps
x = 1552 - 222 fps

Eu acho que se todas as texturas compartilham a mesma paleta, isso poderia ser mais rápido do que uma textura de 64x32x16 bits, ambas são muito próximas em termos de atuação.

BAIXAR (teste 64x64)
https://mega.nz/#!ZkhVRb7K!UejX0KrNIPeK ... u5heYgGLDU


CASTLEVANIA: SOTN OST
Toda a trilha sonora convertida em ogg 44KHz / Estéreo / 128kbps usando libogg, 34 músicas, cabe em um cartucho de 64 MB, reproduz do início ao fim, pode pular músicas com o botão c.

Ele reduz a velocidade de 25fps para sincronizar com o áudio (não sei como usar threads), mas como o fundo estático não há problema algum.

BAIXAR
https://mega.nz/#!Y9pQjYgC!S3LojMylb3lQ-RWEpdtdVxzCJKy9Td1b9AHr7Sq370w

Fiz uma segunda versão do SOTN OST, caso tenham algum problema com as músicas travando.

BAIXAR
https://mega.nz/#!k9hGEDqS!CR53Lh-wb07- ... nxmr7k5kgE

NOTA: Todas as demos podem ser testadas nos emuladores CEN64/MESS ou no Hardware original.