sgonzalez escribió:@cirote3 y qué es, ¿Un plano hecho con tiles?
cirote3 escribió:sgonzalez escribió:@cirote3 y qué es, ¿Un plano hecho con tiles?
Es un plano en modo 0 (4 colores por tile):
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
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):
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
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?
/image%2F2902198%2F20221028%2Fob_eb8770_hardsprite-comparison.png){kind=icon}
: 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". : 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.), 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 
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
7Force escribió:Dejo un video sobre cómo funcionan los sprites y scrolls en MSX bastante interesante:
Snes escribió:Está es la demo de ( Mickey Magic)que puse en Novedades pero ahora le agregaron los sprites de Mickey y unos hongos a lo largo de la pantalla cero flickering, lo malo es que todavía no hay ROM
https://x.com/biospark88/status/2099305550882414888
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
Snes escribió:@cirote3 El autor dice que tomaría 1% de la CPU el comentario está en el enlace ,lo que no dice cuánto con los efectos de iluminación
https://x.com/inceptionalnews/status/20 ... 07982?s=46
cirote3 escribió:Snes escribió:@cirote3 El autor dice que tomaría 1% de la CPU el comentario está en el enlace ,lo que no dice cuánto con los efectos de iluminación
https://x.com/inceptionalnews/status/20 ... 07982?s=46
Sin los rayos de luz esa demo no deja de ser cuatro fondos moviéndose, no debería chupar mucho
Snes escribió:cirote3 escribió:Snes escribió:@cirote3 El autor dice que tomaría 1% de la CPU el comentario está en el enlace ,lo que no dice cuánto con los efectos de iluminación
https://x.com/inceptionalnews/status/20 ... 07982?s=46
Sin los rayos de luz esa demo no deja de ser cuatro fondos moviéndose, no debería chupar mucho
Aquí tienes tu respuesta aproximadamente un 45% de la CPU el la ultima versión con los Sprites incluido
https://x.com/inceptionalnews/status/20 ... 34923?s=46
cirote3 escribió: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
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
- 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
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
Snes escribió:@cirote3 dice que todo lo que se ve en la pantalla supone una media de alrededor del 45% de la CPU, más o menos. ( sin optimizar) muy importante esta parte
How much CPU does this demo use?
That's something I'm actually trying to figure out. I can't for the life of me work out how to get accurate total CPU usage figures in Mesen. Apparently, maybe, everything you see onscreen in the latest version is about 45% CPU on average or thereabouts.
¿Cuánta CPU consume esta demo?
Eso es precisamente lo que estoy intentando averiguar. Por más que lo intento, no consigo averiguar cómo obtener cifras precisas del uso total de la CPU en Mesen. Al parecer, quizá, todo lo que se ve en pantalla en la última versión consume una media de alrededor del 45 % de la CPU, más o menos.
naxeras escribió:Yo siempre he pensado que el hardware puramente 2D más potente de la historia es System 32, yo al menos no conozco un monstruo semejante en otro sitio, ¿Es esto correcto o hubo hardware puramente 2D más potente que esto?
Si mal no me equivoco son :
-> 4 planos con scroll multidireccional.
-> 8.192 sprites simultaneos que puede ser desde 8x8 a 2048×2048.
-> Escalado y rotaciones los sprites.
-> Efectos de transparencias.
Menudo pepinaco pero me pregunto si hay algo más potente en 2D puro (sin hacer trampas con los poligonos).
Un Saludo.
cirote3 escribió:Ahora dicen que no lo habían probado en una SNES de verdad y hay fallos gráficos
cirote3 escribió:Ahora dicen que no lo habían probado en una SNES de verdad y hay fallos gráficos
naxeras escribió:sgonzalez escribió:@naxeras System 32 no tiene rotaciones en sprites.
Lo busque en la IA y se lo habrá inventado de puta madre...
Gracias por la corrección.
7Force escribió:Muy interesante eso del uso de la CPU.
¿Cómo se puede saber el % que se usa? En general, digo, no en un juego específico.
Snes escribió:cirote3 escribió:Ahora dicen que no lo habían probado en una SNES de verdad y hay fallos gráficos
Aquí en este enlace muestran los fallos gráficos
https://x.com/biospark88/status/2099559 ... 22991?s=46
cristus escribió:@cirote3 la sh1 usa algunos chps de saturn por lo que vi en las specs, igual no entiendo mucho pero tal vez tenga algún chip especifico que dificulte un hipotético port , se que con system 32 pasaba, siendo saturn mas potente....
M68K escribió:@cirote3 Por reforzar un poco lo que comentas, me he descargado la demo para probarla y hay algunas cosas también interesantes que he encontrado:
- He visto que la ROM es de 1MB (para haceros una idea, 2 veces más grande que Mario Kart y del tamaño de Batman Returns completo de SNES).
- Es un bucle simple de desplazamiento de scroll de capas, corto, el tilemap actualiza posiciones para "alargar" el bucle pero no cambian los tiles en VRAM (aunque hay ciertas variaciones por HDMA)
- No hay sonido.
- También se me corrompen los efectos de luz en HW real con los haz de luz (¿Se queda sin tiempo durante HBlank?)
Con esto quiero decir que, sin haber tanto detalle, sonido o grandes cambios y con tiles de 2bpp la ROM me parecía demasiado grande...
Esta rutina que he encontrado en el código copia datos desde ROM directamente a VRAM, sin una rutina de descompresión entre medias:
$8083E9
LDA #$5C00
JSR $828A
Donde $828A termina haciendo:
LDA [$11]
STA $2118
Esto es, los datos van de ROM a VRAM directamente sin procesar. Normalmente, cuando los gráficos están comprimidos, se descomprimen en WRAM y posteriormente se transfieren a VRAM mediante DMA. Sin tener que descomprimir, se libera una carga considerable de CPU, o mucha según algoritmo de comprensión.
Aunque no puedo asegurarlo al 100% (lo que sí es seguro es que no he visto rutina de descompresión y solamente accesos de ROM a VRAM) estos gráficos podrían estar ocupando todo ese espacio al no estar comprimidos. No es que sea malo ni mucho menos, pero es un trade off del cambio de Rendimiento X Memoria, un escenario que ayuda a ver lo que se ve.
El desafío estaría verlo en un juego con todas rutinas de un plataformas y que todo entrase en el cartucho y en la lógica del propio juego. Pero como demo únicamente visual de rutinas precalculadas es muy bonito aún con el limitante de color del modo 0.
