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 Super Nintendo [+Remake incrível do SUPER MARIO LAND][+Sonic no SNes]

Maxwelsoonage

Supra-sumo
Mensagens
212
Reações
948
Pontos
178
Impressionante, parabéns! Isso significa que não utilizavam a resolução alta pór outros motivos que não as cores, como o consumo maior de processamento e ausência de modos e efeitos? Ou nem isso também?
Obrigado!
Na verdade, não há consumo maior de processamento.
É só a S-PPU que vai estar operando diferente, a CPU não tem carga extra alguma.

Tem alguns motivos bem grandes para não terem usado tanto:
1 - O tamanho dos gráficos. Eles precisam ser 4 vezes maiores que o normal, a menos que você queira que eles fiquem miúdos na tela.
Isso acaba gastando VRAM mais rápido.
Por exemplo, toda camada no SNES suporta até 1024 tiles. Com 1024 tiles em 2bpp (16 KB), 4bpp (32 KB) ou 8bpp (64 KB) na resolução padrão do SNES, você pode completar uma tela inteira só de tiles únicas, sem repetir nenhuma.
Em alta resolução de 512x448, essa quantidade de tiles só ocupa 1/4 da tela.
Nessa minha demo, as 1024 tiles usadas no background são essas, muito perto do limite.
1704495313580.png
Ok eu exagerei no tamanho dessas coisas, mas é só pra demonstrar o nível de detalhes mesmo. hehe
Como o Mode 6 só tem uma camada, não existe outra pra usar o resto das tiles, 1024 é o limite. A menos que se use HDMA para fazer a camada acessar outros 1024 tiles, mas nesse caso específico não deu pra usar, já que to usando offset-per-tiles junto. Seria útil no Mode 5.

2 - A imagem estar em modo entrelaçado/interlaced pode ser desagradável para alguns. A imagem tende a ser mais "tremida", já que fica nesse troca troca de linhas impares e linhas pares.
Os emuladores emulam o entrelaçamento de maneira crua, então você consegue ver uns artefatos feios na tela que não são aparentes nas CRTs.
1704497308318.png
Em 512x224 você não precisa usar o modo entrelaçado, então ele foi mais utilizado.

3 - O número de camadas e as especificações delas.
No Mode 5, você tem duas camadas: Uma camada de 4bpp, permitindo 8 paletas de 16 cores, padrão do console. A outra camada é de 2bpp, permitindo 8 paletas de 4 cores. Essa segunda camada ser de 2bpp já era algo que os devs não curtiam, já que uma segunda camada é geralmente usada para o fundo de uma fase e esse formato é mais preferível para barra de status ou algo simples assim.
No Mode 6, sobra uma única camada de 4bpp.

4 - Limitação com efeitos de transparência.
Os chamados Mainscreen e Subscreen do console são dois planos muito úteis para efeitos especiais de cores. É como se fosse um plano de misturar cores enquanto o outro é opaco.
Em alta resolução não é possível utilizar isso corretamente, pois esses dois planos são necessários para o aumento da resolução.
Por isso acabei fazendo as bolhas traçadas. Elas ficam piscantes na televisão.
 
Ultima Edição:

ELTORO

Mil pontos, LOL!
Mensagens
27.896
Reações
63.096
Pontos
1.253
Super Mario CD simula os gráficos de um "NES CD". Está usando o mode-0 (4 camadas de background) e MSU-1 para as músicas.


O projeto bizonhamente parece velho e ao mesmo tempo moderno!
Eu achei esse visual bem melhor do que a aparência do Super Mario All-Stars.
E o parallax tá bonito DEMAIS, pessoal que fez tá de parabéns.
 

Daniel-Glenn

Ei mãe, 500 pontos!
GOLD
Mensagens
338
Reações
595
Pontos
619
O projeto bizonhamente parece velho e ao mesmo tempo moderno!
Eu achei esse visual bem melhor do que a aparência do Super Mario All-Stars.
E o parallax tá bonito DEMAIS, pessoal que fez tá de parabéns.
Estão fazendo um excelente uso do mode 0, a quantidade ideal de cores para simular um visual 8 bits, e com as 4 camadas o parallax entre elas está demais mesmo.
 


