Uno de los motivos que me hacen seguir cacharreando con el c64 es quitarme mi espina clavada:hacer un juego en ensamblador para el commodore.
Y, para empezar, quisiera resolver dos primeros problemas: el mapa, y el scroll.
Lo que quisiera conseguir es tener un mapa continuo, con scroll fino, y con libertad de movimiento del personaje. Es decir, tipo Turrican.
Os comento mi planteamiento inicial, para ver si me podeis echar una mano, e ir acumulando ideas:
Sobre el mapa:
- Basado en tiles: los tiles podrían ser de 8x8 caracteres, o de 4x4 caracteres.
Si los tiles son de 8x8, la variedad de graficos es poca, es más dificil combinar tiles entre sí, pero los requisitos de memoria, y el numero de indirecciones a hacer en el pintado de la pantalla, es menor.
La memoria para almacenar los tiles, es mayor que si fueran de 4x4
Si tenemos un máximo de 256 tiles:
En el caso de 8x8, la memoria requerida es 256*8*8=16Kb
En el caso de 4x4, la memoria requerida es 256*4*4= 4Kb
Sin tener en cuenta espacio para marcadores:
Un mapa de 128x32 tiles de 8x8 , equivaldría a unas 25 pantallas de ancho por unas 10 de alto, y ocuparía 4Kb
Un mapa de 256x64 tiles de 4x4, sería un tamaño de mapa equivalente, y ocuparía 16Kb.
O sea, en uso de memoria para almacenar posiciones, los requisitos de memoria serian iguales.
Sobre el color:
No me he puesto a estudiar todos los modos posibles, y cual seria el mas adecuado, pero voy a suponer, en principio, que hay 2 comunes, color de fondo, y que libre queda el color de primer plano.
El color de primer plano podría :
1) Ir asociado al caracter: el caracter se representa con el mismo color esté en el tile en el que esté.
2) Ir asociado al tile : todos los caracteres de un tile, tiene un mismo color de primer plano.
3) Ir asociado a la posicion dentro del tile: cada tile tiene, ademas de 8x8 o 4x4 caracteres, 8x8 o 4x4 colores.En el caso de 8x8, necesitaria 16K (8k codificando 2 colores por byte).En el caso de 4x4, necesitaria 4k (2Kb, codificando 2 colores por byte)
Sobre los tipos de objetos del mapa:
El código de caracter debería codificar información del tipo:
- Si codigo & 0x80, el caracter no es atravesable. (Tendríamos 128 caracteres para objetos atravesables, como suelo, etc, y otros 128 para no atravesables)
- Si codigo & 0xC0 == 0xC0, el contacto con el caracter te mata (Tendríamos 64 caracteres para objetos no atravesables que no matan, y otros 64 para caracteres no atravesables que sí matan)
Así se podrían codificar esas propiedades o cualquier otra.
Sobre el dibujado del mapa y el scroll:
Este modelo no es el tipico de naves donde el scroll es independiente de lo que haga el jugador: el jugador es libre de moverse en cualquier direccion.
El modelo es que existe un rectangulo invisible en el centro de la pantalla.Si el usuario se mueve dentro de ese rectángulo, la pantalla está fija.
Supongamos que el jugador está justo en el borde de ese rectángulo.Si se mueve 1 paso más, se saldría del rectángulo, y provocaría el scroll.
En el turrican, el scroll es inmediato.Se ve que el jugador "empuja" el mapa.El problema es que la nueva pantalla, tiene que ser pintada inmediatamente.
Pero, si miramos el Sams Journey, es diferente: al jugador se le permite atravesar el rectángulo, y el mapa le "seguirá".Eso da tiempo para preparar la nueva pantalla.
Digo "preparar", porque la pantalla nueva debería hacerse con un doble buffer (una pantalla escondida, donde se dibuja mientras se muestra la primera).Sin embargo, en el c64 no se puede hacer doble bufer de la memoria de color.Sin embargo, sí que se podría calcular qué colores hay que pintar en cada posición, y almacenarlo en un buffer de 1k, para que cuando haya que refrescar el mapa de color, sólo haya que copiar el buffer, y no hacer todos los cálculos.
También sería posible hacerlo vía interrupciones: teóricamente, una vez que el raster ha pasado las primeras 8 lineas visibles, ya se puede empezar a pintar, fila a fila, los caracteres.Como pintando vamos a ser más lentos que el raster, no lo vamos a alcanzar.Por seguridad, los sprites sí que habría que actualizarlos cuando el raster esté completamente fuera de la pantalla.
También debería haber una seríe de caracteres especificos que se van a ir actualizando cada x frames, para hacer animaciones, etc
Algun comentario / idea / link de info ?