¿Que impone que los sprites tengan un límite por scanline?

A ver si entiendo tu pregunta: ¿por qué los sprites flickean básicamente? La respuesta en verdad es simple: límites del VDP. Los VDP se diseñan con 2 capacidades diferenciadas:

• Capacidad de fondos: por ejemplo,1 plano de scroll.
• Capacidad de sprites: por ejemplo, 32 sprites de 8x8.

Para el VDP el tratamiento de ambas cosas van por separado. Por un lado debo pintar el fondo y luego pintar los sprites. Ese límite de 32 sprites es tu techo, lo máximo que puede gestionar, pero una cosa es gestionarlos y otra dibujarlos. Así por ejemplo aunque un sprite haya desaparecido por completo a causa del flickeo, el VDP sabe que está ahí y puede colisionar con otros. Es decir, no lo dibuja pero sí lo gestiona.

¿Y por qué no lo dibuja? Por su límite de capacidad de dibujo. Los VDPs pintan la pantalla mediante escaneo horizontal de la pantalla. Supongamos un sistema con 256x192 pixels. Esto da que en 1/60 segundos debe pintar 192 lineas horizontales. Para poder hacerlo no puede "retrasarse" más de la cuenta pintando una línea. ¿Cómo lo gestiona? Si veo que la linea en curso tiene muchos sprites, no los dibujo, ya que el fondo SIEMPRE se va a dibujar.

Básicamente, fue una estrategia que se usó para superar las limitaciones.

Entiendo... es una cuestión de que un sistema gráfico no es lo suficientemente rápido para dibujar un scanline a partir de determinados kb's de información, ¿no?.

¿Y que curre si en el 70% de los scanlines restantes se dibujan antes de tiempo (porque todo el scanline no ofrece variaciones, por ejemplo), y compensan el retraso en uno o dos scanlines?, la imagen saldría dibujada sin retraso, y por lo tanto no habrían ralentizaciones.
Creo que es algo que debió quedar en manos de los programadores, y que ellos busquen los trucos que hagan falta para que uno o varios scanlines puedan superar ciertos límites.

Señor Ventura escribió:Entiendo... es una cuestión de que un sistema gráfico no es lo suficientemente rápido para dibujar un scanline a partir de determinados kb's de información, ¿no?.

¿Y que curre si en el 70% de los scanlines restantes se dibujan antes de tiempo (porque todo el scanline no ofrece variaciones, por ejemplo), y compensan el retraso en uno o dos scanlines?, la imagen saldría dibujada sin retraso, y por lo tanto no habrían ralentizaciones.
Creo que es algo que debió quedar en manos de los programadores, y que ellos busquen los trucos que hagan falta para que uno o varios scanlines puedan superar ciertos límites.

Nunca va a ocurrir el dibujo "antes de tiempo" en un dibujo sincronizado . El dibujo ocurre por interrupciones, es decir tienes un límite por línea y salto de línea, pero aunque una línea se dibuje en el 70% del tiempo que tiene asignado debe esperar lo que se llama una "interrupción de línea" para dibujar la siguiente. Vamos que todo está perfectamente sincronizado (el viejo concepto de vsync).

Realmente los programadores pueden hacer poco, pero ojo, pueden hacer. El VDP va asignando prioridad a los sprites por orden, así por ejemplo el sprite 1 tiene prioridad 1, el 2 tiene 2, etc. Supón que el límite es de 4 sprites por línea y al 5º flickeo. Siempre le tocaría flickear al mismo, al de menor prioridad. ¿Cómo evitamos eso? Con prioridad dinámica, vas cambiando en cada ciclo la prioridad de los mismos de modo que flickee uno diferente por ciclo. El efecto está muy conseguido, ya que un sprite que debería flickear siempre se acaba pintando 4 de cada 5 ciclos.

