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

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

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


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

Warrior Of Light

Bam-bam-bam
Mensagens
1.236
Reações
4.648
Pontos
453
Rapaz...
Depois do seu post vou ser obrigado a jogar isso !

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

Uma coisa, será que o framerate é estável em 30FPS ou tem quedas?
Se for é algo incomum, porque lembro que jogos mais pesados de TPS tipo Jet Force Gemini tinham muitas quedas de frame.
Jet Force Gemini não usa micro-código, por incrível que pareça. Ao invés de usar o F3DEX-2 ele usa apenas o Fast-3D (primeira versão) com algumas customizações, para rodar com alguns efeitos especiais e usar algumas instruções específicas na CPU. Esse código é uma variação do que foi usado em Diddy Kong Racing, chamado de F3DDKR (Fast 3D Diddy Kong Racing) olhando pelo código do jogo ou Ucode 11 (olhando pelo debug).

Estava olhando aqui e esse jogo roda na maior parte do tempo usando mais de 90% da CPU, chegando até 100%. Enquanto isso o RCP fica em torno de 5% (em algumas partes mais e outras menos).

Ou seja, provavelmente estão usando a CPU pra calcular a geometria e outras coisas, além de calcular a lógica. Toda porcentagem de uso do RCP é por conta de estar processando a resolução, texturas e mais alguma coisa relacionada a parte gráfica, provavelmente. Não vou investigar tanto porque vou acabar irritado, pensa em alguém que fica pistola só de olhar pra código (sim, sou eu mesmo :klingua).

Abaixo a porcentagem de uso da CPU e RCP. CPU = 98,12% e GPU = 1,87%.

Sem título.png

Nessa parte o jogo roda em 30 FPS (DL/s), mas em outras partes chega e ter 19.



Esse jogo é pesado, pois tem iluminação dinâmica, AI muito avançada, alguns efeitos de frame-buffer (como esse circulo em volta do personagem na abertura), partículas, muitas animações e até simulação de ray-tracing (usando polígonos espelhados no chão).

download.png
download (4).gif

Essa foi uma "solução" para melhorar a execução do jogo, tentando tirar melhor proveito do hardware, visto que a RARE já tinha usado outros micro-códigos e não tinha obtido um resultado muito plausível, quando falamos em desempenho, pois rodavam muitos jogos com FPS abaixo da média.

A CPU e o RCP compartilham do mesmo barramento, então deixar somente a CPU pra fazer praticamente maior parte da tarefa seria uma alternativa, deixando a GPU mais livre, somente carregando alguns dados mais leves, lidando com o display da imagem, etc. Tinha achado até estranho o RCP quase não estar sendo usado, pensei em ser algum bug que estava acontecendo no debug, mas olhando no código, de fato, quase não está sendo usado mesmo.

#define EXC_INT EXC_CODE(0) /* interrupt */
#define EXC_MOD EXC_CODE(1) /* TLB mod */
#define EXC_RMISS EXC_CODE(2) /* Read TLB Miss */
#define EXC_WMISS EXC_CODE(3) /* Write TLB Miss */
#define EXC_RADE EXC_CODE(4) /* Read Address Error */
#define EXC_WADE EXC_CODE(5) /* Write Address Error */
#define EXC_IBE EXC_CODE(6) /* Instruction Bus Error */
#define EXC_DBE EXC_CODE(7) /* Data Bus Error */
#define EXC_SYSCALL EXC_CODE(8) /* SYSCALL */
#define EXC_BREAK EXC_CODE(9) /* BREAKpoint */
#define EXC_II EXC_CODE(10) /* Illegal Instruction */
#define EXC_CPU EXC_CODE(11) /* CoProcessor Unusable */
#define EXC_OV EXC_CODE(12) /* OVerflow */
#define EXC_TRAP EXC_CODE(13) /* Trap exception */
#define EXC_VCEI EXC_CODE(14) /* Virt. Coherency on Inst. fetch */
#define EXC_FPE EXC_CODE(15) /* Floating Point Exception */
#define EXC_WATCH EXC_CODE(23) /* Watchpoint reference */
#define EXC_VCED EXC_CODE(31) /* Virt. Coherency on data read */

