Hilo técnico de consolas 2D

@cirote3 otros como MK2 y el Sunset Riders fueron muy buenos también
@cirote3 Sí, al final fueron dos filosofías de diseño de hardware diferentes lo que hace que hayan tenido exclusivos tan difíciles de llevar a una consola u otra de la misma manera. También esto desmitifica muchas cosas porque han ido por caminos distintos y han recibido tratos desiguales en cuanto a la compañías que han hecho juegos para ellas.

Por alguna razón, en los últimos años la gente parece separarse bastante más del marketing de los 90 y parece como que hay más público técnico (y adulto) al que no le van a clavar que le digan, por ejemplo, "las instrucciones se ejecutan a la mitad de ciclos de esta consola" cogiendo ese dato suelto sin contexto cuando los ciclos tienen su propia velocidad según que consola o que no dispongan de instrucciones equivalentes como para hacer comparativas cuando lo que hay que mirar es el Tiempo X Tarea buscando un denominador común si se quieren hacer comparaciones.
M68K escribió:Por alguna razón, en los últimos años la gente parece separarse bastante más del marketing de los 90 y parece como que hay más público técnico (y adulto) al que no le van a clavar que le digan, por ejemplo, "las instrucciones se ejecutan a la mitad de ciclos de esta consola" cogiendo ese dato suelto sin contexto cuando los ciclos tienen su propia velocidad según que consola o que no dispongan de instrucciones equivalentes como para hacer comparativas cuando lo que hay que mirar es el Tiempo X Tarea buscando un denominador común si se quieren hacer comparaciones.

Supongo que es resultado de que cada vez haya más gente interesada en hacer juegos para sistemas retro y documentación fácil de digerir para ellas.
Snes escribió:Está demo está interesante
https://x.com/inceptionalnews/status/20 ... 28732?s=46

Acaban de publicar la ROM de la demo: https://archive.org/details/bigger-boo

Además de la ROM, incluyen un readme.txt en el que explican bastantes cosas de la demo. Tenía curiosidad sobre cómo escalaban el Boo gigante en tiempo real. El readme.txt lo explica: no se escala en tiempo real, en el cartucho están almacenados todos los tamaños del Boo disponibles:

There are 53 different sizes of Bigger Boo on this cartridge, from full size down to half, one for every pixel his outline moves.
@cirote3 y qué es, ¿Un plano hecho con tiles?
sgonzalez escribió:@cirote3 y qué es, ¿Un plano hecho con tiles?

Es un plano en modo 0 (4 colores por tile):

Imagen

En la imagen se pueden ver fallos gráficos parecidos a los de las imágenes JPG: se deben a que el plano ha sido cuantizado para reducir el número de tiles únicos y gastar menos tiempo de V-Blank en copiarlo a la VRAM. Para mi juego hice un cuantizador para lo mismo y para reducir el tamaño de la ROM, ese tipo de fallos gráficos me suenan bastante XD
cirote3 escribió:
sgonzalez escribió:@cirote3 y qué es, ¿Un plano hecho con tiles?

Es un plano en modo 0 (4 colores por tile):

Imagen

En la imagen se pueden ver fallos gráficos parecidos a los de las imágenes JPG: se deben a que el plano ha sido cuantizado para reducir el número de tiles únicos y gastar menos tiempo de V-Blank en copiarlo a la VRAM. Para mi juego hice un cuantizador para lo mismo y para reducir el tamaño de la ROM, ese tipo de fallos gráficos me suenan bastante XD


Y que es un algoritmo que se aplica ¿o como va?, ¿tambien serviria eso mismo para reducir el número de colores para megadrive por ejemplo?
naxeras escribió:
cirote3 escribió:
sgonzalez escribió:@cirote3 y qué es, ¿Un plano hecho con tiles?

Es un plano en modo 0 (4 colores por tile):

Imagen