De ahí que el famoso bug del generador de imágenes de snes sea tan desastroso: Cuando se supera el límite, a veces llega a cargarse casi todo el scanline, cuando podría estar programado por hardware que "flickee" entre los sprites afectados en ese scanline para que se puedan mostrar todos.

¿El límite de sprites por scanline tiene que ver con el pixel fill rate? (es decir, una cuestión de renderización), o estamos hablando de una limitación de velocidad a la hora de hacer la conversión analógica, y si no es lo suficientemente rápida se pone el susodicho límite...

Es puro fill rate, el VDP no da para más. Date cuenta que no flickea el sprite completo, sino la linea donde se superpone con el máximo permitido por el VDP, por lo que esa línea no puede dibujarse completa sin exceder el tiempo de dibujo asignado.

AxelStone escribió:Es puro fill rate, el VDP no da para más. Date cuenta que no flickea el sprite completo, sino la linea donde se superpone con el máximo permitido por el VDP, por lo que esa línea no puede dibujarse completa sin exceder el tiempo de dibujo asignado.

Vale, pues identificado el asunto.

Con todo, dobla a toda la competencia en sprites por scanline, o sea que en realidad no es que no de para mas, sino que era de lo mejor... y eso demuestra que la configuración de los sprites, y el software embebido en el sistema gráfico no era el mas adecuado.

Tal vez, sin tocar nada, y tan solo reescribiendo la manera en que se comporta el sistema, se podría solucionar en gran medida el aspecto tan feo que deja cuando hay demasiados sprites.
-Permitir una configuración mas anárquica a la hora de establecer las medidas de los sprites (no solo 2 medidas para todo, sino todas las que quieras, y que no tengan por qué ser cuadrados, sino tambien rectángulos de cualquier medida).
-Corregir el bug que ocasiona que desaparezcan mas sprites de los que realmente se soportan por scanline, y que se hubiese solucionado implementando por hardware que a partir de "equis" sprite, flickee intercalándose con el resto. Se notaría algo raro, pero al menos no desaparecería todo.


En la siguiente imagen no se aprecia lo que digo, porque están todos enteros, pero doy fe de que me costó dar varias vueltas hasta poder sacar una foto decente. Hasta entonces, desaparecían casi todos los sprites.
Una solución es usar sprites grandes aunque supongan un malgasto de tiles, pero vaya, que sin cambiar nada del hardware, y solo las bases en que se especifica como funciona, mejoraría radicalemente el rendimiento.


En megadrive es lo que he dicho siempre. 16 sprites por scanline es de risa para lo que un 68000 podría gestionar.

Compruebalo tu mismo... no veo el sentido a un tema que se puede comprobar facilmente

Yo que se, programa cualquier tonteria como esta, y echas un vistazo al vdp a ver que hace, y ya tenes el porque el limite o no de un sistema, en este caso MD

theelf escribió:Compruebalo tu mismo... no veo el sentido a un tema que se puede comprobar facilmente

Yo que se, programa cualquier tonteria como esta, y echas un vistazo al vdp a ver que hace, y ya tenes el porque el limite o no de un sistema, en este caso MD

Hombre, no creo que haga comprobar que 16 sprites por scanline chirrían un poco cuando hablamos de una máquina que tiene un procesador para pedir mas. Es opinión, vaya.

Señor Ventura escribió:Hombre, no creo que haga comprobar que 16 sprites por scanline chirrían un poco cuando hablamos de una máquina que tiene un procesador para pedir mas. Es opinión, vaya.

theelf escribió:

Señor Ventura escribió:Hombre, no creo que haga comprobar que 16 sprites por scanline chirrían un poco cuando hablamos de una máquina que tiene un procesador para pedir mas. Es opinión, vaya.

*que haga falta*

Estamos hablando del limite de sprites por scanline, y creo que todos hemos visto software que ha demandado mas.

Señor Ventura escribió:*que haga falta*

Estamos hablando del limite de sprites por scanline, y creo que todos hemos visto software que ha demandado mas.

