Capacidades y limitaciones del PPU de SNES

Nota de Moderación:

El hilo viene de un off-topic del hilo de "Novedades scene retro"


kusfo79 escribió:
Señor Ventura escribió:P.D: En snes las tiles con menos colores, ocupan menos espacio.

Si? pero eso es un modo diferente? con diferente numero de colores a la vez?


No, eso es el modo de funcionamiento normal de la SNES: si quieres tiles 8x8 de 16 colores, necesitas 4 bits para cada píxel para codificar el color. Una tile 8x8 de 1BPP ocupa 8 bytes, para tener 16 colores, es el modo 4BPP, por lo que ocupa 4 veces más = 32 bytes.

Dudo mucho que la Megadrive funcione diferente... a más profundidad de color, más ocupa cada tile, a menos de que éstas siempre tengan una profundidad fija y se desaproveche espacio de almacenamiento en modos donde solo se necesite 1 color (por ejemplo, sombras o letras de texto).
En Nes, Master y Megadrive, los tiles ocupan siempre lo mismo, por que no hay modos con diferente densidad de color (Ojo, en Mega puedes usar el modo master system, pero los tiles ocupan lo mismo por que referencian en los dos casos a una paleta de 16 colores). La excepción es si en master usas los modos heredados de la SG-1000 (pero el 99% de los juegos usan el modo 4).
icecaap escribió:
kusfo79 escribió:Acaban de colgar un video de otra de las participantes en el SMSPowerCompo2017...otra demo de "Bad Apple", pero en todo color en una master!!

Bad Apple a todo color en Master!

Una pasada :O pero ya os aviso que no funciona en el everdrive, demasiado tamaño la rom.


En el everdrive de MD usando su retrocompatibilidad debería funcionar. Pesa 4.5Mb y si no me equivoco acepta roms hasta 6Mb, después pruebo.
En otras palabras, que juegos como este:
Imagen


Se mueve a una resolución de 224x160, así que ya solo atendiendo a lo relativo a la resolución vertical, tenemos que el juego permite un ancho de banda de 16,12KB por frame, que sumado a que la mayoría de tiles son de 8 Bytes, tenemos que puedes actualizar 2064 tiles en un solo frame.

Lo que se puede hacer con eso es brutal, y eso sin contar con que la mayoría de tiles están repetidos. Son todos ventajas, hasta podrías poner 4 planos actualizando tiles sin repetir patrones a una velocidad de vértigo, y digo literalmente a muchísima velocidad.

P.D: Estoy obviando la resolución horizontal, que también está recortada. No se si por ahí puedes conseguir también en torno a 1165 Bytes adicionales, mis cálculos no pueden ser correctos, porque sigues dibujando el scanline entero. Tan solo ahorras CPU por partida doble (res. vertical y res. horizontal).


Editado: La megadrive en circunstancias similares, y teniendo en cuenta su mayor ganacia tanto por DMA nominal, como por bytes extra por cada scanline exluído (204 bytes por línea), tenemos que se obtiene por cada frame 20449 Bytes (19,97 KB), pero en su caso, si las tiles ocupan 32 Bytes, se están consiguiendo 639 tiles por frame, en lugar de las 2064 de snes :O

Blast processing vs smart processing [sonrisa]
Vuelvo a preguntar, pero...seguro que esto se puede hacer en 1BPP en algunos tiles, y en otros no? se pueden mezclar modos??
kusfo79 escribió:Vuelvo a preguntar, pero...seguro que esto se puede hacer en 1BPP en algunos tiles, y en otros no? se pueden mezclar modos??


Muy buena observación, me sumo a la pregunta.

aki7 escribió:Pero este tema ¿no es para comentar las novedades que se producen en la scene retro? O se puede offtopiquear a saco y hablar de áspectos técnicos o de cualquier otra cosa que no tengan que ver con centrarse en comentar las novedades que nos trae la scene retro?


