cirote3 escribió:7Force escribió:Yo entiendo que es al revés: el tener los mismos enemigos te permite tener almacenado el mismo frame, ahorrando memoria y transferencia de datos. Es indiferente que uno esté dando un puñetazo, otro un salto y tal, en el sentido que si ya tienes cargado ese frame para 3 enemigos, no vas a tener que cargar otro cuando sea necesario.
@M68K ya demostró que en el Turtles in Time se almacenan todas las animaciones de los enemigos en VRAM, gracias a que se repiten mucho y son pequeños. Como los únicos tiles a cargar en caliente son los de las tortugas, ahorras muchas transferencias de datos y evitas bandas negras. Eso no se puede hacer en otros beat'em ups con personajes más grandes y enemigos más variados, como los Final Fight. Por eso no deberían compararse.
Por reforzar esto mismo que
@cirote3 comenta, lo hacían beat em ups que se podían permitir ese lujo de tener esos tamaños más pequeños o/y tener todas las animaciones listas en la memoria de vídeo para evitar tanta transferencia y que la CPU se dedique exclusivamente a cálculos (es que estoy leyendo por parte de "algún" usuario ciertas contradicciones a todo esto que comentamos).
@7Force , lo has entendido perfectamente. Si todas las animaciones de un enemigo están almacenadas, no tienes la necesidad de transmitir nada, da igual que haya 1 que 20 con posturas diferentes. Como comenté, en TMNT: TiT tienen un banco entero de 8KBs (de un máximo de 2 para sprites) lleno de todas las posibles posiciones de los enemigos (los perritos robóticos son aún más pequeños y entran tranquilamente en el espacio sobrante del banco reservado para los sprites de los protagonistas, siendo 4 frames para caminar, 2 para abrir/cerrar la boca, 1 para mostrarse de frente cuando rompen los critales y 1 frame de animación para la postura de "daño recibido").
Aquí el problema viene de si alguien quisiera meter más animaciones (imagina, yo que sé, una postura de victoria con las manos hacia arriba) o personajes más grandes (requerirían por cada postura más tiles y ya no encajarían como querían dentro del espacio reservado para las posiciones de los sprites enemigos).
Curiosamente, me he metido en un desarrollo de hack de AlienStorm (iremos tanteando meter hasta 3 players) con un amigo, y aquí se hacía exactamente lo mismo:

El cuadrado rojo es la zona de reserva de hasta 30KB donde meten TODAS las posibles posiciones enemigas, y el cuadrado verde es la única zona dinámica de la VRAM que transfiere las posibles posiciones de los personajes. Incluso cuando entras a las tiendas en modo 1a persona para disparar hasta a 8 enemigos simultáneos en pantalla con todos los efectos de destrozo que se ven, ahí tan sólo cambia los tiles para los disparos del prota.
- Lo malo de este tipo de almacenamiento es que deja menos espacio para la variedad gráfica de escenarios siendo estos más pobres o repetitivos.
- Lo bueno es que cualquier cambio de postura, como si cambian de postura 7 personajes al mismo tiempo, lo pueden hacer de frame a frame sin tener que estar repartiéndose los frames entre los personajes para cambiar de postura.
En este aspecto también existe también la posibilidad de ahorrar VRAM para la animación de un personaje como para ahorrar transferencias gráficas.
Esto sería la animación mediante el movimiento de partes de un metasprite estático (aquí sólo se mueve la posición de la zona alta del metasprite)

Y algo bastante más bestia ya sería hacerlo con metasprite multi-articulados.
Con tan solo estos tiles que hay en la imagen, sin necesidad alguna de transmitir nada ni ni ocupar más espacio en VRAM, puede realizar todas las posiciones necesarias que se ven en el gif


(aunque esto tiende a requerir LUTs o capacidad de cálculo pero ahorraría ambas cosas, ancho de banda y VRAM)
Al final se trata de cómo quieras usar los recursos que tienes y si el sistema y el código pueden seguir el ritmo de lo que quieras ver en pantalla.