Não foi uma solução muito boa, visto que o desempenho ainda sofre. Vendo isto a RARE usou outra solução no seus próximo jogos, usando micro-códigos customizados pra fazer melhor uso do RCP (e de todo hardware em si). Conker usa o F3DEX-2 e roda muito melhor, além de ser um jogo mais pesado.
 
Ultima Edição:

Jefferson Praxedes

Ei mãe, 500 pontos!
Mensagens
2.069
Reações
7.642
Pontos
703
Ambicioso demais esse Riqa hein? Parece ter ótimo level design e gameplay, enfim podemos ter ao menos o que a galera fez com o Dinossaur Planet , tentar deixar o game terminado para jogar continuamente, incrível apesar de estar bem avançado em desenvolvimento ainda foi cancelado!

Então vim aqui para fazer uma celebração da edição 4 da revista Nation 64!

Recebi essa de presente já que fui entrevistado nela e nada mais nada menos que o Próprio dev que trabalhou no microcódigo do game o Alexander Ehrath , vou deixar aqui só uma espiadinha nela hehe:

1000287340.jpg

1000287342.jpg

1000287341.jpg
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.236
Reações
4.648
Pontos
453
Como o cara fez essas texturas aqui?
Nem parece N64


Achei doido isso aqui também:

Aumentando o tamanho da ROM. OOT tem 32 MB, adicionando esse patch fica com 56 MB. Tendo mais memoria ROM é possível ter muito mais texturas de alta resolução, pois são 24 MB de memoria ROM adicionados, e são justamente destinados as texturas.

Sem título2.png

Você tem muitas texturas de 32x64, 64x32 e 64x64. Memoria ROM fazia diferença demais, mesmo se fossem adicionados poucos MB's. Neste caso a quantidade usada equivale ao tamanho de um jogo entre meio/fim de vida do N64 na época.

Sem título.png
 

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Aumentando o tamanho da ROM. OOT tem 32 MB, adicionando esse patch fica com 56 MB. Tendo mais memoria ROM é possível ter muito mais texturas de alta resolução, pois são 24 MB de memoria ROM adicionados, e são justamente destinados as texturas.

Visualizar anexo 390434

Você tem muitas texturas de 32x64, 64x32 e 64x64. Memoria ROM fazia diferença demais, mesmo se fossem adicionados poucos MB's. Neste caso a quantidade usada equivale ao tamanho de um jogo entre meio/fim de vida do N64 na época.

Visualizar anexo 390435
Entendi.
É foda que o N64 usava cartucho, eu fico imaginando se usasse CD, ia ser bem melhor ainda.

E tipo, não sabia que dava pra aumentar o tamanho da ROM com patches, achei que teria de refazer o jogo do zero ou utilizar outro método (algo tipo o MSU-1 nos jogos de SNES).

De primeira até achei que era pack de texturas pra versão de PC, e não uma hack do jogo original.
 


and_manf

Ei mãe, 500 pontos!
Mensagens
6
Reações
15
Pontos
923
Lembro que numa antiga discussão aqui sobre o porque o Nintendo 64 não recebeu muitos games em 2D e ports de Arcade da época, alguém citava o texture cache baixo como um dos problemas. Se isso era mesmo um empecilho, esse aspecto foi contornado pelo desenvolvedor do port de Xeno Crisis, lançado no sistema ano passado. Uma breve explicação pode ser vista aqui:


xeno3.png
 

*ka

Mil pontos, LOL!
Mensagens
11.854
Reações
11.602
Pontos
1.344
Lembro que numa antiga discussão aqui sobre o porque o Nintendo 64 não recebeu muitos games em 2D e ports de Arcade da época, alguém citava o texture cache baixo como um dos problemas. Se isso era mesmo um empecilho, esse aspecto foi contornado pelo desenvolvedor do port de Xeno Crisis, lançado no sistema ano passado. Uma breve explicação pode ser vista aqui:


Visualizar anexo 390866
Provavelmente o motivo devia ser que a Nintendo não queria muitos jogos 2D no N64, pois jogos 3D deviam fazer o sistema parecer mais moderno. Possivelmente o N64 rodaria Street Fighter Alpha, KOF, série VS da capcom e etc, e acho que caberiam no cartucho de 64MB. O N64 também tem um controle decente para jogos de luta pois tem duas fileiras com 3 botões em linha, apesar dos botões C serem pequenos dá para usar de boa dessa forma.
 

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Lembro que numa antiga discussão aqui sobre o porque o Nintendo 64 não recebeu muitos games em 2D e ports de Arcade da época, alguém citava o texture cache baixo como um dos problemas. Se isso era mesmo um empecilho, esse aspecto foi contornado pelo desenvolvedor do port de Xeno Crisis, lançado no sistema ano passado. Uma breve explicação pode ser vista aqui:


Visualizar anexo 390866
O Kaze Emmanuar que faz hacks de jogos pra N64 já dizia que o cache de texturas é mais do que suficiente.


Dito isso, excelente trabalho dessa desenvolvedora, não deve ter sido nada fácil portar o jogo.

Provavelmente o motivo devia ser que a Nintendo não queria muitos jogos 2D no N64, pois jogos 3D deviam fazer o sistema parecer mais moderno. Possivelmente o N64 rodaria Street Fighter Alpha, KOF, série VS da capcom e etc, e acho que caberiam no cartucho de 64MB. O N64 também tem um controle decente para jogos de luta pois tem duas fileiras com 3 botões em linha, apesar dos botões C serem pequenos dá para usar de boa dessa forma.
Rodaria tranquilamente.
 

Wolkaiser

Bam-bam-bam
Mensagens
2.270
Reações
7.678
Pontos
283
Faltou o melhor de todos que é Ogre Battle.

Ele considerou somente jogos 2D com sprites. Ogre Battle 64 tem algumas partes poligonais.

large.jpg
1714828874585.png
 

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Putz, faltou Ogre Battle mesmo, possivelmente o melhor game em 2D do console.

RPG não era o forte do N64, mas ainda sim o console teve dois dos melhores RPGs da geração: Ogre Battle 64 e Paper Mario.
Infelizmente a Nintendo não contribuiu ao optar por cartucho ao invés de mídia CD.
Não fosse isso o N64 ia ter uma penca de jogos de RPG.
Ele considerou somente jogos 2D com sprites. Ogre Battle 64 tem algumas partes poligonais.

large.jpg
Visualizar anexo 391211
Ah bão.

Um jogo que não citado no vídeo é o Rakuga Kids



eu gosto bastante do mischief makers (Yuke Yuke Trouble Makers).
Visualizar anexo 391296

Embora eu ache um jogo bom, sinceramente...artisticamente acho feio.
Os assets utilizados me parecem aqueles renderings promocionais de jogos antigos, muito esquisito.
Esse jogo ao meu ver seria melhor se tivesse sprites mais cartunescos.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.236
Reações
4.648
Pontos
453
Tecnicamente falando não existem jogos 2D no N64, tudo é feito com texturas que precisam de wireframes (feitos com polígonos 2D/sem o eixo Z) para serem exibidos. O hardware do N64 é totalmente focado em gráficos poligonais, não existem sprites ou backgrounds, tanto que no código todo gráfico "2D" é especificado como "primitives". No Saturno é diferente, pois ainda lida com gráficos 2D, no código você especifica "sprites" e "backgrounds" da mesma forma que na geração 16 bits.

Tela de título do Rakuga Kids, varios pimitives (polígonos 2D) representados pelos wireframes, e logo em seguida todos texturizados.



Se eu fosse criar uma lista de jogos 2D incluiria todos esses jogos que usam polígonos em alguma parte ou nos cenários, como em Killer Instinct Gold, Rakuga Kids e Paper Mario, mas entendo o proposito do vídeo, que foi apenas mostrar os jogos que não usam nada que fuja do padrão 2D tradicional, sem nenhuma parte ou objeto geométrico.

N64 é um foguete para gráficos 2D, pois gerar sprites usando polígonos 2D é muito mais eficiente do que usar sprites e backgrounds. Segue o benchmark de quantos sprites o N64 consegue processar em 60 FPS.

7WBZFHw.png

Nessa imagem acima o benchmark foi feito em cima do micro-código Fast-3D, ou seja, tá muito limitado ainda, usando versões customizadas daria para processar pelo menos o dobro (ou triplo) de sprites, segundo meus cálculos. Existe micro-código somente para gráficos 2D (que vinha junto no SDK), mas raramente foi usado, mesmo tendo muita vantagem sobre os outros quando se trata de gráficos 2D. Não dá pra saber porque usavam micro-código 3D pra fazer 2D e descartavam o micro-código especifico para 2D, parece até sabotagem.