Casi entendería mas que se solicitase que el primer post del hilo enlazara con las noticias sobre lo que trata el hilo, porque por offtopiquear un poco no se están perdiendo, desde luego.
Vale, me contesto a mi mismo. No, no se pueden mezclar diferentes profundidades de Tile (no me cuadraba con todas las demás consolas que conozco). Supongo que si que se puede llegar a hacer usando una interrupción horizontal, partiendo la pantalla entre modos (algún juego de MSX lo he visto con este truco)

Por lo que he visto por internet, el 99% de los juegos usan el modo 4bpp por tile en la Super Nes, con lo que los tiles ocupan también 32 bytes cada uno. (Y el otro modo usado suele ser el modo 3 de 128/256 colores para imagenes estáticas).
kusfo79 escribió:Vale, me contesto a mi mismo. No, no se pueden mezclar diferentes profundidades de Tile (no me cuadraba con todas las demás consolas que conozco). Supongo que si que se puede llegar a hacer usando una interrupción horizontal, partiendo la pantalla entre modos (algún juego de MSX lo he visto con este truco)

Por lo que he visto por internet, el 99% de los juegos usan el modo 4bpp por tile en la Super Nes, con lo que los tiles ocupan también 32 bytes cada uno. (Y el otro modo usado suele ser el modo 3 de 128/256 colores para imagenes estáticas).


Sí, sí se pueden mezclar, por supuesto, cada profundidad de color en un BG distinto. Aquí puedes verlo: SuperFamicom Wiki
El 99,99% de juegos de RPG utilizan modo 1, y del resto, pues según necesidades, no hay una norma genérica, aunque los más habituales son el modo 1,2,3 y 4.

Y @Aki7 tiene razón, no hagamos offtopic.
Calculinho escribió:
icecaap escribió:
kusfo79 escribió:Acaban de colgar un video de otra de las participantes en el SMSPowerCompo2017...otra demo de "Bad Apple", pero en todo color en una master!!

Bad Apple a todo color en Master!

Una pasada :O pero ya os aviso que no funciona en el everdrive, demasiado tamaño la rom.


En el everdrive de MD usando su retrocompatibilidad debería funcionar. Pesa 4.5Mb y si no me equivoco acepta roms hasta 6Mb, después pruebo.


Acabo de probarla @SetzerGabbiani y da "prog error 140" pero mi everdrive es el chino versión OS36 a saber si con el último que ha salido o con el de kirkzz tirará.
magno escribió:
kusfo79 escribió:Vale, me contesto a mi mismo. No, no se pueden mezclar diferentes profundidades de Tile (no me cuadraba con todas las demás consolas que conozco). Supongo que si que se puede llegar a hacer usando una interrupción horizontal, partiendo la pantalla entre modos (algún juego de MSX lo he visto con este truco)

Por lo que he visto por internet, el 99% de los juegos usan el modo 4bpp por tile en la Super Nes, con lo que los tiles ocupan también 32 bytes cada uno. (Y el otro modo usado suele ser el modo 3 de 128/256 colores para imagenes estáticas).


Sí, sí se pueden mezclar, por supuesto, cada profundidad de color en un BG distinto. Aquí puedes verlo: SuperFamicom Wiki
El 99,99% de juegos de RPG utilizan modo 1, y del resto, pues según necesidades, no hay una norma genérica, aunque los más habituales son el modo 1,2,3 y 4.

Y @Aki7 tiene razón, no hagamos offtopic.


Ahí pone que no se pueden mezclar, otra cosa es que algunos modos asignan una profundidad determinada a todo un plano, y otra a otro de los planos, pero ya está...

Luego abriré un hilo con lo que descubra del another world de snes, y así no offtopiqueamos mas
kusfo79 escribió:
Ahí pone que no se pueden mezclar, otra cosa es que algunos modos asignan una profundidad determinada a todo un plano, y otra a otro de los planos, pero ya está...


