No me atreveré a anunciar el proyecto de manera "oficial" porque ni siquiera estoy seguro de si acabaré terminándolo, debido a lo ambicioso que es. Me limitaré a contaros lo que tengo por ahora.
He estado desde agosto intentando portar el Heroes III con PAlib. Le abré dedicado en total unos tres o cuatro días completos (algunas tardes me da por trabajar en él, y luego me tiro varias semanas sin tocarlo hasta que me vuelven las ganas
![[jaja]](./images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
)
Tengo parte del sistema de batalla implementado y todos los sprites y sonidos ripeados del juego original. Estoy usando DualSprites de 64x64 en 256 colores. He decidido usar la DS como un libro para jugar, 90º girada a la derecha desde su posición "normal" (180º girada desde la posicion "Brain Training").
Lo primero que hice fue implementar el movimiento sobre el terreno de batalla por hexágonos, a través de un algoritmo con detección de colisión que es capaz de buscar el camino más corto para ir de un hexágono a otro partiendo de la velocidad que se le asigne a la unidad.
Y después hice un método para determinar el orden de acción de las unidades según un parámetro que bien podía ser el ataque o el daño de la unidad (no estoy seguro de qué depende exactamente).
Tras eso, me di cuenta de que la VRAM de la DS se llena con sólo meterle 32 sprites de 64x64 pixels en 256 colores (recordad que estoy usando DualSprites). Y eso me desanimó bastante, porque cada unidad tiene unos 40 sprites entre todas las animaciones de ataque, defensa, movimiento, muerte, etc. Así que si hay 7 unidades por jugador, más animaciones de héroes (en verdad sólo tienen una: cuando lanzan un hechizo) y de hechizos, máquinas (tienda de primeros auxilios, catapulta, balista y carro de municiones) y botones necesitaría muchísima más memoria de vídeo de la que la DS ofrece.
Sin embargo, no estaba todo perdido. Si conseguía implementar un sistema de archivos usando PAFS y dividía las "tiras" de sprites en archivos más pequeños (uno para la animación de ataque, otro para la de defensa, otro para cuando está quieto sin moverse) y los cargaba dinámicamente cuando fuesen necesarios tal vez podría continuar.
Y aquí estoy intentando figurarme cómo conseguir eso. Repartir la VRAM es realmente complicado cuando se tienen unidades de gran tamaño en pantalla. Suponiendo que en principio sólo pusiera una de las razas, limitándome así a 7 únicas unidades, no sería muy difícil. Pero como quiero meter todas las unidades debo contar con que 14 de los 32 sprites cargados en VRAM tendrán que ser unidades inmóviles en el campo de batalla para que se vea dónde están; 2 para los héroes; si hay máquinas hasta 4 más para las unidades (en caso de que ambos jugadores tengan 4 máquinas basta con clonar el sprite de manera que no gastemos más memoria); y para los botones 1 ó 2 (estos serán de 32x32, así que caben más). Así que alrededor de un 21/32 ~ 65% de la VRAM estará ocupado de forma fija en todo momento, y me queda un 35% para cargar animaciones dinámicamente. Y eso sin tener en cuenta otros elementos fijos en el terreno de batalla como obstáculos, trampas (minas, barreras mágicas) y (me echo a temblar al pensarlo) cada una de las partes del castillo, en caso de que la batalla sea un asedio. Está muy ajustado y es complicado de gestionar. Ah, y aún no me he parado a pensar en si la carga de archivos ralentizará demasiado el juego... Tan sólo espero que no sea así.
¿Alguien que conozca bien el juego, el hardware de la DS y PAlib se le ocurre un mejor sistema para repartir la VRAM? Tal vez me estoy complicando demasiado porque desconozco algo...
Y no me digáis que me rinda y use sprites de 32x32. ¡Si es posible, incluso si es muy complicado, querría usarlos de 64x64, que ya se pierde bastante resolución con respecto a los originales! xD
Perdonad el tocho texto.
![[tomaaa]](./images/smilies/nuevos2/tomaa.gif "toma")
Edit: Adjunto una captura para estimular vuestra contestación
En esta imagen tomada con el No$GBA se ve un piquero que estaría justo en medio de las dos pantallas, es decir, la mitad del piquero se vería en una pantalla y la otra mitad en la otra. Las unidades se mueven de una pantalla a otra sin problema y se muestra sombreada la zona hasta donde pueden moverse. El fondo es uno de los terrenos de batalla del juego. La rejilla de hexágonos es parte del fondo.
): 
