naxeras escribió:De hecho todos los ejemplos que ha puesto esos sprites se mueven de culo, nada que ver con un juego de peleas donde las amimaciones con mucho mas fluidas.
Entonces, ¿no hay duda de que puedes poner un objeto a base de sprites tan grande como la pantalla?.
¿El argumento pasa a ser el número de tiles de sprites que puedes actualizar porque tenemos ya claro que puedes dibujar un metasprite tan grande como la pantalla?.
Si la respuesta es si, entonces cualquier hardware podrá actualizar las tiles de un sprite gigante según el tiempo de DMA que permita el uso de la CPU.
Si necesitas el 50% del tiempo de un frame para que la cpu haga sus tareas, entonces te queda el 50% de tiempo de DMA para que este haga las suyas (transferir).
Si snes tiene un ancho de banda total de 6,32KB, y le restamos los 40 master cycles a mitad de renderizado del line buffer para refrescar las celdas de la WRAM, te queda un ancho de banda total de 6,14KB.
De esos 6,14KB puedes usar solo el 50% porque la cpu ha estado ocupada el 50% del tiempo de un frame. Esto son 3,07KB para transferir cosas.
Reservamos 544 Bytes paa actualizar toda la OAM en caso de ser necesario, reservamos 512 Bytes por si queremos cambiar TODA la información de color dentro de un frame, y obviamos la tabla de transformación de matrices para el modo 7, y el índice de tiles de los planos, porque es relativo.
Aún reservando 1,032KB, que resulta exagerado, puedes contar con 2KB limpios para actualizar sprites (bastante mas en condiciones normales, pero nos conformaremos con el ejemplo).
2KB de tiles de sprites son 64 tiles de sprites.
Pero además existe un lag entre que demandas una animación, y hasta que sucede. Pueden pasar entre 2 y 3 frames acumulando tiles de sprites para actualizar en "paquetes" de hasta 64 tiles de sprites.
Así que una situación exagerada de poca transferencia podrías actualizar 192 tiles de sprites. Esto sin bandas negras de ninguna clase, sin contar el scanline 0 que se desactiva para preparar las funciones de los ppu's, y que no vemos por el overscan.
Una pantalla tiene 896 tiles. Puedes actualizar un sprite que represente el 21,42% del tamaño de la pantalla con una animación parecida a la de los sprites del donkey kong country (es decir, muy fluído). Sin bandas negras.
En condiciones normales, mas bien aspiraría a actualizar un sprite la mitad de grande que la pantalla con una tasa de animación muy alta, sin bandas negras, y dedicando mucho tiempo de cpu.