Perdón por la tardanza. No he contestado a todo, pero es que últimamente no tengo tiempo para casi nada, y se me escapan cosas.
Allá va:
wave escribió:Correcto, el color transparente solo es un numero de color que la snes no pinta (el 0 si no recuerdo mal)
Esto hablando de espacio en VRAM, donde tanto SNES como Megadrive tienen 64KB.
¿Que hay de la compresión?. Hasta ahora no he leído nada de que no se puedan repetir las mismas tiles en un sprite (tal vez sea una burrada, pero ya digo que no estoy informado).
pocket_lucho escribió:Pues es que el modo 7 no lo he llegado a tocar aún, pero vamos, creo que son 2 capas a 16 colores y una de ellas la que se puede rotar, ampliar y 'sesgar' más luego los sprites como siempre. La putada son las cacho tablas para transformaciones que necesita, que se meriendan la vram cosa mala.
No, no, los mapas de tiles pueden llegar los 256 colores (16 colores por tile, es decir, 16 paletas diferentes para todo el tilemap), con un tamaño de hasta 128x128 tiles (1024x1024 pixels... esto a una resolución de 256x256, ocupa 4 veces la pantalla).
En el f-zero, lo que se hace es ir cargando cada tile map, según la posición de la nave. Gracias a ésto, los circuítos llegan a alcanzar tamaños todavía mas grandes que eso.
Importante: Las tablas para las transformaciones del modo 7 se almacenan directamente en la memoria ram, y los tilemaps en la vídeo ram, en direcciones de memoria que ocupan 2 bytes: el inferior determina el mapa, y el superior el tile.
Mi duda era mayormente sobre el comportamiento y limitaciones de ese segundo plano:
-¿Un plano en modo 7 a 256 colores, impide la creación de un segundo plano?.
-El segundo plano que no tiene las caracteristicas de transformación del otro plano, ¿que límite de tamaño puede tener?, ¿depende de la memoria de vídeo restante?, o tiene un límite fijo.
-¿Que hay de los colores?, ¿su límite es de 128 colores?, o sería posible jugar con ese margen si decido que el plano "A" no disponga de mas de 16.
pocket_lucho escribió:Lo de los tiles... te explico lo que hay en la vram resumidamente... dos tablas para los 128 sprites que ocupa siempre lo mismo, si no usas un sprite tiene sus valores a 0, pero sigue ocupando lo mismo, la diferencia de no usarlos es para que las ppu los ignore, pero la vram la ocupan.
El oam no es como dos tablas independientes, sino una sola tabla que se parte en dos (porque, digamoslo así, la información está interconectada). La primera tabla ocupa
512 bytes en la memoria de vídeo, y la segunda
32 bytes.
Es decir, que a parte de la información sobre la profundidad de color de los tiles en la vram, tenemos
una primera tabla que determina:
-
Byte 1: Posición X del sprite en la pantalla (0-255)
-
Byte 2: Posición Y del sprite en la pantalla (0-255)
-
Byte 3: Número de tile que representa al sprite. Este tercer byte conforma el aspecto final de los sprites.
-El
cuarto byte está conformado por:
·1 bit para la posición horizontal
·1 bit para la posición vertical
·2 bits para la prioridad (superposición)
·3 bits para la paleta de colores
·1 bit para el número alto del tile (debe ser una cabecera que es usada de referencia en el tercer byte, para determinar con que otros se unen)
La
segunda tabla proporciona 2 bits mas de información por sprite (128 sprites*2bits=256bits/8=32bytes), pero ahora mismo no se decir que funciones ocupan en ella, lo siento ^^u
pocket_lucho escribió:En la megadrive, pues lo mismo, aún habiendo 64 kb de ram, hay unas zonas reservadas para la tabla de sprites (sólo hay una), otra para las capas y otra para las paletas. Lo que queda para tiles, en concreto con las SGDK hay sitio para 1392 tiles, 'vacios' o no cmo a ti te gustan xD. La snes es un poco infierno y no te sabría decir un número exacto, pero son menos
Se puede calcular.
A 256x224 tenemos 57344 pixels, y un tile ocupa 8x8 pixels=64 pixels por tile. 28x32 tiles hacen un total de 896 (256*224=57344/64=896), pero, ¿cuánto ocupan 896 tiles en memoria?.
Nota: No hablamos de que exista una mayor capacidad en megadrive para mostrar tiles, sino que, al contrario de como suena, en su caso debido a la mayor resolución se hace necesaria una mayor cantidad para llenar la pantalla (cosa que deja menos margen para otras cuestiones, como los sprites).
Cada tile de 16 colores ocupa exactamente 32 bytes, es decir, 896*32=28Kbytes deVRAM (28672 bytes justos). Que conste que todo el tilemap no tiene por qué estár limitado a una sola paleta (dependiendo del modo), tambien se pueden usar tiles a 16 colores, a 32, 64, 126, 256... el punto, es que gracias a su enorme paleta hace menos falta usar tiles de muchos colores para obtener grandes resultados (y que cuando se precise, se puede echar el resto para lucir graficazos, como por ejemplo para sprites, y zonas complicadas en el tilemap de un fondo).
Ya con un fondo creado, le sobra mas de la mitad de de la memoria para organizar el diseño de un juego como se precise. Que conste que hablamos de un fondo sin absolutamente nada de compresión (tiles repetidos).
A snes le quedan libres 36Kbytes(36864 bytes) en la vram para almacenar 1152 tiles mas, de 16 colores cada uno (a menos que se precisen tiles de mas colores). A esto hay que restarle los 544 bytes que ocupan las OAM, así que hacen un total de 1152-544/32=
1135 tiles para objetos, y demás extras (de sobra para gestionar ese límite de 128 sprites, y siempre y cuando la demanda de computación lo permita).
Nota: El espacio que ocupan las OAM, equivalen a 17 tiles de 16 colores.
Una duda que tengo:¿Es físicamente posible darle una profundidad de color a un tile de 64 pixels?, ¿no serían necesarios 4 tiles/256 pixels?. Quizás esté errando con el concepto de mala manera, pero pregunto.
No es tan negativo como lo pintabas, ¿no?

