devido al tamaño. en un CPC real hace falta tener un dandanator CPC donde grabar la rom.
el juego es inviable en disco, ocupa unos 490k. harian falta muchos discos.
pero el problema no son los discos, sino la cantidad de informacion a la que se accede simultaneamente.
tendria que leer de disco en cada cambio de pantalla y seria inviable.
Os explico asi muy rapidamente y muy resumido lo que es y hace el dandanator.
Es un banco de memoria de 512k, dividido en 32 paginas de 16k, que nos permite ponerla encima de la memoria del CPC como si fuera una ROM.
al paginar una pagina rom del dandanator cualquier lectura a esa posicion de memoria la lee del dandanator como si la estuviera leyendo de la memoria, tarda lo mismo es acceso instantaneo, cualquier escritura a esa posicion de memoria lo hace sobre la memoria fisica del CPC de forma transparente.
hasta ahora solo se habia utilizado como almacenamiento como un gestor de snaps de juegos...
que metia los juegos/snaps en las paginas de la rom y los descomprimia a memoria para jugar a ellos. una vez se lanza el juego el dandanator se desactivaba.
Pero despues de la conversion que hice del Ianna original de zx 128k para que funcionara en un ZX con solo 48k.
Dije y por que no en CPC?
Asi que en el Ianna CPC hemos aprovechado los 512k de la rom para alamacenar los mapas, los tiles, los sprites, la musica, y el codigo del juego sin comprimir.
esto permite que el juego con la correcta programacion pueda ser capaz de usar lo 512k extras instantanemente sin necesidad de copiar las datos a la memoria del CPC.
por ejemplo.
los tiles de cada nivel son 256 tiles de 16x16 pixeles en modo1, cada 8 pixeles horizontales ocupa 2 bytes
osea 256x2x16=16384, los tiles para imprimir cada pantalla ocupan un slot de 16k completo.
En ZX los tiles de cada nivel ocupan unos 4k.
a la hora de generar cada pantalla, lo que se hace es poner el slot del dandanator en una posicion la memoria del CPC 0x8000
y se imprime directamente a memoria de video desde el propio cartucho.
igual para los sprites de los enemigos que esta cada uno en un slot del dandanator.
y preguntareis por que no cabe en un CPC 6128 si cabia en un ZX 128 y tienen la misma memoria, y los mapas son iguales y los sprites parecen iguales....
la principal diferencia es en el apartado grafico.
en el zx la pantalla ocupa 6912k unos 7k, como se usan 2 pantallas main y shadow hacen un total de 14k.
en el cpc la pantalla ocuparia 16384k, pero se ha adaptado para la resolucion de zx y solo ocupa 12k, pero como son 2, en total ocupa 24k.
basicamente los sprites ocupan el doble por ser modo1, si fuera modo 0 ocuparian el cuadruple a la misma resolución.
para cada nivel se accede aproximadamente a 200k de información de forma continua.
al usar la memoria extra del dandanator el juego esta pensado para poder funcionar el cualquier modelo de CPC, incluido el 464 con solo 64k.
asi unas cuentas rapidas de la memoria que se necesita acceder para cada nivel en tiempo de ejecucion...
24k para el codigo principal del juego (en memoria principal)
24k para las dos pantallas main y shadow (en memoria principal)
16k para los sprites de las animaciones del barbaro (en memoria principal) ya que cambian los sprites al cambiar de arma
y hasta aqui nos llegan los primeros 64k
el resto ya se usa directamente los slots del dandanator.
12k para el mapa de 8x8 (64 pantallas maximo por nivel) (en slot dandanator)
16k para los tiles del nivel (en slot dandanator)
8k por cada enemigo simple que se encuentre en el nivel (en slot dandanator) entre 3 y 5
16k por cada enemigo doble que se encuentre en el nivel. (en slot dandanator) entre 1 y 3
5k para la musica y FX (en slot dandanator) la musica tambien se reproduce desde el dandanator aunque el player esta en el codigo principal en memoria
3k para el menu pausa (en slot dandanator)
16k para el menu principal (en slot dandanator)
luego las pantallas de la intro , el final y los creditos estan guardadas en unos cuantos slots.
espero que no sea muy ladrillo de leer
Saludos