Señor Ventura escribió:Concretamente es una máscara de sprites. Cubres el campo de los sprites ocupando el área que necesites abarcar, y sus tiles son transferidas desde el cartucho con la escena ya precalculada.
Con el paso del tiempo sigues teniendo el mismo cacao mental con la SNES y cómo funciona
D
Ya te digo que tu afirmación no es cierta, no hay ninguna máscara de sprites, pero voy a intentar que llegues tú solo a la conclusión: si existe tal máscara... ¿dónde se almacena en la PPU? Es decir, si la PPU ha de enmascarar píxeles para no mostrarlos en pantalla, habrá que decirle en algún sitio qué píxeles se dibujan y cuáles no. ¿Sugieres que hay entonces una zona de memoria VRAM con información de máscara para cada píxel?
Si esto fuera así, necesitarías un buffer del tamaño de la pantalla para guardar esa máscara y por tanto, habría que decirle a la PPU dónde empieza ese buffer. ¿Qué registro de la PPU se usa para ello?
.
.
.
.
Solución: no existe nada de eso que dices de máscara: el color 0 de la paleta es el color transparente para cada sprite; eso quiere decir que todos los píxeles que dibujes en el sprite con ese color, se verá transparente, es decir, dejará ver lo que hay detrás del sprite. Eso no es una técnica, eso es una obligación en un sistema basado en tiles para que los sprites no tengan que rellenar todo un tile y puedan tener formas redondeadas.
Y como te decía, esto no se usa en "algún juego" en concreto, sino en TODOS absolutamente del catálogo de la SNES, porque es la forma en la que trabaja la PPU.
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,
No, ya que si haces scroll de los BG, también tienes que mover los sprites para que sigan ese scroll, lo cual implica actualizar toda la copia de la tabla OAM que tienes en RAM antes de enviarla a OAM. Por tanto la CPU no queda libre, ha de calcular las colisiones de TODOS esos sprites en la nueva posición del scroll.
Señor Ventura escribió:En el caso del super mario world 2, seguramente habrás notado que en condiciones normales se pasaría del pixel fill rate por scanline, y por mucho, pero de esta forma puedes dibujarlo todo sin parpadeos.
No, ya te he comentado muchas veces que el fill-rate de la SNES no suele ser el problema en el 99% de los casos.
Si con "fill-rate" te refieres al límite de píxeles por scanline en tiles de sprites, el límite sigue estando si usas esa "técnica" que dices: de hecho se ve en el video que has puesto, ya que el máximo de ancho son 8 tiles de 16x16 (es decir, las 32 tiles 8x8 por scanline).
Señor Ventura escribió:lo que quería decir es que era incorrecto mi afirmación de que con un chip de apoyo no te podías saltar la limitación del ancho de banda y del fill rate (con el truquito de usar un "lienzo" de sprites, o tiles de un plano, puedes representar una imagen precalculada por un chip de apoyo que en condiciones normales necesitarias mas ancho de banda y fill rate de la que una snes puede ofrecer, por ejemplo poniendo 400 peronajes en pantalla... para la snes solo serían un puñado de tiles igualmente).
Ya te digo que no es ningún "truco" y por supuesto que con el chip de apoyo NO te saltas la limitación de la PPU. Piensa bien eso que dices, es una barbaridad: la PPU tiene una limitación en cómo lee las tiles de su VRAM interna, y dices que con un chip externo, que como mucho puede ESCRIBIR en esa VRAM, la PPU mágicamente deja de tener esa limitación. Eso no es como dices, es técnicamente imposible.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")