jadersnes

Ei mãe, 500 pontos!
Mensagens
1.864
Reações
1.099
Pontos
609
Aeeee! Tava achando muito suspeito essa ideia que ele passou de fazer só algumas cópias físicas e não liberar na internet.
Que bom que ele mudou de ideia.
Exatamente! O jogo é curto, mas parece muito bem feito. Em breve colocarei no meu everdrive pra testar.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Vamos investigar as capacidades poligonais do SNES, para ver se os números batem com o que está documentado. Segundo a equação baseada nos cálculos do desenvolvedor Grog, o 65C816 conseguiria processar 400 polígonos por segundo (flat-shaded/sem textura) ou 100 polígonos texturizados por segundo, num frame-buffer de 256x160 em 15 FPS.

Números exatos (quantidade X ou Y de polígonos que esses consoles processam) são difíceis de comprovar na prática, pois nenhum jogo dessa época era totalmente em 3D, portanto, os números podem variar bastante dependendo do tamanho do frame-buffer, frame-rate e se o jogo usa muitos elementos em 3D (Nesglider e Race Drivin) ou apenas usa 3D em alguns objetos (Zelda LTTP).

Começando por Zelda LTTP, na abertura/encerramento vemos a tri-force feita com polígonos e in-game vemos os cristais depois de derrotar os chefes. Todos possuem 7 cores (vindos de uma paleta de 16 cores).

Tri-force. 24 polígonos e 18 vértices numa resolução de 256x224 em 60 FPS = 1.440 polígonos sem texturas por segundo. Superando o cálculo feito baseando-se no site de desenvolvimento do Grog, além de estar numa resolução e frame-rate maiores.

tumblr_moplv02Fzb1r0ralmo1_r1_500.gif

124154325.png

124234235.png

Cristais. 8 polígonos e 6 vértices numa resolução de 256x224 em 60 FPS = 480 polígonos sem texturas por segundo. A princesa dentro do cristal não é uma textura, mas trata-se de uma sprite que colocaram na frente dos polígonos.

download.png

12312312.png

Esses são os polígonos presentes em Zelda LTTP. Escolhi esse jogo porque usa polígonos de forma não comprometedora, a maioria que usa são péssimos exemplos, mas posteriormente pretendo analisar esses jogos que usam muitos polígonos, como Race Drivin ou Nesglider (protótipo do Star Fox).

Falando em Star Fox, vamos analisar um pouco, visto que aqui já temos algo bem melhor e realmente jogável, pois sabemos que todos os consoles daquela época eram ruins com o 3D, nem o "poderoso" Neo Geo lidava bem com polígonos, na realidade ele sequer processava 3D devido a sua arquitetura (fazia leitura de tiles apenas).

Nave Starwing. 52 polígonos e 42 vértices com 13 cores numa resolução de 224x192 em 60 FPS = 3.120 polígonos sem texturas por segundo (o jogo normal roda em 20 FPS, mas existe patch para rodar em 60).

nqJwpGZ.gif

21423546.png

123123123123.png

Esses são apenas os números iniciais, pois Star Fox coloca muitos elementos 3D em tela, excluindo parte dos cenários (céu e chão) que usam tiles normais do BG2. O chão inclina porque está usando off-set per tile (deslocamento de tiles em colunas) em Mode 2. Os wireframes são a parte 3D do jogo, os pontilhados brancos no chão e sombras das naves também são feitos com polígonos (esses modelos 3D trago depois). Esse jogo certamente chega em 15-20 mil polígonos por segundo, esses eram os números oficiais (ditos pelo presidente da Argonaut), embora a Nintendo tenha dito ser capaz de 76,5 mil. :kmario

123123123123123.png
 
