8BP: Ajustar la sensibilidad de la colisión de sprites

Hola amigos de 8 Bits de Poder. En la entrega semanal del curso 8BP os traemos un pequeño tutorial sobre el ajuste sensibilidad colisión sprites con la librería 8BP.

Pero espera… ¿Es posible que no sepas nada de 8 Bits de Poder? Puedes leer el primer artículo del curso de programación en Amstrad CPC de 8BP.

Es posible ajustar la sensibilidad del comando COLSP, decidiendo si el solape entre sprites debe ser de varios pixels o de uno solo, para considerar que ha habido colisión.

Para ello se puede configurar el número de pixels (pixels en dirección Y, bytes en dirección X) de solape necesario tanto en la dirección Y como en la dirección X, usando el comando COLSP y especificando el sprite 34 (que no existe)

|COLSP, 34, <dy>, <dx>

La librería 8BP no usa “pixels” en la coordenada X, sino bytes, de modo que debes tener en cuenta que una colisión de 1 byte, en realidad son 2 pixels y esa es la mínima colisión posible cuando ajustas dx=0.

En la coordenada Y, la librería trabaja con líneas de modo que dy=0 significa una colisión de un solo pixel.

Ajuste sensibilidad colisión sprites

Una colisión estricta, útil para disparos sería aquella que no tolera ningún margen, considerando colisión en cuanto hay un mínimo solape entre sprites (1 pixel en dirección Y o un byte en dirección X)

|COLSP, 34, 0, 0: rem colision en cuanto hay un mínimo solape

Sin embargo, si estamos haciendo un juego en MODE 0, donde los pixels son más anchos que altos, es quizás más adecuado dar algo de margen en Y y nada en X. Por ejemplo:

|COLSP, 34, 2, 0 : rem colision con 3 pix en Y y 1 byte en X

Mi recomendación es que, si hay disparos estrechos o pequeños, ajustes la colisión con (dy=1, dx=0) mientras que si solo hay personajes grandes puedes dejarla con mas margen (dy=2, dx=1). También debes considerar que, si tus sprites tienen un “margen” de borrado alrededor para desplazarse borrándose a sí mismos, dicho margen no debería formar parte de la consideración de colisión por lo que tiene sentido que tanto dy como dx no sean cero. En cualquier caso, es algo que decidirás en función del tipo de juego que hagas.

¿Que colisiona y con quien? COLSPALL

Con la función COLSP que hemos visto hasta ahora, es posible la detección de colisión de un sprite con todos los demás. Sin embargo, si tenemos un disparo múltiple, donde por ejemplo nuestra nave puede disparar hasta 3 disparos simultáneamente, tendríamos que detectar la colisión de cada uno de ellos y adicionalmente la de nuestra nave, resultando en 4 invocaciones a COLSP.

Debemos tener presente que cada invocación atraviesa la capa de análisis sintáctico, por lo que cuatro invocaciones resultan costosas. Para ello disponemos de un comando muy potente: |COLSPALL.

Esta función funciona en dos pasos: primero debemos especificar que variables van a almacenar el sprite colisionador y el colisionado. La siguiente instrucción la ejecutaremos una sola vez, y sirve para definir las variables sobre las obtendremos los resultados, las cuales deben existir previamente:

|COLSPALL, @colisionador%, @colisionado%

Y posteriormente, en cada ciclo de juego simplemente invocamos la función |COLSPALL sin parámetros.

La función va a considerar como sprites “colisionadores” aquellos que tengan el flag de colisionador a “1” en el byte de estado (es el bit 5), y como “colisionados” aquellos sprites que tengan a “1” el flag de colisión (bit 1) del byte de estado. Los sprites colisionadores deberán ser nuestra nave y nuestros disparos y los colisionados todos aquellos con los que nos podamos chocar: naves y disparos enemigos, montañas, etc. Como anteriormente dije, un sprite no debe tener ambos bits activos (=1) a la vez.

La función |COLSPALL empieza comprobando el sprite 31 (si es colisionador) y va descendiendo hasta el sprite 0, invocando internamente a |COLSP para cada sprite colisionador.  Para cada colisionador, los sprites colisionables también se recorren en orden decreciente (desde 31 hasta 0). En cuanto detecta una colisión, interrumpe su ejecución y retorna el valor del colisionador y el colisionado. Por ello es importante que nuestra nave tenga un sprite superior a nuestros disparos. De ese modo, si nos alcanzan lo detectaremos, aunque hayamos alcanzado a un enemigo con un disparo en el mismo instante.

En cada ciclo de juego sólo se podrá detectar una colisión, pero es suficiente. No es una limitación importante que en cada fotograma solo pueda empezar a “explotar” un enemigo. Si, por ejemplo, tiras una granada y hay un grupo de 5 soldados afectados, cada soldado comenzará a morir en un fotograma distinto, y al cabo de 5 fotogramas estarán todos explotando. Usando |COLSPALL no explotarán todos a la vez, pero tu juego será más rápido y en un arcade es algo muy importante.

En caso de invocar a COLSPALL con un único parámetro,

|COLSPALL, <colisionador inicial>

Se explorarán los colisionadores desde el colisionador indicado hasta el sprite cero, en orden descendente. De este modo si necesitas detectar mas de una colision por ciclo de juego, podras hacerlo invocando sucesivamente a COLSPALL hasta que la variable colisionador tome el valor 32 IMPORTANTE: al igual que ocurre con COLSP, no se detectan colisiones con sprites que tengan alguna de sus dos coordenadas negativas con sprites que las tengan positivas.

¿Qué tal vas avanzando con tu juego en 8BP?

En el articulo de la semana que viene hablaremos sobre como programar un disparo multiple usando COLSPALL.

Hasta aquí hemos llegado por hoy con el curso de programación en Amstrad CPC de 8 bits de poder Si tienes alguna duda puedes escribir en comentarios y te contestaré lo antes posible.

Todos los recursos, como manuales, ejemplos y juegos compilados de este curso los puedes encontrar en el repositorio Github de 8BP.

Hasta la semana que viene amigos 😄