Creo que lo pone bien claro en la wiki y que lo he explicado bien claro: se pueden mezclar profundidades de color ENTRE PLANOS BG: un plano de 4 colores, otro de 16, otro de 2... Si por mezclar te refieres a una tile de un color y la siguiente de otro, pues sí, se puede si ambas tiles pertenecen a distintos planos, y no se puede si pertenecen al mismo.
magno escribió:Creo que lo pone bien claro en la wiki y que lo he explicado bien claro: se pueden mezclar profundidades de color ENTRE PLANOS BG: un plano de 4 colores, otro de 16, otro de 2... Si por mezclar te refieres a una tile de un color y la siguiente de otro, pues sí, se puede si ambas tiles pertenecen a distintos planos, y no se puede si pertenecen al mismo.


Una pregunta tonta, y por mi parte no offtopiqueo mas, ¿con los sprites puedes mezclar unas tiles con una profundidad específica, a continuación de otros sprites con sus tiles a otra profundidad?, o las tiles de los sprites siempre ocupan 32 bytes.

Editado: Cuando cambias la prioridad de un tile de un plano, ¿estás limitado a cambiarlo de capa?, o también puedes cambiarlo de posición al cambiar su prioridad.

Por ejemplo, un tile que está en el background 4 en la esquina superior izquierda, pasarlo al background 1, 2, o 3 pero en el centro. Esto sería cojonudo para tener un plano reservado a modo de "buffer", ya que como quedaría tapado por los demás planos, no se vería semejante amalgama de tiles ^^
magno escribió:
kusfo79 escribió:
Ahí pone que no se pueden mezclar, otra cosa es que algunos modos asignan una profundidad determinada a todo un plano, y otra a otro de los planos, pero ya está...


Creo que lo pone bien claro en la wiki y que lo he explicado bien claro: se pueden mezclar profundidades de color ENTRE PLANOS BG: un plano de 4 colores, otro de 16, otro de 2... Si por mezclar te refieres a una tile de un color y la siguiente de otro, pues sí, se puede si ambas tiles pertenecen a distintos planos, y no se puede si pertenecen al mismo.


Mi primera pregunta era si se podían mezclar diferentes profundidades en un mismo plano, que ya suponía y comprobado que no. Lo preguntaba por que de lo que decía @Señor_Ventura se entendía eso (lo de que muchos de los tiles eran solo dos colores, pero no todos). De todas formas, he mirado como va el Another World en SNES y funciona de la misma manera que en mega. Está usando un solo plano como un framebuffer donde va dibujando todo (BG1).

Sobre lo que comentas, hay 8(+1) modos en la Super Nintendo, y no se pueden mezclar, ya que los defines en el registro $2105 de la PPU para toda la pantalla. Lo que ocurre es que varios de los modos tienen diferentes profundidades de color dependiendo del plano. Como has comentado, el modo 1 era muy usado, y te permitía tener dos planos de 16 colores por tile (32 bytes por tile), y el tercer plano con 4 colores por tile (16 bytes por tile). No permite mezclarlo a voluntad ni nada parecido.

Estaría bien si un moderador, como @salvor70, pudiera crear un hilo con esta discusión, es offtopic pero es interesante.
kusfo79 escribió:Mi primera pregunta era si se podían mezclar diferentes profundidades en un mismo plano, que ya suponía y comprobado que no. Lo preguntaba por que de lo que decía @Señor_Ventura se entendía eso (lo de que muchos de los tiles eran solo dos colores, pero no todos). De todas formas, he mirado como va el Another World en SNES y funciona de la misma manera que en mega. Está usando un solo plano como un framebuffer donde va dibujando todo (BG1).

Sobre lo que comentas, hay 8(+1) modos en la Super Nintendo, y no se pueden mezclar, ya que los defines en el registro $2105 de la PPU para toda la pantalla. Lo que ocurre es que varios de los modos tienen diferentes profundidades de color dependiendo del plano. Como has comentado, el modo 1 era muy usado, y te permitía tener dos planos de 16 colores por tile (32 bytes por tile), y el tercer plano con 4 colores por tile (16 bytes por tile). No permite mezclarlo a voluntad ni nada parecido.

