Os jogos mais avançados do Super Nintendo [+Remake incrível do SUPER MARIO LAND][+Sonic no SNes]

[Ridge]

Acho o Mode 7 fascinante até hoje, fico bobo de ver os múltiplos uso do efeito, e as várias formas em que ele pode ser empregado, Nintendo fez muito bem em implementar essa função, foi uma sacada de mestre o SNES ter esse efeito gráfico.

 

[Proteus_]

Tava conversando com amigo meu e ele acha a parte dos movimentos de tela rapida de Sonic bem avançada, eu disse que basicamente é apenas avançar pixels, pra exemplificar programei do zero uma engine e mostrei a ele, basicamente esses movimentos de camera apenas incrementa e decrementa pixels, nada mais que apenas matemática básica de somar e diminuir, em teoria o processador do Nintendinho poderia fazer igual , com Sprites menores pois ele não pode fazer Sprites Grandes como o Mega ou SNes.

aqui a engine usei goemon como sets.


veja que Sonic segue basicamente isso, no video eu digo para ele pular 50 pixels, aí o jogo fica muito mais rápido, ou seja nada de mais, isso mostra que Sonic não tem nada de outro mundo e poderia ser replicado por processadores como o 6502 , imagina então pelo o SNes.

 

[Ridge]

Esses dois beatemups tem personagens gigantes na tela.

 

[Warrior Of Light]

Sobre o Project N (Orpheus), jogo de SNes que estava sendo produzido pela Watermelon, o Matthias Naggler disse que não tem nenhuma novidade e ainda espera lança-lo algum dia, ele adiou o desenvolvimento do Hiatus (seu jogo de RPG com rítimo musical), pois ele quem estava programando o jogo pra Watermelon.

"As you might have noticed, this page is pretty much dead since about seven years.
That's why I've disabled it completely earlier this year.
However, it has come to my attention that this might be considered disrespectful towards the good people who have contributed content to the filedump section of this page.
For this reason, I'm putting it back online and plan to keep it that way.

Apart from that, I've more or less retracted from online communication.

As far as Project N is concerned (the original reason for the extended hiatus), I do not have any news.
I still have hope that we can release it one day..."

realtime.at - Domain gecatcht

Ele que portou o Road Blasters pro SNes, tem talento, agora é esperar o dia em que a Watermelon lançar o Paprium, pra depois o jogo de SNes ter continuidade, e pelo jeito que ele disse não vai demorar pouca coisa.

 

[Proteus_]

Sobre o Project N (Orpheus), jogo de SNes que estava sendo produzido pela Watermelon, o Matthias Naggler disse que não tem nenhuma novidade e ainda espera lança-lo algum dia, ele adiou o desenvolvimento do Hiatus (seu jogo de RPG com rítimo musical), pois ele quem estava programando o jogo pra Watermelon.

"As you might have noticed, this page is pretty much dead since about seven years.
That's why I've disabled it completely earlier this year.
However, it has come to my attention that this might be considered disrespectful towards the good people who have contributed content to the filedump section of this page.
For this reason, I'm putting it back online and plan to keep it that way.

Apart from that, I've more or less retracted from online communication.

As far as Project N is concerned (the original reason for the extended hiatus), I do not have any news.
I still have hope that we can release it one day..."

realtime.at - Domain gecatcht

Ele que portou o Road Blasters pro SNes, tem talento, agora é esperar o dia em que a Watermelon lançar o Paprium, pra depois o jogo de SNes ter continuidade, e pelo jeito que ele disse não vai demorar pouca coisa.

Acho que se o próprio Paprium que é jogo do console preferido deles, eles meio que não tão preocupados com o tempo de desenvolvimento imagina então o jogo do SNes ..... espero que algum dia esse jogo saia pois parecia muito promissor.

 

[PocketCrocodile]

Acho que se o próprio Paprium que é jogo do console preferido deles, eles meio que não tão preocupados com o tempo de desenvolvimento imagina então o jogo do SNes ..... espero que algum dia esse jogo saia pois parecia muito promissor.

Eu msm nunca confiei de verdade num projeto de jogo de SNES feito por uma galera que idolatra a Sega

 

[Arlindo Orlando]

Tava conversando com amigo meu e ele acha a parte dos movimentos de tela rapida de Sonic bem avançada, eu disse que basicamente é apenas avançar pixels, pra exemplificar programei do zero uma engine e mostrei a ele, basicamente esses movimentos de camera apenas incrementa e decrementa pixels, nada mais que apenas matemática básica de somar e diminuir, em teoria o processador do Nintendinho poderia fazer igual , com Sprites menores pois ele não pode fazer Sprites Grandes como o Mega ou SNes.

aqui a engine usei goemon como sets.


veja que Sonic segue basicamente isso, no video eu digo para ele pular 50 pixels, aí o jogo fica muito mais rápido, ou seja nada de mais, isso mostra que Sonic não tem nada de outro mundo e poderia ser replicado por processadores como o 6502 , imagina então pelo o SNes.