Va, metele una 3dfx tambien, y tenes 3d

theelf escribió:Va, metele una 3dfx tambien, y tenes 3d

¿No se echa en falta un límite algo mayor?.

Señor Ventura escribió:

theelf escribió:Va, metele una 3dfx tambien, y tenes 3d

¿No se echa en falta un límite algo mayor?.

Comprarse un PC, que podias ampliarlo a tu gusto

Yo no termino de comprender el hilo, ¿se supone que snes y Megadrive pueden tener mas sprites por scanline de lo que se vio, o como va esto?

theelf escribió:Comprate un PC, que podes ampliarlo a tu gusto

Tienes razón, ¿para que hablar de nada? xD

Blaster Master escribió:Yo no termino de comprender el hilo, ¿se supone que snes y Megadrive pueden tener mas sprites por scanline de lo que se vio, o como va esto?

Debe ser eso lo que se entiende.

Blaster Master escribió:Yo no termino de comprender el hilo, ¿se supone que snes y Megadrive pueden tener mas sprites por scanline de lo que se vio, o como va esto?

Si se plantea asi es un sinsentido, los juegos de PC se programan pensando en lo que se necesita, los de consola en lo que se tiene

Señor Ventura escribió:

theelf escribió:Comprate un PC, que podes ampliarlo a tu gusto

Tienes razón, ¿para que hablar de nada? xD

Blaster Master escribió:Yo no termino de comprender el hilo, ¿se supone que snes y Megadrive pueden tener mas sprites por scanline de lo que se vio, o como va esto?

Debe ser eso lo que se entiende.

¿Pero va por software?
Si es ese el caso, supongo que no vimos mas sprites por scanline del mismo modo que no vimos otras cosas mejores cuando las maquinas daban de si, por ejemplo; musicas y fx horrendos en Megadrive cuando se puede sacar un adio increible, o 3 enemigos en pantalla en snes cuando se vio en otros juegos que se podian poner mas...

Blaster Master escribió:¿Pero va por software?
Si es ese el caso, supongo que no vimos mas sprites por scanline del mismo modo que no vimos otras cosas mejores cuando las maquinas daban de si, por ejemplo; musicas y fx horrendos en Megadrive cuando se puede sacar un adio increible, o 3 enemigos en pantalla en snes cuando se vio en otros juegos que se podian poner mas...

No, lo que ocurre es que el hardware trabaja de una manera, que aunque sea por hardware, tiene que indicarse igualmente. Al estar embebido en los propios chips, es inamovible, y cuando ese software no optimiza bien la forma de trabajar de ese hardware, pues ocurren cosas como el bug del generador de imágenes de la snes.

Una forma de resolverlo habría sido reescribiendo ese software, haciendo que por ejemplo el sprite Nº 32, al pasarse del límite impuesto, en vez de desaparecer flickee con otro sprite, así en cada frame siempre falta uno, no superándose el límite por scanline, pero a la vista del ojo humano siempre percibirás que están todos. Eso podría haberse hecho por hardware, pero sin embargo, lo que ese software le dice al generador de imágenes, es que se cargue sprites sin ningún control.

Lo inexplicable es que con posteriores remesas de snes no se corrigiera ese problema.

Vamos que te fastidia que la Megadrive pueda hacer un Streets of Rage con 80 sprites y la Super con 128 no le llegue ni a la suela de los zapatos

Vaya exageraciones mas absurdas.

A mi modo de ver, técnicamente esto está bastante a la altura de un streets of rage 2 (nótese que tiene parones entre fases, y transiciones, que no son culpa del juego, sino de la emulación):
https://www.youtube.com/watch?v=14iYMC_qtGc