Testei vários jogos "2D" e 90% deles usam o micro-código F3DEX-2, como Rakuga Kids, Paper Mario e Ogre Battle 64. Outros jogos como Yoshi Story e Mischief Makers usam outros. Esse micro-código era o mais rápido disponível pela Nintendo, tanto que foi usado pela RARE em Conker, mas não era voltado para 2D.

No caso do Mischief Makers usaram uma variação do micro-código Fast-3D com algumas funções específicas para manipulação de sprites (rotação, escalonamento, distorção, aumento de desempenho, etc). Esse micro-código usado é o RSP SW v2.0, tá longe de ser o melhor micro-código para lidar com 2D, pois é o mesmo micro-código do Mario 64 com algumas funções para manipulação de sprites.

Yoshi Story foi o único desses que realmente usou um micro-código decente, usando o micro-código S2DEX que é muito rápido e totalmente voltado para gráficos 2D, fazendo "primitives" de todos os tamanhos e podendo carregar tudo no frame-buffer de uma vez só com apenas 1 comando. Essa tela de Rakuga Kids usa 80 comandos de carregamento de texturas para montar a imagem no frame-buffer e exibi-la, Yoshi Story usa apenas 1 comando e ainda carrega mais texturas.

Sem título3.png
 
Ultima Edição:

*ka

Mil pontos, LOL!
Mensagens
11.854
Reações
11.602
Pontos
1.344
No Saturno é diferente, pois ainda lida com gráficos 2D, no código você especifica "sprites" e "backgrounds" da mesma forma que na geração 16 bits.
Eu achava que o saturn e playstation funcionavam diferente da geração anterior, por causa dessa postagem onde é dito que sat e ps1 não trabalham com sprites reais e usam blitter. Mas provavelmente você vai saber explicar melhor devi ao seu conhecimento.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.236
Reações
4.648
Pontos
453
Eu achava que o saturn e playstation funcionavam diferente da geração anterior, por causa dessa postagem onde é dito que sat e ps1 não trabalham com sprites reais e usam blitter. Mas provavelmente você vai saber explicar melhor devi ao seu conhecimento.

Exatamente como ele explicou, o termo "blitão" usado é justamente desenhar um objeto na memória do frame-buffer (que vem da operação blitter-operation ou simplesmente "blit" do Blitter, um co-processador do Amiga 500), mas os consoles dessa geração "blitão" (desenham objetos) de forma muito mais rápida.

No Saturno você ainda lida com gráficos 2D, no código você especifica "sprites" e "backgrounds", praticamente da mesma forma que era na geração 16 bits (com algumas variações, entretanto). O hardware do Saturno entende o que é sprite e background. Os sprites são desenhados num frame-buffer como quadriláteros 2D (primitives) e depois texturizados (como no N64) usando sua memória dedicada (512 KB) para armazenar os comandos de desenho, tiles, tabelas de cores (além de outros atributos referentes aos sprites), tudo feito pela VDP-1. E os Backgrounds usam tilemaps formadas por tiles de 8x8, ou seja, não usam um frame-buffer, mas um sistema baseado em tiles (como SNES, MD, NES e MS), que é gerado em tempo real, tudo feito pela VDP-2.

PS1 a mesma coisa, faz tudo com primitives (fazia com polígonos 2D e o Saturno fazia com quads 2D) e depois texturizava igual ao N64, com a única diferença de que tanto no PS1 quanto no Saturno existe um comando para especificar um sprite, mas no final das contas, tudo é textura em cima de wireframes.

Resumindo, o Saturno ainda manteve o velho uso de tiles, como nos consoles 16 bits, diferente do N64 e PS1 que não tinham absolutamente nada baseados em tiles. Outra coisa, N64 não tinha nenhum comando/termo para especificar "sprite", tudo é tratado como polígono, seja 2D ou 3D.

 
Ultima Edição:

*ka

Mil pontos, LOL!
Mensagens
11.854
Reações
11.602
Pontos
1.344
Exatamente como ele explicou, o termo "blitão" usado é justamente desenhar um objeto na memoria do frame-buffer (que vem da operação blitter-operation ou simplesmente "blit" do Blitter, um co-processador do Amiga 500), mas os consoles dessa geração "blitão" (desenham objetos) de forma muito mais rápida.

