Retro Games [Tópico Oficial]

[Nash]

Nessa época de leitores super lentos, acho que até o local onde os arquivos estavam no disco fazia diferença.
Aliás, duplicação de arquivo para leitura ainda é normal. Algo que deve sumir agora com o SSDs. Será que era má otimização mesmo ou tinha razões técnicas?

Agora alguém de fato esperava uma intervenção divina na conversão?
Claro que isso é fruto de muita compressão de arquivo e isso compromete bastante a qualidade deles. A
própria versão de PS1 já tem bastante compressão, tem uma versão japonesa de RE3 para PC com os arquivos descomprimidos que é fácil ver a diferença.

Se não me engano, até li algo sobre terem que desenvolver novos tipos de compressão de vídeo na época, pois os que o N64 suportava não eram suficientes. Então com certeza não foi algo fácil de fazer.

[Z80a]

O único ponto que ele tá errado é na parte do codec de video.
Pra chegar aos 64MB que chegou, eles tiveram que usar compressão MPEG pro video que nada com 100MHz consegue aguentar muito bem.
O truque foi usar o poderoso co-processador do N64 pra fazer todas as tarefas de multiplicação (e são MUITAS), e isso é um inferno de fazer porque o co-processador é muito mal documentado até hoje.
Foi quase um "o poder do Cell" aqui.

Mas no resto ele tá certo.

[AvcF]

Além do título click-bait ("Uma mentira..."), o autor errou em algumas coisas no artigo. Se me permitem o auto-merchan, eu fiz um vídeo sobre essa versão:

https://youtu.be/yD8gl7upJcY

Eu estou a vontade pra falar sobre esse tema porque eu pesquisei a fonte primária, no caso um artigo escrito por Todd Maynink, engenheiro de software da Angel Studios, em que ele explicou todo o processo que ele desenvolveu para a conversão dos filmes do PS1 pro N64 à revista Game Developer Magazine de setembro de 2000. Foi um artigo técnico, vejam só a primeira página:



O primeiro erro do Switch Brasil aí, é o cara se baseia na versão PSN pra dizer que o jogo tem 750MB, quando o próprio Maynink, que trabalhou diretamente na conversão afirma "1.2GB of data". O segundo ponto é que a grande dificuldade não era tanto o jogo em si, mas as cutscenes, e aí vem o segundo erro do artigo:

Mas é bem verdade que, mesmo que estejamos olhando para um valor final em torno dos 450 MB (sendo generoso), ainda seria grande feito reduzir esse número para 64 MB. Quando analisamos melhor, mudamos um pouco de opinião.

"O trabalho para transferir estes vídeos não foi muito extraordinário.", então novamente citando o Maynink:

"The original rendered frames of the video sequences were 320x160 pixels of 24-bit color = 153,600 bytes/frame. On the Nintendo 64 Resident Evil 2's aproximately 15 minutes of 30HZ video make a grand total of 15x60x30x153,600 = 4,147,200,000 of uncompressed data. Our budget on the cartridge was 25,165,824 bytes, so I had to achieve a compression ratio of 165:1. Worse still, I had to share this modicum of cartridge real estate data with the movie audio."

Molezinha, né? Isso porque dos 64MB disponíveis no cartucho, apenas 24MB estavam disponíveis para os filmes (com o audio). Resumindo a parada, o cara teve que desenvolver todas as ferramentas na mão, usando vários esquemas com o RCP, etc Enfim, foi um tão "banal" que só foi o primeiro caso da indústria de reprodução de video de alta qualidade em um console de cartucho.

Pra quem tiver interesse, postei o PDF da Game Developer Magazine:

https://we.tl/t-A4HLg1hdDN

[Posseidon]

Além do título click-bait ("Uma mentira..."), o autor errou em algumas coisas no artigo. Se me permitem o auto-merchan, eu fiz um vídeo sobre essa versão:

https://youtu.be/yD8gl7upJcY

Eu estou a vontade pra falar sobre esse tema porque eu pesquisei a fonte primária, no caso um artigo escrito por Todd Maynink, engenheiro de software da Angel Studios, em que ele explicou todo o processo que ele desenvolveu para a conversão dos filmes do PS1 pro N64 à revista Game Developer Magazine de setembro de 2000. Foi um artigo técnico, vejam só a primeira página:



O primeiro erro do Switch Brasil aí, é o cara se baseia na versão PSN pra dizer que o jogo tem 750MB, quando o próprio Maynink, que trabalhou diretamente na conversão afirma "1.2GB of data". O segundo ponto é que a grande dificuldade não era tanto o jogo em si, mas as cutscenes, e aí vem o segundo erro do artigo:

Mas é bem verdade que, mesmo que estejamos olhando para um valor final em torno dos 450 MB (sendo generoso), ainda seria grande feito reduzir esse número para 64 MB. Quando analisamos melhor, mudamos um pouco de opinião.

"O trabalho para transferir estes vídeos não foi muito extraordinário.", então novamente citando o Maynink:

"The original rendered frames of the video sequences were 320x160 pixels of 24-bit color = 153,600 bytes/frame. On the Nintendo 64 Resident Evil 2's aproximately 15 minutes of 30HZ video make a grand total of 15x60x30x153,600 = 4,147,200,000 of uncompressed data. Our budget on the cartridge was 25,165,824 bytes, so I had to achieve a compression ratio of 165:1. Worse still, I had to share this modicum of cartridge real estate data with the movie audio."

Molezinha, né? Isso porque dos 64MB disponíveis no cartucho, apenas 24MB estavam disponíveis para os filmes (com o audio). Resumindo a parada, o cara teve que desenvolver todas as ferramentas na mão, usando vários esquemas com o RCP, etc Enfim, foi um tão "banal" que só foi o primeiro caso da indústria de reprodução de video de alta qualidade em um console de cartucho.

Pra quem tiver interesse, postei o PDF da Game Developer Magazine:

https://we.tl/t-A4HLg1hdDN

Posta isso lá. Quero ver as tretas conversas.

[Z80a]

Não foi tão dificil assim, foi só programar um programa de 8KB que faz uma rotação 64D de forma eficiente num DSP com documentação rala e nenhuma forma de debugar o andamento do programa (isso é, sua unica pista que o programa estava certo é se ele estava rodando ou não rodando :3, nada de "porque esta errado?").
E alem disso só outras coisas simples como motion vectors, i-frames, conversão de RGB pra YIQ, compressão de arvore huffman, e seu programinha de MPEG ainda tem que tocar som junto que é responsabilidade da RSP que você esta usando pra fazer o decode.

É coisinha simples de meia hora.

[AvcF]

Javascript is not enabled OR refresh the page to view

Click here to view the Tweet

[Nash]

Bom vídeo e tem alguns developers do N64 nos comentários, o que também é interessante.

[Z80a]

Bom vídeo e tem alguns developers do N64 nos comentários, o que também é interessante.

Tem uns errões cagados no video, tipo aquele negocio de "ter que copiar a textura do cartucho porque é mais rápido", né não.
E também ele fala o frame rate errado pro WDC (é 30 FPS, não 60) e esquece de explicar que o que deixa o jogo rápido é não usar o Z-Buffer e que o programa Z-Sort é só pra deixar os gráficos corretos sem o Z-Buffer.

[AvcF]

Javascript is not enabled OR refresh the page to view

Click here to view the Tweet

[AvcF]

Javascript is not enabled OR refresh the page to view

Click here to view the Tweet

[Kadaj]

[kyoscaum]

Isso daqui é pro Z80a e vocês discutirem, já que já tinham conversado a um tempo:

https://switch-brasil.com/o-milagre-de-r...-ate-hoje/

que texto

[Titan]

Cara, que trailer sensacional
Wishlistado para jogar com meu irmão

abraços e paz™

[Wander]

Ana Conda

[Kadaj]

Ana Conda            

O John Sawyer tb é legal: "He's been a man... since he was a boy."

[Donovan]

Jogo foda. Joguei um pouco no switch. Esperando um preço bom pra pegar no PC.
Só tem na epic por enquanto.

[Rodrigo Rey]

Zuerinho esse jogo hein

[INXS]

Não foi tão dificil assim, foi só programar um programa de 8KB que faz uma rotação 64D de forma eficiente num DSP com documentação rala e nenhuma forma de debugar o andamento do programa (isso é, sua unica pista que o programa estava certo é se ele estava rodando ou não rodando :3, nada de "porque esta errado?").
E alem disso só outras coisas simples como motion vectors, i-frames, conversão de RGB pra YIQ, compressão de arvore huffman, e seu programinha de MPEG ainda tem que tocar som junto que é responsabilidade da RSP que você esta usando pra fazer o decode.

É coisinha simples de meia hora.

Z80a, a pergunta é meio viagem, mas é uma curiosidade: O Gamecube tem uma arquitetura baseada no Power PC, assim como o Xbox 360, certo?

Se sim, em teoria, se fosse da mesma fabricante (no caso a Nintendo), o Xbox 360 poderia ser retro-compativel com o GameCube?

[Z80a]

Z80a, a pergunta é meio viagem, mas é uma curiosidade: O Gamecube tem uma arquitetura baseada no Power PC, assim como o Xbox 360, certo?

Se sim, em teoria, se fosse da mesma fabricante (no caso a Nintendo), o Xbox 360 poderia ser retro-compativel com o GameCube?

Teria que escrever uma especie de emulador, porque os endereços de memoria das coisas são completamente diferentes, a GPU trabalha de forma completamente diferente, e eu suspeito que se você só pegar a CPU do 360, setar pra 485 Mhz e tentar rodar o código do gamecube, o código vai rodar mais lento por causa das capadas que o cell deu e a microsoft copiou :3
Mas seria mais facil do que fazer pra um x86 porque as instruções pelo menos são as mesmas.

[Undying]

Peguei por 27 reais na eShop Argentina