Y si, con 6 personajes en pantalla ya se nota algún parpadeo de vez en cuando, pero es que hablamos de inflar la pantalla a base de sprites de 8x8. Es una burrada de potencia bruta (con el límite de sprites por scanline de megadrive, no se lo podría ni permitir ni a un 50%, para que te hagas una idea).
La opción es poner sprites de 32x32 (malgastando tiles), y completar los personajes con sprites de 16x16 (porque la snes no permite poner a la vez sprites de 32x32 y 8x8), de forma que así ocupas muchos menos sprites en pantalla, y por lo tanto, hay menos sprites por scanline, evitando cualquier parpadeo.

Un sprite de 32x32 son 16 tiles. Cada uno de los 6 personajes tendría uno de ese tamaño, así que hablamos de 96 tiles. El resto de sprites de 16x16 para completar cada personaje equivalen cada uno a dos tiles (ya que un tile tiene un tamaño de 8x8).
Te quedan 416 tiles para representar los sprites de 16x16 que necesites para completar cada dibujo... vamos, no tienes capacidad en la tabla OAM para tanto (a base de sprites de 16x16), puedes malgastar lo que te plazca.

En definitiva, que con una mejor configuración de sprites, este juego en concreto no hubiera parpadeado. Luego está el tema de la detección de colisiones usando eso tamaños, pero anda que no hay juegos usando esa configuración.



Ahora, ¿que como juego, artísticamente no hay color entre un SoR 2 y un combatribes?, pues si, es así... pero el combatribes tiene una factura de arcade que no tiene nada que envidiarle a ningún brawler. Decir que la snes no le llega ni a los tobillos a la megadrive es ser muy valiente, creo yo xD

es debido a que la mayoria de las consolas antiguas ocupaban sprites por hardware, debido a que no tenian la potencia ni memoria suficiente para dibujar sprites en el framebuffer o no poseian un chip acelerador de graficos o blitter como se le conocia en aquella epoca.
Los sprites por hardware eran dibujados en tiempo real por la VDP (Video display Processor) a medida que se dibujaba cada scanline, debido a esto, si la cantidad de sprites por scanline era muy alta y la VDP no podia dibujarlos todos a tiempo, simplemente ignoraba los que no podia y pasaba a la siguiente linea.

Y si, con 6 personajes en pantalla ya se nota algún parpadeo de vez en cuando, pero es que hablamos de inflar la pantalla a base de sprites de 8x8. Es una burrada de potencia bruta (con el límite de sprites por scanline de megadrive, no se lo podría ni permitir ni a un 50%, para que te hagas una idea).

Si te he entendido bien, dices que el Combatribes usa sprites de 8x8 en Snes y que para hacerlo igual en la Mega, no podria (basicamente).

Si no es asi, lo que sigue vamos ha hacer como que no lo lees xd (y si me lo puedes matizar... )

¿Y porque la Mega deberia hacerlo igual que en Snes cuando ya se ha visto (saga Streets of Rage) que tiene un, cuanto menos (te soy generoso xd), igual rendimiento de enemigos en pantalla "haciendolo a su manera"?

Lo pregunto sin mal rollo ni exager ni na eh? Esta vez va en serio xd

¿y porque dices que el limite de sprites por scanline de la Mega es de 16?

AfterBurner escribió:Si te he entendido bien, dices que el Combatribes usa sprites de 8x8 en Snes y que para hacerlo igual en la Mega, no podria (basicamente).

