La pantalla inicial / final nos ha salido un poco sosa. Tiene un título (“ASTEROIDS”), el autor del juego, la puntuación y el record (sólo si venimos de terminar una partida), y la petición de pulsar espacio para jugar. Todo ello con caracteres estándar.
Para hacer esta pantalla un poco más atractiva tenemos varias opciones:
- Usar caracteres personalizados.
- Incluir algún sprite, parado o moviéndose.
- Incluir un bitmap.
Las opciones anteriores no son excluyentes, se pueden combinar.
Recordemos que los bitmap pueden ser estándar (también llamados hi-res) o multicolor. Como en el caso de los sprites o los caracteres multicolor, los bitmap multicolor tienen la mitad de resolución horizontal (200 x 160 pixels frente a los 200 x 320 de los bitmap estándar) a cambio de tener más color.
Para incluir un bitmap, habría que hacer todo esto:
- Diseñar el bitmap o convertirlo desde un gráfico de PC (JPG, PNG, …). Una herramienta interesante para hacer esto es Multipaint 2019 (ver http://multipaint.kameli.net/). Hay versiones para PC, Linux y Mac. Soporta los modos bitmap estándar y multicolor.
- Generar un fichero con la información gráfica. Este fichero ocupará 200 x 320 = 64.000 bits = 8.000 bytes para los pixels activos / inactivos, más otros 1.000 bytes para la información del color a ubicar en la RAM de pantalla. Adicionalmente, si el bitmap fuera multicolor, harían falta otros 1.000 bytes de color a ubicar en la RAM de color.
- Importar la información gráfica en un programa en ensamblador. Se puede utilizar la directiva “incbin” del CBM prg Studio, igual que hemos hecho con los sprites, los caracteres personalizados, o las pantallas.
- Configurar el VIC para localizar el bitmap en memoria (bit 3 del registro VMCSB = $d018) y para activar el modo bitmap (activar el bit 5 del registro SCROLY = $d011). Además, si se quiere el modo bitmap multicolor, hará falta activar el bit 4 del registro SCROLX = $d016.
Como se puede observar, los bitmaps ocupan mucha memoria (9K ó 10K) y son complejos de manejar. Pero pueden llegar a ser muy vistosos.
Por todo ello, y en aras de la simplicidad, en nuestro caso sólo hemos añadido algunos sprites / asteroides a la pantalla inicial / final. Concretamente estos tres:
Esto es fácil de conseguir. Llega con incluir en la rutina que inicializa esa pantalla, la rutina “inicializaPantallaMenu”, una llamada con “jsr” a la nueva rutina “pinta3Asteroides”:
Esta nueva rutina:
- Configura el multicolor. Esto pasamos a configurarlo aquí, y dejamos de hacerlo en “incializaJugador”, porque “pinta3Asteroides” pasa a ser la primera rutina relativa a sprites que se ejecuta en el programa.
- Para cada uno de los tres sprites / asteroides que pintamos, lo posiciona, hace la configuración básica (puntero, color y activación) y la configuración avanzada (multicolor, expansión y prioridad respecto al fondo).
Una curiosidad es que los tres asteroides deben ubicarse de modo que no toquen ninguna letra. Si lo hacen, al empezar el juego con la tecla espacio, el programa detecta la colisión inmediatamente y anima una explosión. Esto no es más que un ejemplo de los muchos problemas inesperados que uno se encuentra al hacer un juego.
Adicionalmente, ahora se vuelve necesario desactivar todos los sprites antes de inicializar la pantalla de juego, el jugador y los asteroides. Si no lo hacemos así, los tres sprites de la pantalla inicial aparecen activos al empezar el juego:
Igualmente, antes de pintar la pantalla inicial / final interesa desactivar todos los sprites porque, caso de no hacerlo, los sprites activos del final de la partida aparecerían en esa pantalla:
En definitiva, dado que ahora el juego puede constar de muchas partidas, no podemos dar por hecho que la pantalla inicial / final se pintará partiendo de una situación sin sprites activos, salvo que expresamente los desactivemos.
Todo esto podéis verlo en la versión 21 del proyecto. En las próximas entradas ya nos dedicaremos al sonido.
Código del proyecto: Asteroids21
Programación Retro del Commodore 64 
Esto va cogiendo forma!
Es curioso el detalle que en la versión 21 aún puedes colisionar con las explosiones. Por lo que no puedes atravesar un asteroide explotando. Como estés muy cerca… una vida menos!
Lo de los sprites en la pantalla de presentación, no se podría haber realizado mediante Chars? Tener unos Chars con el dibujo de los asteroides, como total, permanecen inmóviles, a no ser que esté planeado que se animen en una futura versión.
Muy interesante el desarrollo!
Saludos,
Jeff
Me gustaMe gusta
Hola, Jeff.
Muchas gracias por tus comentarios.
Efectivamente, si la nave colisiona con un asteroide, aunque éste esté explotando, la colisión se detecta y se trata igual que si no estuviera explotando. Es decir, en ambos casos, la nave explota.
Esta circunstancia también la detecté yo durante las pruebas, y me planteé si cambiarlo. En el fondo es un poco cuestión de criterio: si atraviesas una explosión es fácil que tú también explotes por la onda expansiva 🙂
En teoría, no debería ser complicado cambiarlo. En la rutina en que se detecta la colisión de la nave con un asteroide («actualizaColisionesJugador»), se podría tener en cuenta la situación en que está el asteroide, activo o explotando, y si está explotando no considerar la colisión.
Ahora bien, la cosa tiene más miga de lo que parece. En la rutina ahora mismo detectamos que hay una colisión sprite – sprite, y que en ella interviene la nave («and #%00000001»). Pero lo que no está muy claro es con qué asteroide ha chocado la nave. Podríamos saberlo usando los bits activos del registro SPSPCL pero… ¿qué pasaría si un asteriode estuviera en contacto con otro asteroide? ¡También se activarían sus bits respectivos en SPSPCL!
Total, la única forma de individualizar con qué asteroide ha chocado la nave sería teniendo en cuenta las posiciones de ambos. Y una vez localizado el asteroide con el que ha colisionado la nave, tener en cuenta su estado, activo o explotando.
Respecto a la pantalla inicial / final, sí, los sprites se podrían haber sustituido por caracteres personalizados. Ahora bien, si quieres que los asteroides queden intercalados con el texto / título, puesto que el título y los asteroides serían ambos caracteres, el intercalado podría ser un poco más difícil de conseguir. Con sprites, como se pueden mover y situar pixel a pixel, este intercalado resulta más fácil de conseguir. Incluso se podrían llegar a solapar con el título, aunque ya hemos comentado que eso da problemas (explota el asteroide al empezar el juego 🙂 ).
Se pueden hacer muchas cosas chulas. Incluso se puede mezclar texto y bitmap. Para ello, llega con usar las interrupciones del RASTER, cambiando el modo de la pantalla a la altura de una línea X. ¡¡El C64 es sorprendente!!
¿Qué? ¿No te animas a desentrañar el reto de los asteroides crecientes? 😉
Un saludo cordial, HVSW.
Me gustaMe gusta