Parabéns, cara! Ficou muito legal! Uma pequena dúvida: notei que o Goemon vai se aproximando do lado direito da tela, em vez de ficar centralizado. Vários outros jogos side-scrollers são assim, o que diminui o tempo de reação do jogador ao surgir um obstáculo. É muito complicado programar a tela para centralizar no seu boneco ou até mesmo deixá-lo mais à esquerda, para que haja mais espaço para o que está à frente do personagem?

 

[Proteus_]

Parabéns, cara! Ficou muito legal! Uma pequena dúvida: notei que o Goemon vai se aproximando do lado direito da tela, em vez de ficar centralizado. Vários outros jogos side-scrollers são assim, o que diminui o tempo de reação do jogador ao surgir um obstáculo. É muito complicado programar a tela para centralizar no seu boneco ou até mesmo deixá-lo mais à esquerda, para que haja mais espaço para o que está à frente do personagem?

Não é difícil é até bem simples, no caso é que eu criei um algoritmo para câmera só atualizar quando o personagem estiver em 75% do cenário ao andar pra frente e 25% do cenário ao andar pra trás ,

tipo assim.


No goemon que fiz, enquanto ele se mover dentro do quadrado imaginário ele pode se mover sem a câmera atualizar, no momento em que ele colidir com o quadro imaginário que seria quantos pixels eu teria estipulado pra ser a câmera, tipo pra frente seria 75% do cenário a câmera atualiza fazendo o cenário se mover em função da posição do personagem.

por exemplo programei um exemplo rápido de câmera com quadro imaginário menor , a câmera atualiza bem antes da câmera de Goemon , eu até fiz um esquema de paralax funcional.


Desculpe eu não postar direto do pc, é que meu Pc é ruim pra isso pois como o pc ta renderizando em tempo real, ele não consegue renderizar e capturar ao mesmo tempo sem dar lag, preciso comprar um melhor.....

 

[Warrior Of Light]

Estou retomando a hack de The Legend of Zelda: A Link to the Past do Randerson (Proteus) pra dar continuidade, as cores são cartunescas, na pegada de cores Cel Shading (como em Wind Waker por exemplo), além disso a hack vai ser com o código restaurado pra eliminar todos os slowdowns, e talvez outras melhorias com o decorrer do tempo.

 

[Arlindo Orlando]

Não é difícil é até bem simples, no caso é que eu criei um algoritmo para câmera só atualizar quando o personagem estiver em 75% do cenário ao andar pra frente e 25% do cenário ao andar pra trás ,

tipo assim.


No goemon que fiz, enquanto ele se mover dentro do quadrado imaginário ele pode se mover sem a câmera atualizar, no momento em que ele colidir com o quadro imaginário que seria quantos pixels eu teria estipulado pra ser a câmera, tipo pra frente seria 75% do cenário a câmera atualiza fazendo o cenário se mover em função da posição do personagem.

por exemplo programei um exemplo rápido de câmera com quadro imaginário menor , a câmera atualiza bem antes da câmera de Goemon , eu até fiz um esquema de paralax funcional.


Desculpe eu não postar direto do pc, é que meu Pc é ruim pra isso pois como o pc ta renderizando em tempo real, ele não consegue renderizar e capturar ao mesmo tempo sem dar lag, preciso comprar um melhor.....

Muito legal, cara! Obrigado pela demonstração! Se é algo simples, foi muita mancada de várias desenvolvedoras terem prejudicado a câmera de seus jogos. Uma pena! Sempre tem quem faça um trabalho meia-boca...

 

[Grave Uypo]

Bem além dos descritos e apesar dos pesares Doom para Snes tb acho impressionante, mesmo sendo uma versão fraca é de se louvar que ele rodou no snes com todas as fases e som naquela qualidade

eu achava também, até ver novamente esses dias como roda.
aquilo não é "rodar". injogavel. definitivamente fora do escopo do console.

 

[Warrior Of Light]

eu achava também, até ver novamente esses dias como roda.
aquilo não é "rodar". injogavel. definitivamente fora do escopo do console.

Realmente Doom não roda bem, pra algo satisfatório teriam que colocar no mínimo 2 chips Super FX-2 e uma ROM do tamanho de Star Ocean, 48mb com MMC (SDD-1) pra colocar texturas com qualidade melhor de 64x64pxls.

O problema seria o preço do cartucho, seria uma facada no rim, que tbm foi um dos motivos pra cancelarem o port do Comanche.

 

[Proteus_]

Estou retomando a hack de The Legend of Zelda: A Link to the Past do Randerson (Proteus) pra dar continuidade, as cores são cartunescas, na pegada de cores Cel Shading (como em Wind Waker por exemplo), além disso a hack vai ser com o código restaurado pra eliminar todos os slowdowns, e talvez outras melhorias com o decorrer do tempo.

