No me he leído todo el hilo porque luego se me olvida lo que quería escribir, pero aclarar una cosa porque he leído cosas contradictorias:
* la multiplicación de 24 bits que realiza la PPU realmente es una multiplicación matricial 2x2 que se usa para posicionar el plano del modo 7; cuando no se usa el modo 7, esta multiplicación de matrices se puede usar para obtener resultados de 24 bits o para seguir haciendo multiplicaciones de matrices y así rotar sprites.
* mientras se realiza esta multiplicación (que en realidad es muy rápida en ejecución, pero se ha de usar varias instrucciones para cargar todos los valores de la matriz), se puede seguir haciendo scroll, actualizar BGx y lo que se quiera.
* Final Fantasy 6 usa esta multiplicación, en vez de la estándar en $4202/03, para hacer cálculos en los menús: HP, MP, status de los personajes, etc. En mi versión sustitui todas las multiplicaciones de 24 bits por multiplicaciones de 16, ya que las de 24 esperaban al blanking (aunque no sé si es necesario) y por tanto terminaban siendo más lentas en media: si estabas cerca del H-Blank, la multiplicación de 24 bits era un par de ciclos más rápida, pero si no, la multplicación de 16bits era muchos ciclos más rápida, además de que desde que programas los multiplicandos hasta que obtienes el producto puedes ir ejecutando otras instrucciones. Por eso, y por otros cambios que hice, mi versión no tiene el bug en la pantalla del menú.
Señor Ventura escribió:Lo que ocurre es que lo que nos estaba marcando las pautas de la conversación es el poder de cálculo de los PPU's, así que la longitud de cada scanline es en lo que toca centrarse, porque la resolución horizontal es lo que afecta a la capacidad de cálculo y fill rate del sistema de vídeo (no la vertical).
Es justo lo contrario... Las limitaciones vienen por la resolución vertical, no la horizontal. La explicación es porque todos los cálculos para la pantalla los tienes que hacer antes de que llegue la siguiente interrupción NMI (eso quiere decir, antes de que llegue el siguiente VBlank), por tanto, cuando menos líneas tengas que "calcular" mejor. Por eso la SNES tiene el modo "overscan", en el NMI salta en la línea 226 de pantalla o en la 240: si salta en la 240, tienes más tiempo en el frame para calcular las cosas, pero menos tiempo en el NMI para enviarlas a VRAM, por lo que igual no te sirve de nada calcular tanto para luego no poder enviarlo a pantalla. Lo normal en el 90% de juegos es dejar configurado el modo sin overscan, saltando el NMI en la lñinea 226.
Señor Ventura escribió:
Es decir, que en teoría eso significa que puedes coger varios sprites, y hacer que ocupen un solo slot en la tabla OAM... a menos que el juego utilice dos sets de sprites diferentes para el mismo dibujo del mono en cada uno de sus frames de animación, pero sería tan estúpido que eso queda descartado.
En definitiva, que poderse rotar varios sprites como si fueran un solo objeto es posible, porque parece ser que se puede convertir en un único objeto.
¿La pega?, que en el super aleste la configuración de sprites en el momento en que sale la bola, es de 16x16 y 32x32, así que no puedes hacer que esa bola ocupe un solo slot en la tabla OAM porque ocupa 64x64 pixels, y no es lo configurado.
¿La parte buena?, que puedes cambiar la configuración de sprites al vuelo de un frame a otro para que los objetos de 64x64 ocupen un solo slot cuando no se requieran sprites de 16x16, y así ahorrar rutinas de rotación si tienes que rotar muchos sprites para salvar ciclos de reloj... puedes hacerlo incluso con las resoluciones (aunque esto es otra cosa).
No puedes cambiar la configuración de tamaño de sprites a 64x64 porque la SNES tiene un bug con ese modo. Aunque se pudiera, eso no se haría nunca porque te da poca capacidad de reutilizar sprites, además de por la detección de colisiónes, sobra mucho espacio "vacío" entre el perfil del personaje y el "bounding-box" que forma la rejilla 64x64.
Lo que se hace en todos los juegos de SNES es formar un objeto en memoria ROM que dice cómo está formado el sprite completo del personaje: por ejemplo, 3 sprites 16x16 y 5 sprites 8x8, junto con sus posiciones relativas respecto a una coordenada que definas del personaje: centro de masas, esquina superior derecha, superior izquierda, inferior izquierda, lo que sea... En ROM existe un objeto de estos para cada frame de animación del personaje, otro objeto que dice qué tiles correspoden con los 3 sprites 16x16 y los 5 8x8, y luego otra tabla que configura, para cada movimiento del personaje, qué frame usar.
Todo esto lo tengo bien explicado en el código del Treasure Hunter G que planeo liberar algún día por si alguien se anima a ayudarme a hacerle ingeniería inversa total al juego.
Resumiendo, para animar a un personaje como Donkey Kong:
* En cada frame, antes del NMI, se comprueba qué acción está ejecutando el personaje (andar, saltar, correr, rodar...)
* Se accede a una tabla que indica cuántos frames ha de estar el personaje en una postura determinada para completar la acción
* Para la postura actual del personaje se lee de ROM la composición de sub-sprites y se envía a OAM en el NMI
* Para la postura actual del personaje se lee de ROM las tiles que componen cada uno de esos sub-sprites y se envía a VRAM en el NMI
* Si se ha terminado la cantidad de frames en esa postura, se pasa a la siguiente postura de animación y se repite el proceso
Creo que hay demasiadas suposiciones y afirmaciones incorrectas en el hilo que no ayudan demasiado a hacerse la idea correcta de cómo funciona la SNES....
![[chulito]](/images/smilies/nuevos/sonrisa_ani2.gif "risa con gafas")
![[risita]](/images/smilies/nuevos/sonrisa_ani1.gif "risita")