No Saturno você ainda lida com gráficos 2D, no código você especifica "sprites" e "backgrounds", praticamente da mesma forma que era nas geração 16 bits (com algumas variações, entretanto). O hardware do Saturno entende o que é sprite e background. Os sprites são desenhados num frame-buffer como quadriláteros 2D (primitives) e depois texturizados (como no N64) e usa memoria dedicada (512 KB) para armazenar os comandos de desenho, tiles, tabelas de cores (além de outros atributos referentes aos sprites), tudo feito pela VDP-1. E os Backgrounds usam tilemaps formadas por tiles de 8x8, ou seja, não usam um frame-buffer, mas um sistema baseado em tiles (como SNES, MD, NES e MS), que é gerado em tempo real, tudo feito pela VDP-2.

PS1 a mesma coisa, faz tudo com primitives (fazia com polígonos 2D igual ao N64, Saturno fazia com quads 2D) e depois texturizava, com a única diferença de que no PS1 existe um comando para especificar um sprite, mas no final das contas, tudo é textura em cima de wireframes.

Resumindo, o Saturno ainda manteve o velho uso de tiles, como nos consoles 16 bits, diferente do N64 e PS1 que não tinham absolutamente nada baseados em tiles. Outra coisa, N64 não tinha nenhum comando/termo para especificar "sprite" ou "background", tudo é tratado como polígono, seja 2D ou 3D.


Obrigado pela explicação :kjoinha
 

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Não sei se vale.
Mas outro jogo 2D é o port homebrew do Doom original.
Bom lembrar que o Doom original não é 3D e sim 2D.

Exatamente como ele explicou, o termo "blitão" usado é justamente desenhar um objeto na memória do frame-buffer (que vem da operação blitter-operation ou simplesmente "blit" do Blitter, um co-processador do Amiga 500), mas os consoles dessa geração "blitão" (desenham objetos) de forma muito mais rápida.

No Saturno você ainda lida com gráficos 2D, no código você especifica "sprites" e "backgrounds", praticamente da mesma forma que era na geração 16 bits (com algumas variações, entretanto). O hardware do Saturno entende o que é sprite e background. Os sprites são desenhados num frame-buffer como quadriláteros 2D (primitives) e depois texturizados (como no N64) usando sua memória dedicada (512 KB) para armazenar os comandos de desenho, tiles, tabelas de cores (além de outros atributos referentes aos sprites), tudo feito pela VDP-1. E os Backgrounds usam tilemaps formadas por tiles de 8x8, ou seja, não usam um frame-buffer, mas um sistema baseado em tiles (como SNES, MD, NES e MS), que é gerado em tempo real, tudo feito pela VDP-2.

PS1 a mesma coisa, faz tudo com primitives (fazia com polígonos 2D e o Saturno fazia com quads 2D) e depois texturizava igual ao N64, com a única diferença de que tanto no PS1 quanto no Saturno existe um comando para especificar um sprite, mas no final das contas, tudo é textura em cima de wireframes.

Resumindo, o Saturno ainda manteve o velho uso de tiles, como nos consoles 16 bits, diferente do N64 e PS1 que não tinham absolutamente nada baseados em tiles. Outra coisa, N64 não tinha nenhum comando/termo para especificar "sprite", tudo é tratado como polígono, seja 2D ou 3D.


Não fosse o tamanho do cartucho, acho que esse jogo teria saído pra N64.
 

*ka

Mil pontos, LOL!
Mensagens
11.854
Reações
11.602
Pontos
1.344
Não sei se vale.
Mas outro jogo 2D é o port homebrew do Doom original.
Bom lembrar que o Doom original não é 3D e sim 2D.


Não fosse o tamanho do cartucho, acho que esse jogo teria saído pra N64.
Posso estar errado, mas acho que caberia em um cartucho de 64MB reduzindo a qualidade do áudio. Se o Resident Evil 2 coube, creio que o Symphony também caberia.
O Symphony of the Night não deve ter saído porque a Nintendo estava dando preferência para jogos 3D e provavelmente devem ter preferido ter o Castlevania e Castlevania Legacy of Darkness como exclusivos por serem 3D.
 

and_manf