Visualizar anexo 84130

Tenho certeza que fará um bom trabalho, já que não ando tendo muto tempo por causa da faculdade,trabalho e outros afazeres , além disso o pessoal no canal já pediram essa hacker diversas vezes, eu ainda pretendo terminar o King Of Dragons e Street Fight 2 World Warriors.

 

[Grave Uypo]

Realmente Doom não roda bem, pra algo satisfatório teriam que colocar no mínimo 2 chips Super FX-2 e uma ROM do tamanho de Star Ocean (96mb), pra colocar texturas com qualidade melhor de 64x64pxls.

O problema seria o preço do cartucho, seria uma facada no rim, que tbm foi um dos motivos pra cancelarem o port do Comanche.

pra mim só precisava melhorar o fps de 15 (com drops pra 1 digito) pra algo como 20 estavel. ja ficava jogavel. pra isso eu acho que poderia BAIXAR a resolucao das texturas, que está alta demais pra resolucao de renderização desse jogo no snes.
mesmo assim, na epoca era mto foda só de eu poder jogar doom em casa. eu nem notava que era tão pior q no pc :p mas roda pior que num 386 (framerate semalhante, mas o doom do 386 não é capado), e eu jogava no 486 dx2 66 da minha avó, que tinha otima performance. e depois no meu 486 dx4 100, que colava 35 fps o tempo inteiro no high detail full screen

(bonus pelo som pc-speaker!)

 

[Warrior Of Light]

pra mim só precisava melhorar o fps de 15 (com drops pra 1 digito) pra algo como 20 estavel. ja ficava jogavel. pra isso eu acho que poderia BAIXAR a resolucao das texturas, que está alta demais pra resolucao de renderização desse jogo no snes.
mesmo assim, na epoca era mto foda só de eu poder jogar doom em casa. eu nem notava que era tão pior q no pc :p roda pior que num 386

(bonus pelo som pc-speaker!)

Bom, se você não ligar muito para gráficos ok, pois se baixar a resolução das texturas de 32x32pxls para 16x16pxls para melhorar o fps seria como podar com um facão a qualidade gráfica, pois além de reduzir o número de detalhes que cada textura comportaria, ainda teriam que esticar todas elas (quadruplicando os pixels) pra preencherem as colunas de ray casting, no mínimo teriam que usar filtro bilinear pra borrar tudo pra mascarar a total perca de qualidade (como fizeram em Wolfestein 3d).

 

[NBT master]

Bem além dos descritos e apesar dos pesares Doom para Snes tb acho impressionante, mesmo sendo uma versão fraca é de se louvar que ele rodou no snes com todas as fases e som naquela qualidade

Gosto muito. Dentre as trilhas sonoras dos Doom clássicos, uma das melhores. MIDIs bons.

 

[ELTORO]

eu achava também, até ver novamente esses dias como roda.
aquilo não é "rodar". injogavel. definitivamente fora do escopo do console.

É fato que a versão de SNES não é boa propriamente falando...tipo,eu não ia parar de jogar a versão de PC ou N64 (que é diferente mas foda) pra jogar essa.

Agora o port em si é excelente, mesmo com SuperFX2 acho um absurdo o jogo rodar no SNES,explorou bastante o hardware do aparelho.

Sei que é cheat,mas acho que com overclock pelo menos fica jogável.


Enviado de meu Redmi 5 Plus usando o Tapatalk

 

[Warrior Of Light]

Ter falado texturas borradas me lembrou o N64 em seus jogos de primeira leva e seus jogos de código simplório (vulgo certos ports) que mostravam texturas limitadas e de baixa resolução esticadas, depois borradas com filtro bilinear.


(Filtro ligando e desligando)

Ter cartuchos limitava muito o alocamento de texturas e fudeu com a parte sonora (som no formato wav ocupa enormidades), fora a política de usar SEMPRE o source code da Nintendo, onde toda dev era obrigada a usá-lo, pelo menos viram o grande erro e liberaram a customização de código tempo depois, caso contrário o N64 nunca poderia mostrar a capacidade total do seu hardware e ficaria a míngua.

Rareware, Factor 5 e Boss Studios foram dev's que melhor optimizaram seus micro códigos, sendo um exemplo disso o Banjo (que usa o fast3d F3D uCode), onde em contagem poligonal ultrapassa os jogos de PS1 e tem enorme quantidade de texturas (sem aquele borrado todo), fazendo leitura de tudo diretamente do cartucho com o jogo rodando, usando-o como "RAM extra" para quando o personagem percorrer pela fase o software calcular e renderizar quais partes do cenário precisam ser preenchidas com texturas, a velocidade de leitura é altíssima permitindo enormidades de texturas em tela sem nenhum tipo de restrição (a não ser o próprio cartucho).