Ultima Edição:

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Gameplay de 13 minutos do Super Mario Bros CD. Projeto incrível mesmo, é como tivessem usado um add-on no NES para exibir mais camadas e som de CD (tipo um Nintendo CD para o NES).



Continuando com a análise geométrica em Star Fox, vemos que realmente o jogo seria impossível sem o Super FX, pois existem algumas coisas que nem mesmo o SA-1 daria conta de replicar.

No começo do jogo temos 136 polígonos e 112 vértices. A nave Airwing in-game possui 20 polígonos e 16 vértices (diferente da nave rodando na tela de título). Os pontilhados brancos no chão são todos vetores (polígonos 2D/sem profundidade ou eixo Z). Nessa cena temos 8.160 polígonos por segundo (136 polígonos x 60 FPS).

Star Fox Scene2.png

Alguns inimigos comuns do jogo. Existem inimigos comuns com 64 polígonos e 51 vértices, como o robô que aparece carregando uma pilastra logo na primeira fase.

Comum1.png

Comum3.png

Comum2.png

Chefe final, Andross. Possui 57 polígonos e 35 vértices, não muito se comparado até mesmo a inimigos comuns, mas solta muitos quadriláteros pela boca jogando a geometria nas alturas.

Andross.png

Agora chegou na parte onde veremos realmente o máximo do Super FX, no chefe secreto Slot Machine, que sozinho possui 161 polígonos e 108 vértices. Nessa parte eles realmente usaram o Super FX no máximo, pois além da alta geometria do chefe quando você acerta o Jackpot (uma sequência de 3 números 7 seguidos) a máquina começa a soltar muitas moedas ao mesmo tempo (sendo até 10 moedas simultaneamente). Nisso, temos 461 polígonos e 284 vértices (somando a máquina de caça níquel, a nave Airwing e todas as moedas).

Considerando o patch que adiciona o Super FX-2 e Fast-ROM temos 60 FPS. Dito isso, nessa cena temos 27.660 polígonos por segundo (461 polígonos x 60 FPS), mas ainda esse número sobe ainda mais um pouco, pois temos os tiros da nave e as partículas no fundo do cenário (os pontilhados brancos se movendo atrás do chefe), que são feitas com vetores. O número de partículas nessa parte é de aproximadamente 50-70 vetores, portanto, teríamos entre 30-32 mil polígonos por segundo.

Cena completa.png



Ainda estou curioso quanto a hack Exploration Showcase, pois os próprios desenvolvedores disseram que foi feita para mostrar as capacidades do Super FX-2. Logo na tela de título vemos 4 modelos de alta geometria (pra época) e partículas no fundo do cenário.

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

Madarame

Mil pontos, LOL!
Mensagens
14.101
Reações
35.101
Pontos
1.054
E essa pegadinha de Primeiro de Abril?





Lembrou o Ecstatica:

Ecstatica-screenshot-5.gif
 

Akira_Toriyama

Habitué da casa
Mensagens
134
Reações
388
Pontos
78
Super Mario CD simula os gráficos de um "NES CD". Está usando o mode-0 (4 camadas de background) e MSU-1 para as músicas.


Séria muito melhor fazer um projeto imaginando como séria Super Mario para o SNES CD, já que o SNES só não teve esse acessório por desavença com a Sony.
 

jadersnes

Ei mãe, 500 pontos!
Mensagens
1.864
Reações
1.099
Pontos
609
Esse jogo é interessante, pois todo mundo pensa que jogos 3D só podem ser feitos com polígonos e nesse Ecstatica e também no jogo Urban Decay, usa-se elipisóides.


Por que não usaram mais este formato? Parecia mais agradável aos olhos esses visuais arredondados ao invés dos polígonos pontiagudos da época...
 

Maxwelsoonage

Supra-sumo
Mensagens
212
Reações
948
Pontos
178
E essa pegadinha de Primeiro de Abril?