Estaría bien si un moderador, como @salvor70, pudiera crear un hilo con esta discusión, es offtopic pero es interesante.


Lo que quiere decir es que tu puedes poner tiles de 1BPP incluso en un plano de 256 colores, pero ya no podrás usar otros tiles con otra profundidad de color en ese mismo plano.

Piensa que si los tiles estuviesen obligados de forma rigida a tener la profundidad de color que indique el plano del modo en el que trabajes, no existirían los tiles a 1BPP, porque no hay planos a esa profundidad de color.

Lo genial sería poder mezclarlos, pero al menos hay una solución factible para obtener buenos resuktados mezclando. Mi duda está en si un tile al que cambias de prioridad, se le puede cambiar también de lugar al "cambiarlo de plano" (nótense las comillas).
Estaría bien que hubiesen más hilos de temas técnicos, que al final estamos deseando que salte el tema en algún sitio para poder hablarlo jejeje.

EDITO: gracias por crearlo Salvor
Ya que tenemos el nuevo hilo, respondo a algunas cosas:

Señor Ventura escribió:Lo que quiere decir es que tu puedes poner tiles de 1BPP incluso en un plano de 256 colores, pero ya no podrás usar otros tiles con otra profundidad de color en ese mismo plano.

Piensa que si los tiles estuviesen obligados de forma rigida a tener la profundidad de color que indique el plano del modo en el que trabajes, no existirían los tiles a 1BPP, porque no hay planos a esa profundidad de color.


Que va, no es así en absoluto. Si tú pones una tile 1BPP en un plano de 256 colores, te toca rellenar el resto de bits por píxel (los 7) de color 0 para que sean transparente.
La PPU de SNES sólo maneja tiles de 4 colores (2BPP), 16 colores (4BPP) y 256 colores(8BPP), y estos se pueden distribuir libremente dentro de cada BG según la tabla que linké más arriba.
Pero tú puedes usar tiles de 1BPP si quieres, pero luego en VRAM han de aparecer como 2BPP, 4BPP o 8BPP.
Algo muy típico que se suele hacer es trabajar con tiles de 1BPP en ROM o RAM y luego pasarlas a VRAM a tiles 2BPP dejando sin utilizar los otros 2 colores.
Lo que no se puede hacer nunca es mezclar en un BG son tiles de diferente profundidad de color: una vez está configurado la profundidad de color en un BG a través del modo, las tiles siempre ocupan lo mismo en VRAM.




kusfo79 escribió:Mi primera pregunta era si se podían mezclar diferentes profundidades en un mismo plano, que ya suponía y comprobado que no. Lo preguntaba por que de lo que decía @Señor_Ventura se entendía eso (lo de que muchos de los tiles eran solo dos colores, pero no todos). De todas formas, he mirado como va el Another World en SNES y funciona de la misma manera que en mega. Está usando un solo plano como un framebuffer donde va dibujando todo (BG1).


En tu primer pregunta dijiste si se podían mezclar, no si se podían mezclar en el mismo plano; además, dices que al subirlas a VRAM siempre ocupan lo mismo, y es lo que traté de explicarte que no era así:

kusfo79 escribió:En realidad, y como creo que ya comenté un día que preguntabas algo parecido, en estas consolas el número de colores, sobretodo a la hora de subir a la VRAM, da igual. Los tiles ocupan siempre lo mismo. Si que puedes ahorrar en cierta manera si tienes los tiles comprimidos en la rom y los descomprimes en RAM...


Y @Señor Ventura tampoco habla dentro de un mismo BG, habla en general:

Señor Ventura escribió:P.D: En snes las tiles con menos colores, ocupan menos espacio.


Supongo que habrá sido todo un malentendido.