Para isso tbm é necessario que as texturas tenham muitas camadas e sejam divididas em diversas partes pequenas e depois unidas para formarem texturas maiores, sendo o cache de texturas de apenas 4kb (na verdade 2kb), pois o filtro mip mapping ocupa 2kb desse cache, suportando no máximo 4 texturas de 64x64pxls com 4 bits de profundidade, ou seja, 16 cores para cada textura ou 64 cores quando unificadas para formar uma única textura de 128x128pxls.

6.273 polígonos por frame

Se mostra superior mesmo se comparado a jogos Open World do PS1 que possuem cenários maiores como Spyrou e ainda usam polígonos crus (flat-shaded tipo Tobal 2) em boa parte do cenário.

2.812 polígonos por frame

Bom, o micro código salvou o hardware do N64, visto que o console tinha que passar tudo pelo RPC (co-processador) pois não tinha DMA e ficava limitado a m**** da pouca memória dos cartuchos.

 

[Jefferson Praxedes]

Um problema pouco conhecido na época foi o terremoto de Hanshin que atingiu boa parte do setor industrial do japão causando danos de 20 bilhoes de dolares
isso destruiu uma das principais fabricas de RAM do japão causando um enorme impacto e escassez em silício, material principal usado para fabricar os chips
sendo que todas as PCBs e componentes dos cartuchos do 64 eram fabricados no japão mesmo as versões americanas e europeias independente eram produzidas lá,
isso bem na época do N64 lançar, isso deve ter forçado a Nintendo a usar chips de tamanhos menores inicialmente nos primeiros anos da vida do console, tanto que muitos jogos multis tiveram roms de miseros 16mbit a 32mbits, capando a qualidade sonora de muitos jogos e portes, tinha games no SNES que tinham de 72 a 96mbits como Star Ocean e Far East of Eaden Zero

Great Hanshin earthquake - Wikipedia

en.wikipedia.org

No final ironciamente o cartuchos cheraram a rom size do mesmo tamanho do N64DD (512mbit) como Resident Evil 2, Conkers Bad Fur Day e Pokemon Stadium 2
os estudios que voce mencionou fizeram proezas mesmo, a factor 5 criou o driver MusyX que deu qualidade de CD e som Surround aos jogos da Lucas Art e ainda emprestou a tecnologia para Angel Studios expremer todo o audio de RE2 com surround no 64, eles também sao os criadores do format DivX que muita gente aqui usou para ver filmes e animes nos tempos mais primórdios da internet no Brasil haha

Puxa quanta informação interessante que você postou @Warrior Of Light , minha cabeça explodiu nessa cena ai roda a 376.380 polys por segundo! É insano mesmo
e eu não sabia que eles colocavam varias camadas de textura para burlar o limite de 4k, por isso os games da Rare tem texturas tão boas



Acho que no final do dia se o N64 fosse em CD os devs não focariam tanto nos gameplay e graficos, tanto que não existem nenhum game no PS1 com o mesmo moveset do Mario 64 e Banjo, o tempo que se perdia fazendo CGi eles investiram no jogo em si como foi o diferencial dele nessa geração, como voce falou usando o proprio cartucho como RAM era possivel aqueles enormes cenários com a qualidade grafica distinta , até porque a taxa de transferencia do cartucho eram enormes 50Mibs/s se comparado com os leitores do Playstation que rodavam a 2x transferindo 300kbps com alta latência , isso era um fator complicado criar mundos enormes em full 3D no console da SONY até a os devs de Soul Reaver implementar a tecnologia de mascarar os loadings in game mas tiveram que diminuir muito a qualidade sonora em contra partida justo pelo limite de transferência do CD tinha que compartilhar com os assets graficos.

 

[Arlindo Orlando]

Ter falado texturas borradas me lembrou o N64 em seus jogos de primeira leva e seus jogos de código simplório (vulgo certos ports) que mostravam texturas limitadas e de baixa resolução esticadas, depois borradas com filtro bilinear.

Visualizar anexo 84664
(Filtro ligando e desligando)

Ter cartuchos limitava muito o alocamento de texturas e fudeu com a parte sonora (som no formato wav ocupa enormidades), fora a política de usar SEMPRE o source code da Nintendo, onde toda dev era obrigada a usá-lo, pelo menos viram o grande erro e liberaram a customização de código tempo depois, caso contrário o N64 nunca poderia mostrar a capacidade total do seu hardware e ficaria a míngua.

Rareware, Factor 5 e Boss Studios foram dev's que melhor optimizaram seus micro códigos, sendo um exemplo disso o Banjo (que usa o fast3d F3D uCode), onde em contagem poligonal ultrapassa os jogos de PS1 e tem enorme quantidade de texturas (sem aquele borrado todo), fazendo leitura de tudo diretamente do cartucho com o jogo rodando, usando-o como "RAM extra" para quando o personagem percorrer pela fase o software calcular e renderizar quais partes do cenário precisam ser preenchidas com texturas, a velocidade de leitura é altíssima permitindo enormidades de texturas em tela sem nenhum tipo de restrição (a não ser o próprio cartucho).

