Pregunta rápida (bueno, no xD) sobre la resolución en snes...

Archivado
Buenas.

Entrando en materia, en la snes existe un modo gráfico que permite usar una resolución de hasta 512x448, la cual dispone de 2 layers por hardware, uno de 16 colores, y otro de 4.

Sobre la resolución vertical, y horizontal, existe una implicación diferente para cada de distintas partes del hardware.
La resolución vertical requiere de un uso intensivo de la cpu, mientras que la resolución horizontal requiere de un uso intensivo de las PPU's. Cuánto mayor sea el número de sprites dispuestos en vertical, menor será el tiempo de la cpu para dibujarlos todos... y cuánto mayor sea el número de pixels a dibujar en horizontal, menor será el número de sprites a dibujar en cada scanline.

El motivo es sencillo. De generar los scanlines se encarga el sistema de vídeo, y tiene un límite debido a la tasa de relleno de pixels... pero en su resolución vertical la disposición es todo lo que la cpu sea capaz de mover y/o transferir las tablas OAM (coordenadas de los sprites para ser dibujados), porque la imagen vertical ya está compuesta por líneas horizontales, y no hay que hacer ningún esfuerzo para componerla (la imagen vertical) .
Es decir, a 256x224 puedes dibujar 32 sprites o 34 slives por scanline (horizontal) como máximo (y no permite mas aunque te sobre cpu), pero en vertical puedes poner los 128 sprites que permite el hardware sin ningún problema porque en ningún scanline excedes del límite de los PPU's. Este es el motivo por el que para lo vertical necesitas mas cpu, y para lo horizontal mas potencia de vídeo.



Bien, una vez explicadcas la premisas, me surgen un par de dudas.

Si escojo el modo 5 de vídeo, y establezco una resolución de 512x448, lo que obtengo es una limitación de potencia que implica que la tasa de relleno de pixels para la resolución horizontal se reduce a la mitad, y que la cpu tiene ahora potencialmente menos tiempo para mover objetos en pantalla si pretendes sobrecargar una escena (mayormente en vertical, aunque el area es general, claro). Es decir, que puedo dibujar 512 pixels de ancho, si, pero...

1º ¿La suma de los sprites por scanline no puede exceder de 512 pixels, o 128 pixels?. La lógica me dice que 512, porque es el número de pixels que puede dibujar el sistema de vídeo, y da igual si pertenecen a tiles de sprites, o tiles de layers... pero prefiero preguntar, porque con la snes nunca se sabe.

2º El número de sprites por scanline se reduce a 16 sprites (de 8x8, 16x16, 32x32, o 64x64), pero, ¿el número de slives tambien se reduce a la mitad?, o se mantiene en 34.

3º La resolución de 512 pixels horizontales tiene como consecuencia la reducción de poder aplicar 4 ciclos de reloj por pixel, a solo poder aplicar 2 ciclos de reloj por pixel. Lo primero que se deja notar es la mencionada reducción en el manejo de sprites (de 32 a 16), pero, ¿existe alguna limitación en la capacidad para rasterizar?, ¿tal vez aplicar efectos como alpha blending?, ¿morphing?. Menos ciclos de reloj por pixel implica menos poder de computación, así que en algo mas debería haber limitación... ¿o no?.
Me autorespondo:

1º A 512x448 la snes puede dibujar 304 pixels de sprites por scanline.

2º ?

3º ?
Duda: ¿estas preguntas no deberías quizás plantearlas en el foro de desarrollo? Me refiero, si acaso estás trabajando con la SNES y tienes algunas dudas sobre su hardware seguro que allí te pueden resolver mejor esas dudas :-).

Respecto al uso de CPU y VDP, vaya arquitectura rara ¿no? Normalmente la gestión de lineas tanto horizontales como verticales debería correr a cargo del VDP exclusivamente, y a mayor resolución mayor carga del mismo. No tiene sentido delegar en la CPU este tipo de tareas salvo por carencias en el diseño.
Hay un juego de coches que usa la alta resolución de snes, se llama RPM racing (alias rock'n roll racing 0.5):
https://www.youtube.com/watch?v=OyvecUB5xp4

Cosas a tener en cuenta:
-los coches son low res
-los colores se limitan a 16 en pantalla
-la secuela optó por baja resolución
AxelStone escribió:Duda: ¿estas preguntas no deberías quizás plantearlas en el foro de desarrollo? Me refiero, si acaso estás trabajando con la SNES y tienes algunas dudas sobre su hardware seguro que allí te pueden resolver mejor esas dudas :-).


Pues la verdad es que no sabía que tuviéramos un foro de eso, primera noticia ^^

AxelStone escribió:Respecto al uso de CPU y VDP, vaya arquitectura rara ¿no? Normalmente la gestión de lineas tanto horizontales como verticales debería correr a cargo del VDP exclusivamente, y a mayor resolución mayor carga del mismo. No tiene sentido delegar en la CPU este tipo de tareas salvo por carencias en el diseño.