kusfo79 escribió:Sobre lo que comentas, hay 8(+1) modos en la Super Nintendo, y no se pueden mezclar, ya que los defines en el registro $2105 de la PPU para toda la pantalla. Lo que ocurre es que varios de los modos tienen diferentes profundidades de color dependiendo del plano. Como has comentado, el modo 1 era muy usado, y te permitía tener dos planos de 16 colores por tile (32 bytes por tile), y el tercer plano con 4 colores por tile (16 bytes por tile). No permite mezclarlo a voluntad ni nada parecido.


Así es, los modos no se pueden mezlcar, es como querer meter en la misma pantalla un trozo 1080p y otro a 480i, no tiene sentido lógico. Tampoco se puede hacer a mitad de pantalla por HDMA sin que se produzcan glitches gráficos descontrolados, ya que cambia cómo se eligen las paletas, TileNumbers, etc.
Lo que sí he visto es pasar del modo 2 al 1 y del 5 al 6 en frames consecutivos sin que se note, pero porque un frame completo ya se dibuja en un modo concreto diferente al frame anterior. Creo que esto lo hacía Treasure Hunter G, pasando de modo 2 al 1 cuando se tiene que mostrar texto, ya que éste aparece en BG3 con solo 4 colores (2BPP).



Señor Ventura escribió:Una pregunta tonta, y por mi parte no offtopiqueo mas, ¿con los sprites puedes mezclar unas tiles con una profundidad específica, a continuación de otros sprites con sus tiles a otra profundidad?, o las tiles de los sprites siempre ocupan 32 bytes.


Los sprites siempre son 4BPP y siempre usan una paleta de 16 colores, aunque se puede elegir en cada sprite una paleta diferente entre 8 disponibles. Muy útil esto para hacer personajes grandes en los que cada trozo del personaje (sub-sprite) use una paleta diferente optimizada para la zona que representa: cara, vestimenta, arma...
Las 8 paletas de 16 colores cada una ocupan los 128 colores primeros de CGRAM siempre.



Señor Ventura escribió:Editado: Cuando cambias la prioridad de un tile de un plano, ¿estás limitado a cambiarlo de capa?, o también puedes cambiarlo de posición al cambiar su prioridad.


Cuando cambias de prioridad un tile, estás cambiando el orden con el que se representa en pantalla, es decir, si piensas en la pantalla como una pila de capas una encima de otra (que no corresponden directamente con las BG), sólo estás cambiando en qué capa de representanción está dicha tile. Esto permite que una tile en BG3 por ejemplo tape un sprite si la tile tiene prioridad 1 o quede por detrás de él si tiene prioridad 0.





Señor Ventura escribió:Por ejemplo, un tile que está en el background 4 en la esquina superior izquierda, pasarlo al background 1, 2, o 3 pero en el centro. Esto sería cojonudo para tener un plano reservado a modo de "buffer", ya que como quedaría tapado por los demás planos, no se vería semejante amalgama de tiles ^^


Eso no es necesario. Creo que no entiendes bien cómo se crea la pantalla en estas consolas... Las tiles las tienes almacenadas en una zona de VRAM y luego las colocas como quieras en pantalla gracias al tilemap. Así, si tienes una tile en BG4 en la esquqina superior izquierda de pantalla, tienes las tiles físicamente por ejemplo en la dirección $0E78 de VRAM, y tú colocas esa tile en el centro de la pantalla siemplemente cambiando 1 byte, el que está en la posición central de pantalla en el tilemap.
El tilemap es como una rejilla, es como si dividieras la pantalla en 32x32 bloques de 8x8 píxeles cada uno; cada rejilla es una dirección de VRAM, donde se almacena una palabra de 16 bits.
Si quieres poner una tile en la esquina superior izquierda, tienes que escribir la dirección de VRAM (más exactamente, el TileNumber, que es una porción de la dirección de VRAM de x bits) en la posición 0 de la rejilla. Si quieres dibujar en el centro de pantalla esa misma tile, tendrás que escribir en la posición 32x16+16 de esa rejilla la misma dirección de VRAM que escribiste para dibujar la tile en la esquina superior izquierda. Es decir, la tile está en VRAM 1 vez, y en el tilemap aparece 1 vez por cada posición donde aparezca en pantalla.
Por eso no tienes necesidad de un tile buffer.
Señor Ventura escribió:
kusfo79 escribió:Mi primera pregunta era si se podían mezclar diferentes profundidades en un mismo plano, que ya suponía y comprobado que no. Lo preguntaba por que de lo que decía @Señor_Ventura se entendía eso (lo de que muchos de los tiles eran solo dos colores, pero no todos). De todas formas, he mirado como va el Another World en SNES y funciona de la misma manera que en mega. Está usando un solo plano como un framebuffer donde va dibujando todo (BG1).