Para isso tbm é necessario que as texturas tenham muitas camadas e sejam divididas em diversas partes pequenas e depois unidas para formarem texturas maiores, sendo o cache de texturas de apenas 4kb (na verdade 2kb), pois o filtro mip mapping ocupa 2kb desse cache, suportando no máximo 4 texturas de 64x64pxls com 4 bits de profundidade, ou seja, 16 cores para cada textura ou 64 cores quando unificadas para formar uma única textura de 128x128pxls.

6.273 polígonos por frame

Se mostra superior mesmo se comparado a jogos Open World do PS1 que possuem cenários maiores como Spyrou e ainda usam polígonos crus (flat-shaded tipo Tobal 2) em boa parte do cenário.

2.812 polígonos por frame

Bom, o micro código salvou o hardware do N64, visto que o console tinha que passar tudo pelo RPC (co-processador) pois não tinha DMA e ficava limitado a m**** da pouca memória dos cartuchos.

Bem legal saber disso. Dificilmente vejo qualquer explicação técnica sobre o N64, é tudo novidade pra mim. Uma curiosidade a respeito do Blender, software que não utilizo, mas conheço sua fama: é você quem reconstrói os polígonos a partir da imagem ou o software a analisa e faz tudo automaticamente? Achei que ficou um trabalho bem feito.

 

[Warrior Of Light]

Bem legal saber disso. Dificilmente vejo qualquer explicação técnica sobre o N64, é tudo novidade pra mim. Uma curiosidade a respeito do Blender, software que não utilizo, mas conheço sua fama: é você quem reconstrói os polígonos a partir da imagem ou o software a analisa e faz tudo automaticamente? Achei que ficou um trabalho bem feito.

Tudo é retirado automaticamente pelo software (emuladores de Debug) para o jogo rodar em wireframes, em seguida capturar a imagem e abri-la no Blender para fazer a contagem de quantos polígonos e vértices (por frame) o jogo possui. Para saber a quantidade de polígonos por segundo basta multiplicar o valor de polígonos da imagem capturada pelo número de frames por segundo (com medidor de fps no Debug).



Silent Hill - 3.894 polígonos por frame


Conker - 7.293 polígonos por frame


Zelda - 4.371 polígonos por frame

Tem tutoriais que ensinam a fazer tudo isso, meu objetivo é ter um tópico específico pra analisar o hardware e jogos de cada console, pegando desde o Atari 2600 até a sexta geração (DC/PS2/GC/XBOX), incluindo os portáteis tbm.

 

[Arlindo Orlando]

Tudo é retirado automaticamente pelo software (emuladores de Debug) para o jogo rodar em wireframes, em seguida capturar a imagem e abri-la no Blender para fazer a contagem de quantos polígonos e vértices (por frame) o jogo possui. Para saber a quantidade de polígonos por segundo basta multiplicar o valor de polígonos da imagem capturada pelo número de frames por segundo (com medidor de fps no Debug).

Visualizar anexo 84742

Silent Hill - 3.894 polígonos por frame
Visualizar anexo 84743Visualizar anexo 84745

Conker - 7.293 polígonos por frame
Visualizar anexo 84750

Zelda - 4.371 polígonos por frame

Tem tutoriais que ensinam a fazer tudo isso, meu objetivo é ter um tópico específico pra analisar o hardware e jogos de cada console, pegando desde o Atari 2600 até a sexta geração (DC/PS2/GC/XBOX), incluindo os portáteis tbm.

Poxa, cara... Parabéns por estar arregaçando suas mangas e indo você mesmo atrás da ciência por trás dos jogos. Infelizmente, ainda tem gente arrogante aqui na pasta que pega conhecimento de uma ou outra fonte, sem questionar, e toma como verdade absoluta pra corroborar o seu ponto de vista. Acho bem legal que você compartilha o conhecimento conosco e ainda indica como podemos conferir por nós mesmos, em vez de aceitar cegamente.

 

[Proteus_]