Tambien yo me explico un poco de aquella manera.

En vertical puedes poner todos los sprites que la tabla OAM del hardware permita, pero eso es así en todas las máquinas, megadrive, snes, nes... etc.

El motivo es sencillo, los gráficos se dibujan horizontalmente, y por lo tanto la imagen se compone así, a base de líneas horizontales. Es por esto que las restricciones se fijan horizontalmente, y no verticalmente, y por lo tanto, al poder poner mas sprites en vertical que en horizontal, la cpu se ve mas comprometida al moverlos, por el simple motivo de que estás poniendo mas.

Es decir, no es que estés poniendo sprites en vertical, es que de esa forma no estás sobresaturando scanlines que tienen unos límites.

P.D: Me parece que ha quedado igual de claro que antes xD

estoybien escribió:Hay un juego de coches que usa la alta resolución de snes, se llama RPM racing (alias rock'n roll racing 0.5):
https://www.youtube.com/watch?v=OyvecUB5xp4

Cosas a tener en cuenta:
-los coches son low res
-los colores se limitan a 16 en pantalla
-la secuela optó por baja resolución


Las limitaciones son bastante fuertes, si... pero creo que el mal aspecto del juego se debe mas a una excesiva repetición de tiles, y no se si se podría mejorar.

Trabajar con esa resolución hace imposible poner tantos tiles diferentes en pantalla para los fondos como en el modo 256x224, y si encima llenan físicamente la mitad, pues ya apaga y vámonos, pero de todos modos me da la sensación de que la VRAM da para un poquito mas.

Al menos puede moverlo, que no es poco XD
estoybien escribió:Hay un juego de coches que usa la alta resolución de snes, se llama RPM racing (alias rock'n roll racing 0.5):
https://www.youtube.com/watch?v=OyvecUB5xp4

Cosas a tener en cuenta:
-los coches son low res
-los colores se limitan a 16 en pantalla
-la secuela optó por baja resolución


Joder el juego apesta, en buena hora decidieron hacerlo en high res. Supongo que ese modo no estaba destinado a la creación de juegos.

@Señor Ventura Sí tenemos un foro de Desarrollo, pero está muy parado, casi mejor prueba en foros especializados de desarrollo de SNES. La limitación horizontal es tan vieja como la vida misma, creo que ya se comentó una vez. Piensa que el VDP dispone de 1/60 segundos para pintar el fotograma, llamémoslo ciclo. En 1 ciclo, debes pintar todas las líneas, si tenemos por ejemplo 212 lineas cada una de ellas debe pintarse en 1/212 ciclos. El VDP siempre pinta primero el plano de fondo y luego superpone los sprites, por lo que el está garantizado que se dibuja el fondo y luego dibujará tantos sprites como tenga tiempo.
AxelStone escribió:Joder el juego apesta, en buena hora decidieron hacerlo en high res. Supongo que ese modo no estaba destinado a la creación de juegos.


Es que a 16 colores, como no hagas algo en blanco y negro va a cantar demasiado xD

Blanco y negro, y colores sin ningún tipo de degradado, es la única manera de que quede "bien". De todos modos, es la repetición de tiles la que le sienta como un tiro, o plantas algo en plan minimalista, con espacios sin dibujar en lugar de rellenar con toneladas de tiles de 8x8 repetidos, o el resultado ya vemos el que es.

AxelStone escribió:@Señor Ventura Sí tenemos un foro de Desarrollo, pero está muy parado, casi mejor prueba en foros especializados de desarrollo de SNES.


De momento prefiero no entrar de lleno, que me conzco. Al menos hasta el verano, que termine el curso y pueda encerrarme en mi cuarto con mis ideas.

AxelStone escribió:La limitación horizontal es tan vieja como la vida misma, creo que ya se comentó una vez. Piensa que el VDP dispone de 1/60 segundos para pintar el fotograma, llamémoslo ciclo. En 1 ciclo, debes pintar todas las líneas, si tenemos por ejemplo 212 lineas cada una de ellas debe pintarse en 1/212 ciclos. El VDP siempre pinta primero el plano de fondo y luego superpone los sprites, por lo que el está garantizado que se dibuja el fondo y luego dibujará tantos sprites como tenga tiempo.


¿En los hardwares antiguos afecta algo a la capacidad de dibujado de los scanlines si estableces la velocidad de refresco a 30fps?, o el pixel fill rate es el que es, y da igual lo que hagas.
Hace un tiempo, modifique el codigo del zsnes de dos para soportar resolucion nativa. Bajate el source del zsnes, y parti de los archivos que modifique

Tenes las respuestas a tus preguntas de una manera tecnica, porque lo primero que se delimitan son los limites en el codigo

http://board.zsnes.com/phpBB3/viewtopic.php?f=2&t=137530

Es ensamblador de intel, algo durillo, pero se entiende relativamente facil
theelf escribió:Hace un tiempo, modifique el codigo del zsnes de dos para soportar resolucion nativa. Bajate el source del zsnes, y parti de los archivos que modifique

Tenes las respuestas a tus preguntas de una manera tecnica, porque lo primero que se delimitan son los limites en el codigo

http://board.zsnes.com/phpBB3/viewtopic.php?f=2&t=137530

Es ensamblador de intel, algo durillo, pero se entiende relativamente facil


Gracias theelf, ahí que voy!!
Señor Ventura escribió:Las limitaciones son bastante fuertes, si... pero creo que el mal aspecto del juego se debe mas a una excesiva repetición de tiles, y no se si se podría mejorar.

Trabajar con esa resolución hace imposible poner tantos tiles diferentes en pantalla para los fondos como en el modo 256x224, y si encima llenan físicamente la mitad, pues ya apaga y vámonos, pero de todos modos me da la sensación de que la VRAM da para un poquito mas.

Al menos puede moverlo, que no es poco XD


Si es para probar, creo que sería factible intentar portear algo de un sistema superior (por ejemplo, de algún arcade concreto); supongo que será la manera más sencilla de hacer probaturas para tratar de explotar un sistema, porque si hay que comerse la cabeza para crear desde 0 algo interesante que estruje cualquier aspecto concreto de las prestaciones de snes... puff.

Ya sabes que no entiendo mucho de esto, pero creo que lo suyo es eso, demakeo hasta que la consola lo resista.
Posteo esto para tenerlo a mano. Podeis ignorarlo xD

http://atariage.com/forums/topic/161400-people-should-stop-freaking-out-about-the-sness-cpu/page-3

http://atariage.com/forums/topic/159269 ... try1977472


That's a bit silly... complaining about actual slowdown is one thing, but going into random technical stuff for those who don't have a clue what they're saying is BS. (some reviewers aren't clueless though, in which case it's legitimate IMO)

The 2 systems do have a good deal of trade-offs, some of which are personal taste (like the sound), though A/V output quality varies much more widely on different Genesis revisions than the SNES (or TG-16/PC-Engine), RGB is rock solid on all models for users with that option (ie JP and EU users), but Composite video tends to be a fair bit weaker on the Genesis (varies a good bit as 4 different video encoders were used on various models) and RF is often down right mediocre (average at best), the sound is poor on the final revision of the model 1 systems and several model 2 revisions, though the Genesis 3 is generally decent (but mono only) and composite tends to be good too, the CXS, X'Eye and such tend to have good sound too. (the WonderMega even had S-video output unlike other stock consoles)

Comparing the hardware itsself always gets a bit hairy, the SNES has more subpalettes (16 to the gen's 4, TG-16 has 32), and 15-bit RGB master palette to the Geny's 9-bit (like Atari ST and PC-Engine/TG-16), resolution (MD has the 320 wide mode, SNES is stuck at 256 for all intents and purposes), and the CPU.
Comparign the CPUs is a bit touch due to the very different architectures, the 65816 has faster but less powerful instructions, 8-bit bus with 1 cycle accesses vs 16-bit bus with slow accesses, needing more accesses due to limited registers, etc etc. Overall, from previous discussions, at 3.58 MHz, the SNES's CPU is still more than 1/2 as fast as a 7.67 MHz 68k, I seems to remember it coming down to around 70-80% in such a discussion, but the other problem is that the SNES's CPU is stuck at 2.68 MHz much of the time (DRAM is limited to that and many games use cheaper ROM on a 2.68 MHz bus). It was noted that in cases of a couple re-releases of games that switched from 2.68 MHz ROM to 3.58 MHz ROM, slowdown was noticeably reduced. (SMW compared to SMW Allstars was one example)

I've wondered why Nintendo opted for such a slow clock speed when a far higher one should have been easily possible, this thread shed some more light on the issue: http://www.atariage....72#entry1977472
So unlike a normal 6502 or 65C02, the way the 65816 is set-up with multiplexed addressing means that memory had to be clocked 2x as fast as the CPU, that's even more extreme when you compare it to things like the Z80 and 68000 which have multi-cycle memory accesses, allowing RAM to be slower than the CPUs. (650x needs memory at equal speed to not have wait states)

There is, of course, other discussions involving not the SNES vs Genesis CPU, but bringing the PCE/TG-16's 7.16 MHz 65C02 derivative into the fray as well, and that only complicates things more. (it's generally got a big advantage over the SNES's CPU and, depending on the case, a speed advantage over the 68k too, with equivalent optimization -as a very vague summary) Again, that's just complicates matters.
10 respuestas
Archivado
Volver a Consolas clásicas