Pior que achei essa ideia muito boa.
Ele só exagerou na compressão dos cenários. Com o grande número de paletas do SNES, dá pra ficar quase igual ao original, idependente do modo gráfico escolhido.
Esse é um que fiz em Mode 1 (BG = 8 Paletas de 16 cores) dentro do Super Mario World:
Resident Evil DEMO000.png

E esse foi em homebrew mesmo, usando Mode 3 (BG = 256 cores):

Resident Evil 2 Fundos000.png

Os personagens feitos por bolas funcionaria muito bem. Fazer em sprite seria um grande problema pois os fundos possuem ângulos variados e profundidades diferentes. Imagine a penca de sprites necessários pra cada cena.
O difícil é programar esse tipo de coisa. Ballz 3D usou o chip DSP-1 pra poder calcular as posições 3D, esse também iria precisar, a menos que o programador seja bastante habilidoso e crie uma longa lista de cálculos pré-feitos.
 

*ka

Mil pontos, LOL!
Mensagens
11.821
Reações
11.548
Pontos
1.344
Séria muito melhor fazer um projeto imaginando como séria Super Mario para o SNES CD, já que o SNES só não teve esse acessório por desavença com a Sony.
Mas ao contrário do Sega CD aparentemente o drive de CD do snes não traria upgrades para hardware do consoles, seria só um drive de cd, mas daria para os jogos aproveitarem o maior espaço de armazenamento, porém na época o pessoal gastava esse espaço extra com músicas e fmv.
 

Wolkaiser

Bam-bam-bam
Mensagens
2.012
Reações
6.738
Pontos
283
Por que não usaram mais este formato? Parecia mais agradável aos olhos esses visuais arredondados ao invés dos polígonos pontiagudos da época...

Acredito que as ferramentas de modelagem 3D trabalhavam com triângulos e esses elipses eram feitos mais no braço.

Vi um comentário no post do Pikuma, de que TLOU usou essa técnica nas sombras do jogo.

 

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Eu acho bem mais feio.
Também me parece muito cartunesco e mais difícil de adicionar detalhes.
Daria muito trabalho pra fazer dessa forma, teria que ser feito manualmente, pois não se tinha uma ferramenta pra fazer esse tipo de modelagem, é uma técnica onde pegam os objetos e escolhem um ponto arbitrário (P) e rotacionam em volta do eixo Y (altura) e X (largura) desse mesmo objeto até ficar com formato arredondado.

Sem título2.png

Visualmente fica feio demais huahuahua, parecem um monte de balas jujuba.

Acho que a melhor maneira de adaptar Resident Evil pro SNES seria usando Mode 3 para ter 256 cores no BG (igual mostraram acima), dessa forma o BG não teria percas significativas, e nesse modo ainda teria o segundo BG com 128 cores pra fazer o HUD.

Para os personagens adaptaria usando vários meta-sprites com ângulos e profundidades diferentes, apesar de mais trabalhoso o resultado final seria muito melhor. Ou você escalona em tempo real (exigindo um ótimo programador) ou deixa tudo pré-calculado para ir trocando o tamanho e quantidade de sprites na V-RAM quando eles se aproximam ou afastam. Ambas opções dariam certo, mas a segunda seria mais fácil de executar.

Spectre é um jogo que faz isso muito bem, onde os objetos ficam trocando seus ângulos e escalonando, usando 4 sprites de 32x32 quando estão próximos e 4 sprites de 16x16 quando estão distantes.

Sem título.png



Seguindo essa mesma formula, considere esse cubo azul um personagem (Leon ou Claire) sendo escalonado, e usando sprites pré-renderizados para realismo, o resultado seria muito próximo do visual usando polígonos texturizados, vide o próprio Mario em New Super Mario Land que usa pré-render e se parece com sua versão 3D do Nintendo DS. Me diga se os personagens na tela de seleção em Doom Troopers não se parecem 3D.

Maxsteiner.gif