Ei mãe, 500 pontos!
Mensagens
6
Reações
15
Pontos
923
Posso estar errado, mas acho que caberia em um cartucho de 64MB reduzindo a qualidade do áudio. Se o Resident Evil 2 coube, creio que o Symphony também caberia.
O Symphony of the Night não deve ter saído porque a Nintendo estava dando preferência para jogos 3D e provavelmente devem ter preferido ter o Castlevania e Castlevania Legacy of Darkness como exclusivos por serem 3D.
Também acredito nisso, creio que quase todos os games do PS1 são pesados devido ao áudio e CG/FMV. No entanto creio que não foi só a posição da Nintendo em relação ao 2D que pesou pra escassez de jogos do console. Títulos da Namco como Tekken ou mesmo os 3D da Capcom como Street Fighter EX, Star Gladiator e Rival Schools poderiam estar no Nintendo 64 e nunca foram cogitados. Essa falta de apoio das grandes japonesas pesou muito, pelo que lembro até meados de 1998 só a Konami dava suporte.
 

Ridge

Bam-bam-bam
Mensagens
2.146
Reações
4.671
Pontos
453
Essa política da Nintendo de priorizar jogos 3D no N64 talvez explique o motivo da Capcom lançar Street Fighter Alpha 2 pro SNES ao invés de lançar pro N64.

O N64 precisava muito mais de games de luta que o SNES que praticamente já estava em seu final de ciclo.
 

and_manf

Ei mãe, 500 pontos!
Mensagens
6
Reações
15
Pontos
923
Essa política da Nintendo de priorizar jogos 3D no N64 talvez explique o motivo da Capcom lançar Street Fighter Alpha 2 pro SNES ao invés de lançar pro N64.

O N64 precisava muito mais de games de luta que o SNES que praticamente já estava em seu final de ciclo.
Existe alguma ferramenta tipo SGDK pro Nintendo 64 ? Se algum programador se aventurasse a portar algo do zero, meu sonho seria justamente ver Street Fighter Alpha 2 rodando no console.
 

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Achei um teste do SOTN no n64, postados no fórum eletrolado :
3sGRfMb.png

Posso estar errado, mas acho que caberia em um cartucho de 64MB reduzindo a qualidade do áudio. Se o Resident Evil 2 coube, creio que o Symphony também caberia.O Symphony of the Night não deve ter saído porque a Nintendo estava dando preferência para jogos 3D e provavelmente devem ter preferido ter o Castlevania e Castlevania Legacy of Darkness como exclusivos por serem 3D.
Daria, mas aí seria tenso, músicas do SOTN sofreriam muito com a compressão.

Lembrei da revista que disse que o Castlevania 3D era excelente enquanto o SOTN era horrível graficamente.
 

*ka

Mil pontos, LOL!
Mensagens
11.854
Reações
11.602
Pontos
1.344
Achei um teste do SOTN no n64, postados no fórum eletrolado :
Visualizar anexo 391437


Daria, mas aí seria tenso, músicas do SOTN sofreriam muito com a compressão.

Lembrei da revista que disse que o Castlevania 3D era excelente enquanto o SOTN era horrível graficamente.
Não acho que as músicas ficariam tão ruins, perder um pouco de qualidade no áudio não impediria as pessoas de se divertirem com o jogo. Assim como o pessoal se divertiu da mesmo forma com RE2, que teve algumas reduções para caber no cartucho, tem melhorias, mas também tem reduções. Tudo dependeria da equipe que trabalharia na versão n64.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.236
Reações
4.648
Pontos
453
Achei um teste do SOTN no n64, postados no fórum eletrolado :
Visualizar anexo 391437
SOTN seria fácil portar, pois é um jogo bem leve para o PS1 (até o SNES portaria de forma decente), mas o maior problema seria a parte sonora, como vocês disseram. Não que isso tornasse o porte impossível, mas seria o maior obstáculo, pois a parte gráfica não tem nada demais. Não estou criticando o jogo, só falando tecnicamente, inclusive, esse é o segundo melhor Castlevania para mim, perdendo apenas para o Rondo of Blood (tanto que na história estão conectados).

Sou amigo do programador que fez essa demo, abaixo as informações:

SYMPHONY OF THE NIGHT N64

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

TESTES DE SCROLLING

Testando algum tipo de otimização de rolagem.

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

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.

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

