Asteroids: una pantalla inicial un poco más sofisticada

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:

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. 

Asteroids - Multipaint multicolor.PNG

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:

Asteroids - Pantalla con asteroides

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”:

Asteroids - Pinta 3 asteroides.PNG

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:

Asteroids - Desactivar sprites.PNG

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:

Asteroids - Desactivar sprites 2.PNG

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

2 comentarios en “Asteroids: una pantalla inicial un poco más sofisticada”

  1. 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 gusta

  2. 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 gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s