Sobre lo que comentas, hay 8(+1) modos en la Super Nintendo, y no se pueden mezclar, ya que los defines en el registro $2105 de la PPU para toda la pantalla. Lo que ocurre es que varios de los modos tienen diferentes profundidades de color dependiendo del plano. Como has comentado, el modo 1 era muy usado, y te permitía tener dos planos de 16 colores por tile (32 bytes por tile), y el tercer plano con 4 colores por tile (16 bytes por tile). No permite mezclarlo a voluntad ni nada parecido.

Estaría bien si un moderador, como @salvor70, pudiera crear un hilo con esta discusión, es offtopic pero es interesante.


Lo que quiere decir es que tu puedes poner tiles de 1BPP incluso en un plano de 256 colores, pero ya no podrás usar otros tiles con otra profundidad de color en ese mismo plano.

Piensa que si los tiles estuviesen obligados de forma rigida a tener la profundidad de color que indique el plano del modo en el que trabajes, no existirían los tiles a 1BPP, porque no hay planos a esa profundidad de color.

Lo genial sería poder mezclarlos, pero al menos hay una solución factible para obtener buenos resuktados mezclando. Mi duda está en si un tile al que cambias de prioridad, se le puede cambiar también de lugar al "cambiarlo de plano" (nótense las comillas).


Después de mirar bastante la wiki (que al fin y al cabo, de la Super no he programado nada), he de decir que creo que lo que comentas no es cierto. El modo que tenga ese plano determina cuantos bytes ocupa cada tile en la VRAM. Por ejemplo, en el modo 1, los planos de 16 colores cogen 4 bytes por linea del tile, lo que hace que ocupen 32 bytes. Esos 32 bytes los tienes que setear en la VRAM sea como sea, aunque los tiles solo contengan dos colores. En los planos de 4 colores, necesitas 16 bytes para definir un tile, y tampoco te los puedes ahorrar de ninguna de las maneras. En los planos de 256 colores, usas un byte por pixel, como en el modo 13h VGA del msdos, con lo que cada tile ocupa 64 bytes. Luego existe el modo direct color, donde cada pixel está representado por un byte, y defines el color como BBGGGRRR (blue, green, red).

Aunque desconocía bastante como funcionaba realmente el PPU de la SNES, me parecía bastante raro el tema este de las profundidades de color mixtas, más que nada debido a que todo lo que hace la PPU está implementado por Hardware, y hay un límite a lo que se podía hacer en un chip diseñado a finales de los 80 sin convertirlo en un bicharraco.

Otra cosa es que para hacer determinadas cosas, como por ejemplo guardar algo como la demo de Bad Apple, tu codifiques dicha información en la ROM comprimida, donde la podrías guardar por ejemplo en dos colores, y luego tu la descomprimas en la RAM. Esto tiene la desventaja de que necesitas tiempo de proceso para descomprimir, y al final, igualmente, tienes que enviar a la VRAM la misma cantidad de bytes.

En todo caso, la solución que parece que usaron en el "Another World" es simplemente dibujarlo todo en el BG1 a 16 colores, usando la VRAM como un framebufer.