En la imagen se pueden ver fallos gráficos parecidos a los de las imágenes JPG: se deben a que el plano ha sido cuantizado para reducir el número de tiles únicos y gastar menos tiempo de V-Blank en copiarlo a la VRAM. Para mi juego hice un cuantizador para lo mismo y para reducir el tamaño de la ROM, ese tipo de fallos gráficos me suenan bastante XD


Y que es un algoritmo que se aplica ¿o como va?, ¿tambien serviria eso mismo para reducir el número de colores para megadrive por ejemplo?

No sé lo que han hecho ellos, pero lo que hice yo (y por lo que leí hacen otros) es buscar los dos tiles del fondo que más se parecen y fusionarlos. Eso se hace una y otra vez hasta que el número de tiles es suficientemente bajo o la imagen se ve demasiado mal XD

Hay que tener en cuenta que los tiles de un fondo que no es de modo 7 se pueden invertir en los dos ejes (horizontal y vertical), por lo que al buscar los dos tiles que más se parecen hay que invertirlos en los dos ejes.

El objetivo es reducir el número de tiles, no el número de colores, por lo que normalmente el número de colores del fondo cuantizado es mayor que el del original. Para reducir el número de colores de un fondo, lo que mucha gente suele usar incluido yo es el cuantizador de paletas de Rilden: https://rilden.github.io/tiledpalettequant/
No sé si la he puesto alguna vez, pero en esta página hacen un repaso a algunas de las consolas, los micros y las placas arcade más populares de los 80 y 90 a la hora de mostrar sprites: https://upsilandre.over-blog.com/2022/1 ... ratif.html

Aunque en el artículo avisan varias veces de que el funcionamiento de cada una no se debería resumir en una tabla, ahí va la tabla XD

Imagen

En la tabla se miden los sprites por hardware, sin intervención de la CPU. Se ignoran los modos de alta resolución y el multiplexado de sprites. Aunque recomiendo leer el artículo traducido a algo que se entienda, hago un resumen de las plataformas que conozco:

NES, SMS y Game Boy: los sprites de la NES son parecidos a los de la SMS salvo por la mitad de profundidad de color, lo que hace que en algunos juegos como en el Megaman se superpongan varios sprites para mostrar más colores, haciendo más fácil los parpadeos. A su favor la NES tiene otras cosas como poder invertir sprites o poder mostrarlos detrás del fondo. La Game Boy muestra más sprites por scanline y encima la pantalla es más estrecha, por lo que es la mejor a la hora de llenar la pantalla con sprites.

Las consolas de 16 bits:
  • La PC Engine es la que tiene más paletas para sprites (16), pero le falta el tamaño más pequeño (8x8 píxeles), lo que obliga a malgastar sprites de 16x16 en disparos pequeños.
  • El autor considera que la Mega Drive es la mejor ya que puede mostrar sprites de muchos tamaños y encima multiplexarlos. El gran inconveniente es el de siempre: solo hay 4 paletas de colores y encima hay que compartirlas con los fondos.
  • La SuperGrafx es dos PC Engines pegadas con cinta aislante XD: en la tabla queda muy bien pero en la práctica es difícil de aprovechar bien ya que hay que saber repartir bien los sprites y los tiles de sprites entre las dos "GPUs".
  • De la SNES se comenta lo que hablaba en el primer mensaje del hilo: la tabla de atributos de sprites tan pequeña obligó a meter como limitaciones solo dos tamaños de sprites simultáneos en pantalla y solo 256 píxeles para el eje Y, lo que hace que los sprites de 64 píxeles de alto puedan mostrarse abajo y arriba de la pantalla a la vez. También dice que los 128 sprites en pantalla son una ventaja difícil de aprovechar en la práctica. A cambio hay 8 paletas de colores, color de 15 bits en vez de 9 y transparencias, algo que ni Neo Geo ni CPS tienen.

Neo Geo: es tan buena a la hora de mostrar de sprites ya que casi todo se muestra con ellos. Permite mostrar sprites muy altos y engancharlos con otros sprites, con lo que es muy fácil construir un fondo a base de sprites sin gastar CPU. Además permite encoger sprites sin afectar al número de sprites por scanline.

