Ya esta disponible la versión v20 de la libreria 8BP, totalmente retrocompatible
He actualizado el repositorio de github https://github.com/jjaranda13/8BP con los siguientes cambios (coherentes entre la documentación y la librería). Con estas mejoras los juegos arcade ahora funcionan aun más rapido. Se incluye la demo de annunaki donde podéis comprobar el uso de estas mejoras.
Las mejoras son:
- posibilidad de definir la sensibilidad de la colisión entre sprites
- nuevo comando COLSPALL que acelera la detección de colisión
Posibilidad de definir la sensibilidad de la colisión entre sprites
COLSP : ahora puedes definir la sensibilidad de la colision (grado de solape entre sprites)
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.
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 mas anchos que altos, es quizás mas 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 colision 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 si 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
Nuevo comando COLSPALL que acelera la colisión entre sprites y simplifica tu programa BASIC
Con la funcion 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 4 invocaciones resulta costoso. Para ello disponemos de un comando adicional: COLSPALL
Esta funcion funciona en dos pasos, primero debemos especificar que variables van a almacenar el sprite colisionador y el colisionado
|COLSPALL, @colisionador%, @colisionado%
Y posteriormente, en cada ciclo de juego simplemente invocamos la funcion sin parámetros:
|COLSPALL
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 colision (bit 1) del byte de estado. Los sprites colisionadores deberán ser nuestra nave y nuestros disparos
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. 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 solo 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 en 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.
Espero que os gusten estas mejoras. Yo voy a intentar centrarme en avanzar en el videojuego "Annunaki",el cual hace uso de estas mejoras por ser un arcade espacial. En cuanto lo tenga listo lo compartiré con todos vosotros
No hay comentarios:
Publicar un comentario