Não acho que as músicas ficariam tão ruins, perder um pouco de qualidade no áudio não impediria as pessoas de se divertirem com o jogo. Assim como o pessoal se divertiu da mesmo forma com RE2, que teve algumas reduções para caber no cartucho, tem melhorias, mas também tem reduções. Tudo dependeria da equipe que trabalharia na versão n64.

RE2 é o melhor exemplo de como eles poderia lidar com o áudio. Além de terem portado toda parte sonora ainda adicionaram Dolby Surround, e ainda portaram todos os FMV's (que são os maiores arquivos e mais complexos para espremer no cartucho). Alguns dizem que a parte sonora ficou até melhor no N64, inclusive os desenvolvedores. Particularmente eu acho ambas muitos boas, com o PS1 tendo vantagem na qualidade da amostra e o N64 tendo vantagem no Surround.

Inclusive, o mesmo que fez a demo do SOTN no N64 também portou toda a trilha sonora.

CASTLEVANIA: SOTN OST

Toda a trilha sonora convertida em ogg 44KHz / Estéreo / 128kbps, 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.

Imagem


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

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

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

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

Infelizmente removeram esses links das músicas, mas vou tentar achar aqui no meio das coisas, caso não ache em lugar nenhum vou entrar em contato com ele. De qualquer forma, isso mostra que num cartucho de 64MB cabem todas as músicas com a mesma qualidade do PS1. Num eventual porte isso não seria necessário, amostras de 44KHz ocupam muito, então reduzir a qualidade das amostras para 22KHz (formato ADPCM ou uLaw) seria o necessário, além de adicionar Surround. Fazendo dessa forma, você reduz pela metade a quantidade de ROM que a parte sonora ocuparia (e ainda adicionaria som 3D), ou seja, as músicas ocupariam 32MB e ainda sobrariam 32MB para os gráficos.

Exatamente assim fizeram no porte de RE2, amostras e FMV's em formatos comprimidos e o restante para comportar os gráficos, até extras foram adicionados.

E o XenoCrisis no 64? Roda como?

Roda muito bem, é um jogo bem leve.



Já era leve para os padrões do MD e SNES, imagina para o N64. Outros jogos como Smash T.V. e Pocky & Rocky eram mais pesados. Smash T.V. por colocar absurdamente mais inimigos em tela e Pocky & Rocky por colocar inimigos maiores, muito mais efeitos e cenários em constante movimento (ao invés de telas estáticas trocando toda hora).



Também não estou fazendo uma crítica ao jogo, pois é um jogo muito bom, o level design por exemplo, humilha o do Smash T.V. e a trilha sonora é absurda. Viu o porte que saiu para SNES? Portaram recentemente e os caras estão de parabéns, pois melhoraram muita coisa e adicionaram extras. É importante pontuar essas coisas, pois já vi falarem que era um jogo ultra pesado e isso e aquilo outro, mas não é nada disso, porém, como disse antes o level design (Henk Nieborg é monstro demais) e parte sonora são de outro planeta.
 
Ultima Edição:

ELTORO

Mil pontos, LOL!
Mensagens
28.182
Reações
64.105
Pontos
1.253
Tem um camarada fazendo uma hack interessante de Ocarina, alterações drásticas nos ambientes do jogo e alguns lugares novos customizados:









Esse aqui achei doidera que as árvores mexem por conta do vento:

 

Wolkaiser

Bam-bam-bam
Mensagens
2.270
Reações
7.678
Pontos
283
Vale lembrar que um dos maiores feitos da Angel Studios com RE2, foi criar codecs de áudio e video para o N64, coisa que não existia nos kits originais.
Então um port de SOTN teria que lidar com algo que não existia, por isso a dificuldade.

Lembrei da revista que disse que o Castlevania 3D era excelente enquanto o SOTN era horrível graficamente.

9hylyn33eks41.jpg
 

Ridge

Bam-bam-bam
Mensagens
2.146
Reações
4.671
Pontos
453
Sim, é possível SOTN no N64, mas teria que ter um cartucho de 64MB principalmente pra ter uma boa qualidade de áudio.

O problema é que la em 97/98 esse jogo dificilmente teria usado um cartucho de 64MB, ainda mais sendo um jogo 2D feito por uma third.

Na época provavelmente o jogo iria ser lançado em um cartucho com espaço minúsculo e com vários cortes nos áudios.
 
Topo Fundo