EDIT: Acabo de ver la respuesta de Magno, y creo que estamos totalmente de acuerdo, no entendí que es lo que comentaba antes :-)
magno escribió:Que va, no es así en absoluto. Si tú pones una tile 1BPP en un plano de 256 colores, te toca rellenar el resto de bits por píxel (los 7) de color 0 para que sean transparente.
La PPU de SNES sólo maneja tiles de 4 colores (2BPP), 16 colores (4BPP) y 256 colores(8BPP), y estos se pueden distribuir libremente dentro de cada BG según la tabla que linké más arriba.
Pero tú puedes usar tiles de 1BPP si quieres, pero luego en VRAM han de aparecer como 2BPP, 4BPP o 8BPP.
Algo muy típico que se suele hacer es trabajar con tiles de 1BPP en ROM o RAM y luego pasarlas a VRAM a tiles 2BPP dejando sin utilizar los otros 2 colores.
Lo que no se puede hacer nunca es mezclar en un BG son tiles de diferente profundidad de color: una vez está configurado la profundidad de color en un BG a través del modo, las tiles siempre ocupan lo mismo en VRAM.


Pues me he llevado un chasco, la verdad. Tiles a 1BPP hubieran sido tremendamente socorridas, y apenas ocupando memoria. Seguramente si hubiesen contemplado la idea, al menos habrías reconsiderado incluírlo, porque es una gran ventaja (para hacer sombras, por ejemplo, o superficies a contraluz, entre otros ejemplos... que siempre puedes repetir las tiles, pero los contornos no, y si necesitas muchos, pues ahí lo llevas).

Sobre la ultima frase, ¿significa entonces que en un plano configurado a 16 colores puedo usar tiles a 2BPP, pero van a ocupar 32 Bytes, como si fueran de 4BPP?.

(editado: aprovecho para preguntar, ¿cuanto ocupan las tiles de 16x8 del modo 5?, porque la demo del bad apple a 512x448 está hasta arriba de ellas).

magno escribió:Eso no es necesario. Creo que no entiendes bien cómo se crea la pantalla en estas consolas... Las tiles las tienes almacenadas en una zona de VRAM y luego las colocas como quieras en pantalla gracias al tilemap. Así, si tienes una tile en BG4 en la esquqina superior izquierda de pantalla, tienes las tiles físicamente por ejemplo en la dirección $0E78 de VRAM, y tú colocas esa tile en el centro de la pantalla siemplemente cambiando 1 byte, el que está en la posición central de pantalla en el tilemap.
El tilemap es como una rejilla, es como si dividieras la pantalla en 32x32 bloques de 8x8 píxeles cada uno; cada rejilla es una dirección de VRAM, donde se almacena una palabra de 16 bits.
Si quieres poner una tile en la esquina superior izquierda, tienes que escribir la dirección de VRAM (más exactamente, el TileNumber, que es una porción de la dirección de VRAM de x bits) en la posición 0 de la rejilla. Si quieres dibujar en el centro de pantalla esa misma tile, tendrás que escribir en la posición 32x16+16 de esa rejilla la misma dirección de VRAM que escribiste para dibujar la tile en la esquina superior izquierda. Es decir, la tile está en VRAM 1 vez, y en el tilemap aparece 1 vez por cada posición donde aparezca en pantalla.
Por eso no tienes necesidad de un tile buffer.


Me he explicado mal. No necesitas un tile buffer porque la VRAM ya es un tile buffer, pero dada la limitación de que solo puedes tener tiles de una sola profundidad de color por plano, la única manera de tener 2 tiles diferentes en ese plano, es que procedan de planos diferentes alterando su prioridad, por eso la VRAM como tile buffer para conseguir dos tiles de diferente BPP en un mismo plano no te sirve en este caso.

Leí hace tiempo que incluso puedes alterar la prioridad de pixels sueltos, en lugar del tile entero. No recuerdo exactamente de donde, así que lo cojo un poco con pinzas, además de que me suena un poco raruno.