Teve um user (não lembro o nome) que pegou várias postagens minhas e colocou em um tópico com o objetivo de dizer que eu estava cometendo garfes nessas postagens, e eu respondi a cada uma dessas postagens que ele pois lá , no caso ele até distorceu meu poste lá dizendo que eu tinha afirmado certas coisas que eu nem tinha dito, uma das coisas que ele colocou lá dizendo que eu tinha dito besteira foi o fato de eu ter dito( isso eu falei mesmo) que aquele efeito de nuvem do Castlevania SofN era possível no SNes , sendo que eu tinha dado um exemplo com Demo Crest ,no caso esse efeito do Goemon é até mais parecido (praticamente idêntico a vista, provando minha argumentação, mas o cara printou aquilo achando que eu estava teclando m**** kkkkkk , Não tenho culpa se o nível de conhecimento do Cara no SNes é nível maternal kkkkk.


Outra coisa que ele colocou lá foi que eu tinha afirmado que o SNes podia ter jogos com som de alta qualidade e cantado,que o problema de certos jogos terem o som abafado era culpa de samples de baixa qualidade ou seja problema de espaço, eu mostrei que o SNes já tinha jogos cantados e com mídia maior poderia ir muito além.

No vídeo abaixo mostrarei que adicionaram em uma hack de SNes tema de Rock cantado com som bom pra Kct , isso em míseros 4 MB = 32Mb , imagina isso em um cart de 100 Mb.

Ahhhh no começo do vídeo uma surpresa em andamento reprogramado por Mim.



Link da hack na descrição do Vídeo.

 

[Jefferson Praxedes]

=O isso aí é o beta la do banjo ???????


Minha nossa, ia ser um sonho rodar no SNES isso aeww rapaiz, como tu fez isso???

Gostei da musica do Breath of Fire, Trough Fire and Flames combinou pacas haha



Enviado de meu LG-K220 usando o Tapatalk

 

[The Kong]

eu achava também, até ver novamente esses dias como roda.
aquilo não é "rodar". injogavel. definitivamente fora do escopo do console.

Na década de 90 eu alugava esse cartucho vermelho aí e me divertia DEMAIS!

Hoje rodo jogo no full HD no ultra e se cai do 60 pra 59 as já perco a vontade de jogar na hora...

As coisas eram mais simples antes

 

[Grave Uypo]

Na década de 90 eu alugava esse cartucho vermelho aí e me divertia DEMAIS!

Hoje rodo jogo no full HD no ultra e se cai do 60 pra 59 as já perco a vontade de jogar na hora...

As coisas eram mais simples antes

bom eu tava jogando gzdoom no switch no frame rate que o snes rodava e tava divertido :p (não era doom normal, claro, era meu mod)
até a parte que ficou literalmente injogavel e eu nao conseguia passar por causa da performance :( aí fui aprender a dar overclock no swtich, e ficou jogavel botando o cpu em 1.7ghz

ja fui fresco pra kct com isso, mas não sou mais.

 

[The Kong]

Ter falado texturas borradas me lembrou o N64 em seus jogos de primeira leva e seus jogos de código simplório (vulgo certos ports) que mostravam texturas limitadas e de baixa resolução esticadas, depois borradas com filtro bilinear.

Visualizar anexo 84664
(Filtro ligando e desligando)

Ter cartuchos limitava muito o alocamento de texturas e fudeu com a parte sonora (som no formato wav ocupa enormidades), fora a política de usar SEMPRE o source code da Nintendo, onde toda dev era obrigada a usá-lo, pelo menos viram o grande erro e liberaram a customização de código tempo depois, caso contrário o N64 nunca poderia mostrar a capacidade total do seu hardware e ficaria a míngua.

Rareware, Factor 5 e Boss Studios foram dev's que melhor optimizaram seus micro códigos, sendo um exemplo disso o Banjo (que usa o fast3d F3D uCode), onde em contagem poligonal ultrapassa os jogos de PS1 e tem enorme quantidade de texturas (sem aquele borrado todo), fazendo leitura de tudo diretamente do cartucho com o jogo rodando, usando-o como "RAM extra" para quando o personagem percorrer pela fase o software calcular e renderizar quais partes do cenário precisam ser preenchidas com texturas, a velocidade de leitura é altíssima permitindo enormidades de texturas em tela sem nenhum tipo de restrição (a não ser o próprio cartucho).

Para isso tbm é necessario que as texturas tenham muitas camadas e sejam divididas em diversas partes pequenas e depois unidas para formarem texturas maiores, sendo o cache de texturas de apenas 4kb (na verdade 2kb), pois o filtro mip mapping ocupa 2kb desse cache, suportando no máximo 4 texturas de 64x64pxls com 4 bits de profundidade, ou seja, 16 cores para cada textura ou 64 cores quando unificadas para formar uma única textura de 128x128pxls.

6.273 polígonos por frame

Se mostra superior mesmo se comparado a jogos Open World do PS1 que possuem cenários maiores como Spyrou e ainda usam polígonos crus (flat-shaded tipo Tobal 2) em boa parte do cenário.

2.812 polígonos por frame

Bom, o micro código salvou o hardware do N64, visto que o console tinha que passar tudo pelo RPC (co-processador) pois não tinha DMA e ficava limitado a m**** da pouca memória dos cartuchos.

Essa é de longe a MELHOR seção desse fórum e uma das melhores de Brasil, se não a melhor, no que tange à informações técnicas.

 

[The Kong]

 

[Proteus_]

=O isso aí é o beta la do banjo ???????


Minha nossa, ia ser um sonho rodar no SNES isso aeww rapaiz, como tu fez isso???

Gostei da musica do Breath of Fire, Trough Fire and Flames combinou pacas haha



Enviado de meu LG-K220 usando o Tapatalk

Desculpa a demora em responder, ando muito ocupado ultimamente, sim é o Dreams mesmo, eu iria fazer surpresa mais acabei não me segurando e postei junto da hacker de som um spoiler kkkk...

Eu estou programando do zero, fiz a captura do pc com muita gambiarra pra ele consegui captura e renderizar, mesmo assim vc percebe quedas de fps, pois renderizar em tempo real e capturar pra um dual Core sem placa de vídeo é foda.....

no entanto depois de gambiarras consegui capturar direto do pc, a parte ruim é que o vídeo ficou muito escuro não sei porque, talvez o programa de captura esteja mau configurado.....

Aqui o vídeo.


Aqui um printscreen de como realmente esta rodando, não sei porque a captura ficou escura.


Se vc perceber eu pus transparência no inicio da fase e estou adicionando detalhes no cenário.

 

[Jefferson Praxedes]

Parabéns @Proteus_ esta ficando fenomenal o seu trabalho, seu empenho e dedicação valerá a pena já que a Rare não ia vazar isso ai nem ferrando
lembro do twiiter do Tim Stamper postando a foto do cartucho que contém esse protótipo , deveria compartilhar com a galera ja que foi cancelado



Mas voce tá replicando muito bem e adicionando até uns efeitos legais !!

 

[Kyo Olhos Demoniacos]

Esse Gundan talvez não tenha feito tanto sucesso por conta de ser um jogo lento e com jogabilidade horrível. Quem vinha jogando Street Fighter, Mortal Kombat e Killer Instinct não tinha como jogar aquilo mesmo. Tecnicamente é legal de ver os sprites de Gundan hoje mas na época não me surpreendeu.

Agora Donkey Kong é diferente. Me lembro das vésperas do Natal de 1994... Aquele comercial e também as demonstrações nos shoppings eram FANTÁSTICAS. Esse Donkey Kong (e suas sequências), são atemporais. Os gráficos são lindos até hoje jogando no hardware original e TV de tubo. Envelheceram muito bem. E ninguém reclamou que a Nintendo apelou lançando três anos seguidos Donkey Kong 1, 2 e 3.

Pessoal já estava falando em 3DO, PS1 e Saturn. Já se impressionavam com o que saía nas revistas e também tinha os poucos sortudos e afortunados que já jogavam nesses consoles. A Nintendo apostou em Donkey Kong para manter o interesse no SNES e se deu muito bem.

Tenho um sentimento absolutamente nostálgico pelo Mega Drive. Foi o console que mais joguei dos 8 aos 13 anos. Foram toneladas de jogos sensacionais e até hoje gosto mais de Sonic do que Mário Bros.

Mas sem dúvidas o SNES foi um videogame melhor e a Nintendo respeitou muito mais o consumidor. O último grande ano do Mega foi 1994 e, até ali, levou parelho a geração. Mas o SNES teve mais três anos de jogos sensacionais, fantásticos e que ficarão para sempre no panteão dos melhores games.

Apenas sobre o que você falou de Gundam Wings do SFC, nem de longe é um jogo lento. Ele possui uma mecânica completamente diferente por ter robôs como personagens. Ele não foi lançado no Ocidente justamente por ser baseado num anime que não é muito gosto Americano, Mechas.

Vídeo de combos do jogo:



Esse jogo é a base para outro mais famoso no ocidente e que todo mundo conhece:



Uma vez que a programadora é a mesma empresa: A Natsume. Ela com certeza usou o Gundam Wings como base para o jogo do Power Rangers.

O que espanta no Gundam é como o jogo ficou muito bonito graficamente, fluído, com ótima jogabilidade num cartucho minúsculo.

Eu imagino um SFA3 do Snes com o estilo gráfico desse Gundam Wings, casaria perfeitamente.

 

[Frankley]

Esse Wonder Project J, saiu a continuação pra o nintendo 64

 

[ELTORO]

Um problema pouco conhecido na época foi o terremoto de Hanshin que atingiu boa parte do setor industrial do japão causando danos de 20 bilhoes de dolares
isso destruiu uma das principais fabricas de RAM do japão causando um enorme impacto e escassez em silício, material principal usado para fabricar os chips
sendo que todas as PCBs e componentes dos cartuchos do 64 eram fabricados no japão mesmo as versões americanas e europeias independente eram produzidas lá,
isso bem na época do N64 lançar, isso deve ter forçado a Nintendo a usar chips de tamanhos menores inicialmente nos primeiros anos da vida do console, tanto que muitos jogos multis tiveram roms de miseros 16mbit a 32mbits, capando a qualidade sonora de muitos jogos e portes, tinha games no SNES que tinham de 72 a 96mbits como Star Ocean e Far East of Eaden Zero

Great Hanshin earthquake - Wikipedia

en.wikipedia.org

No final ironciamente o cartuchos cheraram a rom size do mesmo tamanho do N64DD (512mbit) como Resident Evil 2, Conkers Bad Fur Day e Pokemon Stadium 2
os estudios que voce mencionou fizeram proezas mesmo, a factor 5 criou o driver MusyX que deu qualidade de CD e som Surround aos jogos da Lucas Art e ainda emprestou a tecnologia para Angel Studios expremer todo o audio de RE2 com surround no 64, eles também sao os criadores do format DivX que muita gente aqui usou para ver filmes e animes nos tempos mais primórdios da internet no Brasil haha

Puxa quanta informação interessante que você postou @Warrior Of Light , minha cabeça explodiu nessa cena ai roda a 376.380 polys por segundo! É insano mesmo
e eu não sabia que eles colocavam varias camadas de textura para burlar o limite de 4k, por isso os games da Rare tem texturas tão boas

Visualizar anexo 84694

Acho que no final do dia se o N64 fosse em CD os devs não focariam tanto nos gameplay e graficos, tanto que não existem nenhum game no PS1 com o mesmo moveset do Mario 64 e Banjo, o tempo que se perdia fazendo CGi eles investiram no jogo em si como foi o diferencial dele nessa geração, como voce falou usando o proprio cartucho como RAM era possivel aqueles enormes cenários com a qualidade grafica distinta , até porque a taxa de transferencia do cartucho eram enormes 50Mibs/s se comparado com os leitores do Playstation que rodavam a 2x transferindo 300kbps com alta latência , isso era um fator complicado criar mundos enormes em full 3D no console da SONY até a os devs de Soul Reaver implementar a tecnologia de mascarar os loadings in game mas tiveram que diminuir muito a qualidade sonora em contra partida justo pelo limite de transferência do CD tinha que compartilhar com os assets graficos.

Um detalhe importante nesses jogos de N64 que não sei se alguém menciona,é a escala dos objetos.

Normalmente em jogos de PSX ou Saturn os personagens tinham um tamanho bem reduzido para causar uma sensação de que os cenários eram realmente grandes,e certamente muitas vezes funcionava,mas olhando hoje da pra perceber isso melhor.
Pega um jogo tipo Spyro por exemplo,você vai de um lado pro outro no cenário e rapidinho você já chega.
Vejo isso bastante em alguns jogos recentes como os da série Gundam,onde os personagens mais parecem bonequinhos do que robôs grandes,propriamente falando.

Agora aquela imagem ali do Banjo Kazooie mostra que tanto os cenários quanto o personagem tinham proporções bem críveis, dá pra ver que o cenário é espaçado mas o Banjo não parece um mero bonequinho.
Não é a toa que nos wireframes que postaram dá pra ver que aquelas construções e terrenos tem proporções mais condizentes com a realidade (mas não necessariamente realistas) , e quando você vai jogar você vê que isso bate também porque a navegação pelos mapas é mais demorada mesmo com o personagem correndo.

Acho importante reforçar isso porque aguentar objetos grandes sem gerar deformações ou um slowdown da vida (quanto maior o draw distance e maior objeto,mais difícil fica pra renderizar) era um parto na época, e tão foda quanto era aguentar isso enquanto trabalha o máximo pra driblar a limitação de texturas no N64.

 

[Frankley]

Apenas sobre o que você falou de Gundam Wings do SFC, nem de longe é um jogo lento. Ele possui uma mecânica completamente diferente por ter robôs como personagens. Ele não foi lançado no Ocidente justamente por ser baseado num anime que não é muito gosto Americano, Mechas.

Vídeo de combos do jogo:



Esse jogo é a base para outro mais famoso no ocidente e que todo mundo conhece:



Uma vez que a programadora é a mesma empresa: A Natsume. Ela com certeza usou o Gundam Wings como base para o jogo do Power Rangers.

O que espanta no Gundam é como o jogo ficou muito bonito graficamente, fluído, com ótima jogabilidade num cartucho minúsculo.

Eu imagino um SFA3 do Snes com o estilo gráfico desse Gundam Wings, casaria perfeitamente.

eu conheci esse jogo do gundam só quando comecei a jogar no emulador do snes lá em 1999, eu fiquei impressionado com os gráficos, ficou muito bom.

 

[Proteus_]

Parabéns @Proteus_ esta ficando fenomenal o seu trabalho, seu empenho e dedicação valerá a pena já que a Rare não ia vazar isso ai nem ferrando
lembro do twiiter do Tim Stamper postando a foto do cartucho que contém esse protótipo , deveria compartilhar com a galera ja que foi cancelado



Mas voce tá replicando muito bem e adicionando até uns efeitos legais !!

Obrigado, eu estou inclusive criando alguns cenários inéditos utilizando pedaços de texturas de Dkc + Dreams para a construção do ambiente como por exemplo essa floresta abaixo.


Bom , eu pretendo criar algo além de uma simples demo , só não sei quanto tempo vou levar , já que estou fazendo tudo sozinho como texturização, programação e etc...