magno escribió:@Señor VenturaLo primero de todo es que nadie te está insultando, sólo te estoy explicando en qué te equivocas. Y aunque le intentes dar vueltas semánticamente, lo que exponías no es cierto; te respondo a continuación:
No he dicho que tu me estés insultando, sino que otros usuarios usan tus correciones para descalificarme a mi, cuando comúnmente se deben mas a no llegar a un entendimiento, que a que no esté viendo bien las cosas, o a que me equivoque tanto, tanto, TANTO.
Mira los votos positivos que has recibido. Están encantados.
Pero me temo que en esta ocasión no se me ha entendido, aunque eso dará igual, y para esas personas será otra equivocación mas que será usado para lo de siempre. Por eso decía lo que decía.
magno escribió:Señor Ventura escribió:La OAM que se ve en el vídeo existe, no tiene nada de incierta.
La OAM no es lo que se ve en el video por mucho que la pestaña de la ventana diga eso: lo que se ve en el video es la parte de VRAM que almacena las tiles de los sprites apuntados desde la OAM. La OAM es una tabla de 544 bytes con los primeros 512 bytes con los datos para los 128 sprites (4 bytes por sprite) y los 32 bytes siguientes (256 bits) son los 2 bits extras para la posición horizontal del sprite y el otro para cambiar la página de VRAM donde están las tiles del spruite. Por tanto, la OAM son 544 bytes donde no hay tiles, por lo que estás viendo en ese video no es la OAM, es la VRAM (que es el único sitio posible donde se alamacenan las tiles que se ven en pantalla, ya sean de BGs o de sprites)
Lo se, se que en la tabla OAM no hay tiles, es una tabla de atributos para los sprites.
La tabla de atributos de los sprites consiste en establecer una coordenada X y una coordenada Y en los dos primeros Bytes, número de tile en el segundo Byte, dos bits del cuarto Byte para flipear el sprite en dos coordenadas (bit 7 Y, bit 8 X), los bits 4 y 5 para la prioridad, bits 1 2 y 3 para el número de la paleta. Los 32 Bytes adicionales destinan 2 bits por sprite, que definen su tamaño, y hasta donde tenía entendido, su coordenada X.
Un poco caótico, pero el concepto ya lo tenía claro (repito, tengo claro el concepto de tabla OAM, no que cada bit de los atributos sirvan justo para lo que menciono).
magno escribió:¿A modo de lienzo? Dices que se dispone a modo de lienzo como en todos los juegos de SNES... por tanto no hay ninguna "técnica" ahí, es como funciona el sistema. Lo que no es de ninguna manera es una máscara; supongo que no estás muy familiarizado con estos términos y los usas sin el debido conocimiento, pero para nada es una máscara, más bien es algo parecido a un canal alfa, donde un color se usa para hacer la transparencia.
No, en todos los juegos de snes varias decenas de sprites no simula estar representando varios centenares de sprites.
Si observas la imagen de la presentación del super mario world 2, y no sus sprites desde un debugger, podrás notar el número de objetos que están siendo calculados
POR EL SUPER FX.
Si ese número de objetos tuviesen que ser representados con los 128 slots para sprites de snes, no serían suficientes porque te pasarías del límite por scanline, y seguramente porque necesitarías mas de 128 sprites.
Sin embargo, usando los 40 sprites que la snes destina para que el super fx cambie su información gráfica desde la ram del cartucho (esto es, renderizar la imagen, dividirla en tiles, y mandarla a la VRAM), podrás visualizar todo lo que se renderice desde el mismo.
En definitiva, ahí hay 40 sprites, pero hay muchos mas objetos que 40.
magno escribió:No se entiende perfectamente lo que quieres decir, porque leyendo tus palabras das una idea totalmente errónea de lo que realmente ocurre en la SNES; quizá sí sepas cómo va a SNES, pero entonces tu problema es que lo explicas mal.
Ya te lo dije anteriormente: no te metas en estos barrizales y nadie usará tus propios comentarios en tu contra.
Permíteme la licencia de aludir a la acepción que en un foro no especializado en programación, se le pueda dar a la palabra "máscara".
Creo que mas allá de la jerga de programación, se puede entender a que me refería, y mas con un vídeo que contextualiza lo que está pasando.
Se me puede entender, creo yo, vamos.
magno escribió:Claro, esto que dices sí es verdad, así es como funciona el SuperFX, nada de máscaras ni técnicas raras que solucionen el problema de sprites por scanline.
No solucionas el problema del límite de sprites total, y por scanline, sino que lo simulas.
Pero si todos esos objetos tuvieran que representarse usando un sprite por cada uno de ellos, si te estarías encontrando con esa limitación, por eso al usar esta forma de representar la escena, te saltas ese límite. No de una forma literal, sino que te evitas el tener que toparte con ese límite.
No he pretendido decir otra cosa en todo este tiempo.
magno escribió:Señor Ventura escribió:Exigiría una sincronización mas difícil de llevar a cabo que hacerlo todo directamente con un procesador de apoyo.
Por eso dije que lo suyo sería hacerlo todo desde ahí. En el caso concreto del super mario world 2, al no haber scroll, la snes puede pintar el fondo ella sola, y lo que hay dentro de los sprites son calculados por el super fx para luefgo ser enviados a la vram.
No dijiste eso ni de coña; en este comentario dices que "no hay scroll" y yo te estaba respondiendo a éste en el que dices qué pasaría si hubiera scroll:
Señor Ventura escribió:Y la gracia de hacerlo con sprites, es que a la snes le dejas libre los planos para que su sistema gráfico pueda hacer scroll con uno o varios planos,
Si he dicho que lo lógico sería hacerlo todo (sprites y planos) desde el procesador de apoyo:
"aunque lo lógico es que el procesador que calcula la posición de los objetos también se encargue de dibujar unos planos".viewtopic.php?p=1747248599magno escribió:Señor Ventura escribió:Me refiero que si haces que cada elemento movil de esa escena sea representada por los sprites que correspondan, te pasarías de tasa de relleno, y no habría OAM suficiente.
Maaaaaaaadre mía, qué cacao llevas......... ¡que la OAM no lleva tiles! A ver, la "tasa de relleno" de la que tanto hablas es
la capacidad de enviar píxeles a pantalla, que en el caso de SNES es fija: la SNES está diseñada para ser suficientemente capaz de generar la resolución de 256x240 píxeles de pantalla, es decir, que el fill-rate se deriva del reloj de píxel y la resolución, ambas fijas; lo que supongo que quieres decir es la tasa de envío de tiles a VRAM, que no es el fill rate, pero en este caso, esa tasa de envío de tiles a VRAM no tiene que ver con la OAM porque ésta no lleva tiles.
No llevo ningún cacao. La snes pone 40 sprites, y el super fx pone muchísimos mas objetos en esa pantalla.
Si intentas que la snes dibuje cada objeto usando sprites, llegas al límite antes de dibujarlo todo. Ciertamente es así.
magno escribió:Señor Ventura escribió:Te la saltas porque estás evitando que sea representado de la forma ordinaria, y así si que no hay recursos.
No es cierto, no te la saltas de ninguna manera porque esa imagen del SMW2 es una imagen como cualquier otra hecha con sprites y sigue teniendo la misma limitación, que ya te he comentado que en el video se ve claramente como no ocurre el error: hay 32 tiles en un scanline, por tanto, no hay problema.
Desde el mimso momento en que le evitas a la snes tener que usar un sprite para cada uno de todos esos objetos, te estás saltando su limitación. No es que consigas poner mas sprites de los que soporta la snes. Eso no es lo que está pasando.
magno escribió:Señor Ventura escribió:¿Cuantos elementos móviles hay en la pantalla de presentación del super mario world que se ve en el vídeo? (lo que se ve dentro de cada sprite).
Malinterpretas lo que estás viendo en ese video totalmente: los "elementos móviles" son tiles que se están actualizando en VRAM, mientras que los sprites son estáticos, es decir, la tabla OAM está configurada para que aparezcan en pantalla ciertos objetos de 16x16 píxeles y hace un "layout" con esos sprites, poniéndolos uno al lado de otro de la manera adecuada para la imagen. Luego, el SuperFX está generando la imagen y envía a VRAM las tiles que se pintarán en esas posiciones de pantalla. No hay ningún misterio más, es lo que se hace en TODOS los juegos de SNES.
Los elementos móviles son tiles que se están actualizando en la VRAM, efectivamente, nunca he dicho lo contrario, de hecho eso mismo lo he tenido que mencionar bastantes veces a lo largo de este hilo, y de otros muchos hilos mas, porque es lo que entiendo de como funciona eso.
Por otro lado, querrás decir que eso sucede en todos los juegos de snes que usan el super fx, ¿no?.
magno escribió:Pues estaría bien que empezaras a entender de lo que hablas, por que en ese video no explica nada de lo que has dicho en los otros posts.
Entender, y querer ser entendido. Seamos justos.
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
D
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
Fíjate por dónde lo has clavado. 
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
¿Y no te das cuenta de que esto no supera la limitación de sprites por pantalla de la SNES? Es cierto que si fuera como dices, el SuperFX podría estar calculando cada "enemigo" (por poner un ejemplo de sprite) como tiles sueltas sin estar restringido a los 128 de la SNES, pero luego es la PPU la que tendría que mostrar ese enemigo como un sprite por pantalla, por lo que sigue limitando el número de sprites de la PPU. Y si ese "enemigo" calculado por el SuperFX lo convirtieras a una tile para ponerlo en un BGx, tendrías el problema del scroll que te decía antes.