Nem tudo precisa ser polígono ou apelar para chips extras, os exemplos estão aí, o próprio Spectre é um jogo totalmente poligonal no PC e foi portado para o SNES com Mode 7 e sprites. Dá para replicar jogos 3D e manter os gráficos aproximados usando outros recursos, mas depende do jogo também.
 
Ultima Edição:

jadersnes

Ei mãe, 500 pontos!
Mensagens
1.864
Reações
1.099
Pontos
609
Daria muito trabalho pra fazer dessa forma, teria que ser feito manualmente, pois não se tinha uma ferramenta pra fazer esse tipo de modelagem, é uma técnica onde pegam os objetos e escolhem um ponto arbitrário (P) e rotacionam em volta do eixo Y (altura) e X (largura) desse mesmo objeto até ficar com formato arredondado.

Visualizar anexo 385793

Visualmente fica feio demais huahuahua, parecem um monte de balas jujuba.

Acho que a melhor maneira de adaptar Resident Evil pro SNES seria usando Mode 3 para ter 256 cores no BG (igual mostraram acima), dessa forma o BG não teria percas significativas, e nesse modo ainda teria o segundo BG com 128 cores pra fazer o HUD.

Para os personagens adaptaria usando vários meta-sprites com ângulos e profundidades diferentes, apesar de mais trabalhoso o resultado final seria muito melhor. Ou você escalona em tempo real (exigindo um ótimo programador) ou deixa tudo pré-calculado para ir trocando o tamanho e quantidade de sprites na V-RAM quando eles se aproximam ou afastam. Ambas opções dariam certo, mas a segunda seria mais fácil de executar.

Spectre é um jogo que faz isso muito bem, onde os objetos ficam trocando seus ângulos e escalonando, usando 4 sprites de 32x32 quando estão próximos e 4 sprites de 16x16 quando estão distantes.

Visualizar anexo 385850



Seguindo essa mesma formula, considere esse cubo azul um personagem (Leon ou Claire) sendo escalonado, e usando sprites pré-renderizados para realismo, o resultado seria muito próximo do visual usando polígonos texturizados, vide o próprio Mario em New Super Mario Land que usa pré-render e se parece com sua versão 3D do Nintendo DS. Me diga se os personagens na tela de seleção em Doom Troopers não se parecem 3D.

Visualizar anexo 385858

Nem tudo precisa ser polígono ou apelar para chips extras, os exemplos estão aí, o próprio Spectre é um jogo totalmente poligonal no PC e foi portado para o SNES com Mode 7 e sprites. Dá para replicar jogos 3D e manter os gráficos aproximados usando outros recursos, mas depende do jogo também.


É, vendo dessa forma, acho que a melhor solução seriam os cenários fixos e os sprites pré render. Mataria a pau. O falecido Project Dream da Rare era um bom exemplo de qualidade nesse sentido...
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Se conseguiram no GBC, no SNES seria algo possível creio.

Visualizar anexo 385867Visualizar anexo 385868

Tem um jogo do Scooby Doo para Mega Drive que é diferente da versão SNES. No mega o jogo é um adventure, com cenários com câmeras estáticas, bem ao estilo RE.


Possível é sem dúvidas. Alone in the Dark do GBC faz justamente isso que estava dizendo na outra postagem, backgrounds pré-renderizados com sprites fazendo escalonamento. Essa seria a melhor escolha para um eventual porte de Resident Evil.

No GBC não daria pra ter backgrounds pré-renderizados detalhados igual no SNES (muito menos sprites), pois são apenas 8 paletas de 4 cores para o background e 8 paletas de 3 cores para os sprites, mas mesmo assim fizeram isso tudo nesse jogo. Agora imagina no SNES como ficaria.

AITD.gif
 

Maxwelsoonage