CPS1: es el perro verde de la tabla XD: en vez de mostrar los sprites por scanline, los renderiza en un framebuffer (como la Saturn) y los muestra al frame siguiente. Eso evita los parpadeos de sprites a costa de reducir el número de sprites en pantalla y a meter un frame de lag. Comentan que el sistema de sprites del X68000 no tiene nada que ver con el del CPS1.

En el artículo me faltan algunas plataformas más como la Game Gear, la Lynx, las CPS 2 y 3 y algún pepino tipo System 32. Comento otras dos que faltan de las que sé un poco más, la GBA y la DS:

GBA: tiene 128 sprites en pantalla, 16 paletas de colores en vez de las 8 de la SNES y 256 colores por sprite: ninguna de las plataformas del artículo es capaz de mostrar más de 16 colores por sprite. Permite multiplexar sprites como la Mega Drive y escalar y rotar sprites: a diferencia de la Neo Geo, también puede agrandarlos, no solo encogerlos. Como es lógico elimina el límite de dos tamaños de sprites simultáneos de la SNES y aumenta el rango del eje Y a 512 píxeles, por lo que no hay problema en mostrar sprites de 64 píxeles de alto en la parte baja de la pantalla. Tiene 1210 píxeles de sprites por scanline, lo que la hace mejor que la Neo Geo en este sentido ya que la resolución de la pantalla es más pequeña, y eso que encima la GBA tiene otras cuatro capas de fondos. Lo malo es que escalar y rotar sprites consume muchos más píxeles de sprites, por lo que hay que evitarlo siempre que sea posible. Encima tienen transparencias aditivas más potentes que las de PSX.

DS: en general son iguales que en la GBA (no me quiero enrollar más XD), pero con 1536 píxeles de sprites por scanline en vez de 1210. Lo que hacían muchos juegos como los Castlevania era usar además los polígonos 3D como sprites 2D, ya que permitían muchas ventajas como transparencias por píxel, mostrar un sprite transparente encima de otro, mostrar sprites que ocupen toda la pantalla, mostrar muchos más píxeles de sprites por scanline, etc. Me gustaría ver un port del Outrunners o algo del estilo en la DS, la consola es un pepino a la hora de llenar la pantalla con sprites :)
@cirote3 efectivamente el sistema de sprites de X68000 no tiene nada que ver con el del CPS1, es más parecido al de snes
X68000
Cantidad Hasta 128 Sprites simultáneos en pantalla
Tamaño cada Sprites mide 16x16 pixeles
Memoria dedicada: Disponible de 32KB de ram estática y 16KB específico para la gestión de Sprites
Paleta y colores: los Sprites pueden utilizar los colores de una paleta total de 65536 colores.
Cantidad de Sprites por línea de escaneo (scanline)32 Sprites
Snes escribió:@cirote3 efectivamente el sistema de sprites de X68000 no tiene nada que ver con el del CPS1, es más parecido al de snes
X68000
Cantidad Hasta 128 Sprites simultáneos en pantalla
Tamaño cada Sprites mide 16x16 pixeles
Memoria dedicada: Disponible de 32KB de ram estática y 16KB específico para la gestión de Sprites
Paleta y colores: los Sprites pueden utilizar los colores de una paleta total de 65536 colores.
Cantidad de Sprites por línea de escaneo (scanline)32 Sprites

La verdad es que no conocía nada del sistema de sprites del X68000, tener eso en tu casa en el 87 tenía que ser la hostia XD

Estaba bastante por encima de las consolas de 16 bits a la hora de evitar parpadeos (512 píxeles de sprites por scanline vs los 320 de la Mega Drive o los 272 de la SNES). Por eso dicen en el artículo que el port del Final Fight soportaba dos personajes y cuatro enemigos a resolución CPS1 sin parpadeos.
@cirote3 así mismo estaba bastante por encima de las 16bits y ese port de final fight quedó súper bien
Dejo un video sobre cómo funcionan los sprites y scrolls en MSX bastante interesante:

62 respuestas
1, 2