Si no es asi, lo que sigue vamos ha hacer como que no lo lees xd (y si me lo puedes matizar...

Me he equivocado, usa sprites de 16x16, y alguno que otro de 8x8, pero es que no usa ninguno de 32x32, que sería lo necesario.

Megadrive no puede abusar de usar sprites pequeños para estos juegos, porque su límite de sprites por scanline es de 16. Si snes con 32 llega al límite, la megadrive llegaría mucho antes.

La cuestión, es que como dices, no hay por qué liarse a usar sprites pequeños.

AfterBurner escribió:¿Y porque la Mega deberia hacerlo igual que en Snes cuando ya se ha visto (saga Streets of Rage) que tiene un, cuanto menos (te soy generoso xd), igual rendimiento de enemigos en pantalla "haciendolo a su manera"?

Lo pregunto sin mal rollo ni exager ni na eh? Esta vez va en serio xd

Exacto, esa es la cuestión.

Hablaba de fuerza bruta, que no es que tenga usabilidad, pero es el caso del combatribes.

AfterBurner escribió:¿y porque dices que el limite de sprites por scanline de la Mega es de 16?

Pues porque es lo que determina su VDP.

Pues porque es lo que determina su VDP.

Pero eso es en modo "emulacion snes" xd Osea 256x224

En 320x224 son 20.

AfterBurner escribió:

Pues porque es lo que determina su VDP.

Pero eso es en modo "emulacion snes" xd Osea 256x224

En 320x224 son 20.

Cierto, son 20.

Theelf no está de acuerdo conmigo, pero a mi no me parece proporcionado ese pixel fillrate por scanline, con el ancho de banda de su bus de datos.

Sigo pensando que es una limitación autoimpuesta de forma absurda. Si puedes poner 20 sprites de 16 pixels de ancho, es que el VDP puede dibujar 320 pixels de sprites por scanline... pero sin embargo no puedes poner 30 sprites de 8x8, a pesar de que eso supone 240 pixels, y el VDP tiene pixel fillrate de sobra para dibujar cada scanline bajo esas condiciones.

Y lo mismo sucede con todas las máquinas que funcionan así.

Señor Ventura escribió:

AfterBurner escribió:

Pues porque es lo que determina su VDP.

Pero eso es en modo "emulacion snes" xd Osea 256x224

En 320x224 son 20.

Cierto, son 20.

Theelf no está de acuerdo conmigo, pero a mi no me parece proporcionado ese pixel fillrate por scanline, con el ancho de banda de su bus de datos.

Sigo pensando que es una limitación autoimpuesta de forma absurda. Si puedes poner 20 sprites de 16 pixels de ancho, es que el VDP puede dibujar 320 pixels de sprites por scanline... pero sin embargo no puedes poner 30 sprites de 8x8, a pesar de que eso supone 240 pixels, y el VDP tiene pixel fillrate de sobra para dibujar cada scanline bajo esas condiciones.

Y lo mismo sucede con todas las máquinas que funcionan así.

No te podria decir lo que es, ya que lo desconozco, pero...¿y si realmente es asi por algo serio y nos lo estamos pasando por alto?
Quiero decir, todas estas maquinas funcionan asi, por algo debe ser ¿no?

Blaster Master escribió:No te podria decir lo que es, ya que lo desconozco, pero...¿y si realmente es asi por algo serio y nos lo estamos pasando por alto?
Quiero decir, todas estas maquinas funcionan asi, por algo debe ser ¿no?

Yo lo veo matar moscas a cañonazos, la verdad.


Ahora, con los datos en la mano, cualquiera diría que snes lo tiene mas fácil para evitar parpadeos y desapariciones de sprites... 128 sprites, 32 por scanline... pero luego sucede esto:




Por cierto, echadle un vistazo al siguiente link, porque hay información que me parece interesante de investigar, si realmente es cierto.
Dicen que hubo recortes, y que la megadrive estuvo planificada para tener 128KB de vram (en mi opinión, la vram es el elemento mas crítico en una consola de 16 bits), además de un bus adicional que le hubiese permitido aumentar todavía mas el ancho de banda del bus de datos.

http://www.vandal.net/foro/mensaje/8937 ... -a-fondo/4

El artículo empieza desde aquí, muy recomendado echarle un vistazo desde el principio:
http://www.vandal.net/foro/mensaje/8937 ... e-a-fondo/

Gracias por las respuestas @Señor Ventura

Pensad que al ser todo esto hardware, la capacidad para el VDP pueda pintar más de n sprites en un scanline se lo tienes que implementar tu a pista y puerta lógica. Hay un límite a lo que puedes llegar a implementar dentro un chip