Supra-sumo
Mensagens
212
Reações
948
Pontos
178
Alone in the Dark de GBC não altera o ângulo da câmera, dá pra reaproveitar os mesmos frames do personagem pra todas as telas. As de Resident Evil não, tem alguns que parece câmera de segurança filmando de cima, outros ficam na altura da cintura etc.
Teria que ter essa adaptação pra usar sempre o mesmo ângulo, pois são muitos frames pra todos os movimentos e distâncias, imagine pra ângulos diferentes.
Dando um jeito nisso, acho perfeitamente possível.

Usar fundos em 8bpp apertaria demais na VRAM, limitando o número de inimigos. No exemplo que usei, a imagem é de 256x200 e sobraram 368 tiles pros sprites (o máximo são 512).
Talvez seja o suficiente se não tiver mais que 2 zumbis em tela.

Pra ter mais espaço pra inimigos e pra outra camada, só diminuindo ainda mais o tamanho do fundo... ou usando o Mode 1 padrão mesmo. É possível que mudando as cores a cada linha usando HDMA ajude a melhorar o visual limitado do 4bpp.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Alone in the Dark também altera o ângulo de visão dos sprites, onde igual em Resident Evil o personagem fica por cima em determinadas partes.

Alone in the Dark - The New Nightmare (Europe) (En,Fr,De,Es,It,Nl)_002.png

Como os sprites trocam na V-RAM em telas onde o ângulo muda, não teria o problema de faltar tiles. Seria mais uma questão de adaptação mesmo.

192 tiles para os sprites seriam suficientes, 64 para o personagem principal e 64 para 1 zumbi, o restante para algum outro inimigo. Spectre usa 32 tiles quando o cubo está o mais próximo da tela possível e com todos os frames, mas espelha pra completar a parte de baixo, por ser um cubo não dá diferença porque as tiles de cima podem ser repetidas em baixo.

Levando isso em conta, no caso de Resident Evil gastariam 64 tiles no Leon e 64 em 1 zumbi (por não ter como espelhar). Nesse cenário estaria gastando 128 tiles (Leon e zumbi), sobrando 64 para algum outro inimigo que gaste tiles diferentes. Para mais zumbis sprite multiplexing resolveria, como todos os zumbis são praticamente iguais daria pra fazer, aí o número deles em tela só dependeria de quantos deles você quer colocar.
 

Maxwelsoonage

Supra-sumo
Mensagens
212
Reações
948
Pontos
178
Para mais zumbis sprite multiplexing resolveria, como todos os zumbis são praticamente iguais daria pra fazer, aí o número deles em tela só dependeria de quantos deles você quer colocar.
Isso exigiria botar todos os frames dos zumbis nesse espaço, que até mesmo no limite padrão de 512 tiles já seria muito apertado.
A ideia de 1 jogador + 2 zumbis é a mais possível mesmo.
Eu já pensei em fazer uma demo disso, mas precisaria de todos os frames do Leon e dos zumbis em um fundo de cor sólida. Algo impossível de achar por ser um jogo 3D.
 

Warrior Of Light

Bam-bam-bam
Mensagens
1.229
Reações
4.606
Pontos
453
Isso exigiria botar todos os frames dos zumbis nesse espaço, que até mesmo no limite padrão de 512 tiles já seria muito apertado.
A ideia de 1 jogador + 2 zumbis é a mais possível mesmo.
Eu já pensei em fazer uma demo disso, mas precisaria de todos os frames do Leon e dos zumbis em um fundo de cor sólida. Algo impossível de achar por ser um jogo 3D.
Não precisa ser algo com muitos frames igual ao original, mas reduzido pra caber nessa limitação de 512 tiles. Considerando um cenário com 192 tiles e 64 tiles para 1 zumbi daria pra fazer também, sobrando 64 tiles para o Leon e 64 tiles para os frames dos zumbis multiplexados ou outro inimigo com tiles diferentes.

Todos os frames do Leon num fundo de cor sólida? Se você quiser eu te mando todos eles, na internet você não vai achar mesmo não, pois tem que ser feito manualmente, extraindo frame por frame a geometria do personagem e salvando aos poucos.

Leon.png
 
Topo Fundo