Blaster Master escribió:Mas que de los 64 colores en pantalla yo me quejaria por la escasa paleta,64 (o mas,con truquillos) colores simultaneos esta bien,pero 512 de paleta y muchos no bien escogidos pues no tanto...
De aumentarle algo a la mega, yo me decantaría por una paleta de 32000 colores, antes que poder mostrar mas de 64 colores. A 320x224 sería ya un poco justito para esos 64Kbytes de vram.
Si ya trabajar con tiles amarga un poco en megadrive, con mas colores sería un trabajo de chinos. En este sentido, la lacra de resolución en snes, y su enorme paleta, hacen de este sistema mucho mas amigable para trabajar (irónicamente es así xD).
Luego hay casos contrarios, como el margen que da la mega con el 68000... o de nuevo contrarios, como los resultados del spc, frente al yamaha de megadrive, y su único canal pcm.
Cada sistema tiene su cosa, pero precisamente el vídeo, es mucho mas amigable en snes (y esto sin contar con la cantidad de cosas que hace por hardware, y no necesita ser programado a parte).
naxeras escribió:Una pregunta sobre el zoom y rotaciones de SNES (Modo 7).
¿La SNES no permite escalado y rotación de sprites? ¿Solo de planos?
¿Entonces en los juegos que se ve un personaje siendo escalado y rotando como lo hacen?
Es una duda que tengo cada vez que veo los malos del Super Mario World (rotaciones) o cuando va el bowser en la nave esa.
Un Saludo.
Por partes.
1- No permite escalado y rotación de sprites, sólo lo permite de un único plano simultaneo... y cuando esto sucede, el modo en que se trabaja para acceder a esas rutinas gráficas solo permite dibujar otro plano mas (mas los sprites, obvio), y sin los atributos de rotación y escalado.
2- "Objeto/personaje" no es lo mismo que "sprite". Generalmente son planos, aunque hay excepciones. En wolfstein 3D tenemos sprites que son escalados por software, gracias al margen extra de computación que dejan los escenarios generados por modo 7.
Tambien tenemos casos de pseudo escalado por software, como en los art of fighting 1 y 2. Esto ocupa mucha menos computación, y en un ritmo rápido de la acción da absolutamente el pego.

EDIT:
En cuanto pueda sigo contestando cosas