Lo preguntaba porque tal vez los tiles de un plano no solo pudieran alterar su proridad, sino su coordenada en pantalla al ser movido a otro plano, y es que en algunos juegos se ve algo parecido a esto:
Imagen



Se usa el tercer plano paratraer las tiles de 2BPP del cielo y del contorno de las montañas para formar parte del BG1. El BG1 por su parte es generado directamente desde la VRAM, pero debe usarse el BG3 para que comparta en un mismo plano (el BG1), tiles de 2BPP, y las tiles de 4BPP que menciona Kusfo.

Ahora, lo que me llama poderosamente la atención, es que cada tile del BG3 no corresponde exactamente con su posición en el BG1. Define un area mas pequeña (marcada en rojo en la imagen), por lo que da la impresión de que el resto del cielo está conformado trayendo tiles del BG3 al BG1, pero no solo alterando su prioridad, sino también sus coordenadas en pantalla:
Imagen


Espero no equivocarme, porque si esto es así, entonces puedes alterar la prioridad de tiles, ponerlas donde quieras, y repetirlas las veces que quieras.

kusfo79 escribió:Después de mirar bastante la wiki (que al fin y al cabo, de la Super no he programado nada), he de decir que creo que lo que comentas no es cierto. El modo que tenga ese plano determina cuantos bytes ocupa cada tile en la VRAM. Por ejemplo, en el modo 1, los planos de 16 colores cogen 4 bytes por linea del tile, lo que hace que ocupen 32 bytes. Esos 32 bytes los tienes que setear en la VRAM sea como sea, aunque los tiles solo contengan dos colores. En los planos de 4 colores, necesitas 16 bytes para definir un tile, y tampoco te los puedes ahorrar de ninguna de las maneras. En los planos de 256 colores, usas un byte por pixel, como en el modo 13h VGA del msdos, con lo que cada tile ocupa 64 bytes. Luego existe el modo direct color, donde cada pixel está representado por un byte, y defines el color como BBGGGRRR (blue, green, red).


Lo que voy a decir... ¿como se implementan 256 colores en un tile, cuando solo tienes 64 pixels?, ¿mezclando colores? :-?

Es una parte de la snes que no he mirado mucho, la verdad, eso del direct color, y tiles de 8BPP... se habla de 256 colores usando tiles de 8BPP, de hasta 400 mezclando planos, y de hasta 2000, no se de que manera. Seré manco buscando información, pero nunca he encontrado documentación concreta sobre eso.

kusfo79 escribió:Otra cosa es que para hacer determinadas cosas, como por ejemplo guardar algo como la demo de Bad Apple, tu codifiques dicha información en la ROM comprimida, donde la podrías guardar por ejemplo en dos colores, y luego tu la descomprimas en la RAM. Esto tiene la desventaja de que necesitas tiempo de proceso para descomprimir, y al final, igualmente, tienes que enviar a la VRAM la misma cantidad de bytes.


Si, es lo que comentaba de la demo del bad apple a alta resolución. Hay ahí tiles para parar un carro, concretamente 1792 tiles, a 30fps.

kusfo79 escribió:En todo caso, la solución que parece que usaron en el "Another World" es simplemente dibujarlo todo en el BG1 a 16 colores, usando la VRAM como un framebufer.


He encontrado lo que parece ser una discrepancia (como puedes ver mas arriba). No se hasta que punto parece tener sentido, pero en un principio parece tener su lógica.
Pues a lo que comentas de los 256 colores, obviamente no puedes tener 256 colores diferentes en un mismo tile, pero ese plano puede contener 256 colores, y cada tiles hasta 64 (por el numero de pixeles que contiene).

Lo que comentas del BG3 del another World le echaré un ojo, no tengo muy claro para que se usa, cuando deshabilitaba el plano BG1 me desaparecía todo lo de la pantalla. No se si es algun efecto o similar tipo shadow/highlight de la mega.
Y este post con lo del PPU de Super aquí metido? XDD
20 respuestas