Programación del Amstrad CPC usando la libreria 8BP ("8 bits de poder") desde BASIC
"Las limitaciones no son un problema, sino una fuente de inspiración"
Jose Javier Garcia Aranda
If you like 8BP, your help is welcome. Help me supporting this initiative (from 1€, whatever you want). Donations will be used for materials and 8BP disemination:
Ya tenéis disponible la versión V43 de la librería 8BP, descargable en github https://github.com/jjaranda13/8BP . Esta nueva versión incorpora varias funcionalidades nuevas y una nueva opción de ensamblaje. Además, en la opción de ensamblaje "cero" te da un poco mas de memoria libre.
Esta nueva versión supone una mejora y en parte es gracias a vosotros que me escribís con preguntas, dudas, ideas, etc.
las novedades son:
soporte de doble clipping horizontal: esta funcionalidad es interesante para implementar juegos con scroll estilo ghost n goblins. Estoy trabajando en ello para poder hacer una demostración.
nuevo flag y funcionalidad de borrado. Se activa con PRINTSP,33,1 y se desactiva con PRINTSP,33,0. Con el flag activo tanto PRINTSP como PRINTSPALL borran los sprites. Este mecanismo funciona también con sprites que tienen sobreescritura. Esta funcionalidad me la han pedido desarrolladores de juegos y se ha podido incorporar sin apenas gastar memoria.
nuevo modo de ensamblaje ASSEMBLING_OPTION = 4 que permite prescindir de layout y scroll, y que te deja 25300 bytes para tu codigo y 500 bytes mas para tus sprites
mas memoria disponible en el modo de ensamblaje cero. Antes eran 23500 y ahora son 23600 bytes
corregido bug en ANIMASP
dos nuevas demos: una de doble clipping y otra de flag de borrado
Estos son los 4 modos de ensamblaje disponibles en 8BP V43
El manual ha sido actualizado con todas estas cuestiones y ahora hay una versión del manual "V43". Las traducciones a otros idiomas se han quedado desactualizadas en "V42", pero es lo único que quedaría por actualizar.
Quiero dar las gracias en especial a "fito", por que me ha ayudado a estas mejoras con sus ideas
Espero que la disfrutéis y aprovecho para desearos un feliz verano!
Recientemente, hablando con un amigo desarrollador de AMSTRAD, "fito", conocido programador de juegos como "space panic", "barr war" o "spaceman kerl" (https://fitosoft.itch.io/), surgió la necesidad de hacer mapas del mundo dinámicos.
No os preocupéis que esto no va de música setentera. Como sabéis, 8BP tiene capacidad de scroll mediante un mecanismo llamado "mapa del mundo", el cual es una lista de "items" compuestos por coordenadas y dirección de imagen. De este modo podemos construir un mundo que después recorremos con el comando MAP2SP, el cual convierte a sprites aquellos items que "caen" dentro de la pantalla.
Pues bien, es posible pokear las direcciones de memoria del mapa usando identificadores de imagen en lugar de direcciones de memoria. En 8BP podéis dar de alta en una lista llamada "IMAGE_LIST" las imágenes que queráis, de modo que a cada imagen le corresponde un numerito pequeño en lugar de una dirección de memoria. Por ejemplo, podríamos decir que una casa es el ID=23 en lugar de decir que se encuentra en la dirección &8D41.
Al pokear el mapa podéis crear mapas dinámicamente, antes de comenzar una fase de modo que podríais inventar una forma de guardar mapas enormes de un modo mas compacto. O simplemente crear laberintos aleatorios. La imaginación manda.
El caso es que esto ya era posible en 8BP y de hecho se usa en el juego "3D racing one" pero recientemente descubrimos que usar identificadores de imágenes hacia fallar el comando de colisión (lo cual no ocurre en "3d racing one" porque usa otro mecanismo de colisión). Pues bien, esto ha sido corregido y además se ha acelerado un poquitín el comando de colisión. La nueva versión corregida es 8BPV42_001 (https://github.com/jjaranda13/8BP) y también se han añadido estas cuestiones en el manual, Asi como una idea (truco) para lograr imágenes animadas en tu mapa, tales como un volcán en erupción, una cascada de agua o lo que se te ocurra, Espero que os guste y os sea útil en vuestros juegos
En esta ocasión os traigo un pequeño truco motivado por un desarrollador que quería cambiar la dirección de salto de un personaje en mitad de una ruta
Supongamos que quieres que tu personaje salte hacia la
derecha y en mitad del sato quieres que el personaje pueda cambiar hacia la
izquierda, continuando el salto. Lo que estamos planteando se puede representar
con este dibujo:
En este ejemplo nuestro personaje salta y en mitad de la ruta
de salto hacia la derecha, cambia de dirección en el punto 2, continuando con
la ruta de salto a la izquierda, pero sin comenzar un nuevo salto, simplemente
continuando el salto y alcanzando la misma altura (punto 3) que alcanzaría con
el salto hacia la derecha para finalmente terminar el salto a la izquierda en
el punto 4.
Para poder hacer esto necesitamos cambiar la ruta a nuestro
personaje desde basic en el punto 2, pero no podemos usar el comando SETUPSP
porque ello iniciaría la ruta, obteniendo un salto mucho mayor, que comenzaría en
el punto 2. Lo que podemos hacer en ese caso es simplemente un POKE a la dirección
de memoria que almacena la ruta del Sprite, que es la dirección de su estado +15,
tal como muestra la tabla de atributos de sprites.
Suponiendo que tenemos dos rutas de salto (ruta 0 salto a derecha y ruta
1 salto a izquierda), el siguiente ejemplo ilustra el concepto (puedes cargar las demos de 8BP y modificar estas líneas en la demo 2 para ver el efecto
130 'ciclo
de juego ------
150 |AUTOALL,1:|PRINTSPALL,0,1,0
170 '
rutina movimiento personaje -----
173 IF PEEK(27000)<128 THEN 178
174 'estamos
en mitad de un salto
175 IF INKEY(27)=0 THEN POKE
27015,0:GOTO 180:'cambio ruta a derecha
176 IF INKEY(34)=0 THEN POKE
27015,1:GOTO 180:'cambio ruta a izq
177 GOTO 193
178 IF INKEY(67)=0 THEN
|SETUPSP,0,0,137:|SETUPSP,0,15,dir:'saltar
180 IF INKEY(27)=0 THEN
dir=0:|SETUPSP,0,6,1:'ir derecha
190 IF INKEY(34)=0 THEN
dir=1:|SETUPSP,0,6,-1:'ir izquierda
193 ciclo=ciclo+1
310 GOTO 150
La única limitación del uso de POKE para este propósito es
que la imagen del personaje no cambia hasta que no encuentra un código de cambio
de imagen en mitad de la ruta. Cambiar la imagen usando SETUPSP es posible pero
peligroso, ya que no sabes si el personaje esta subiendo (borrado con líneas inferiores)
o bajando (borrado con líneas superiores). Por ello es mejor simplemente
asignar la ruta y que la propia ruta cambie la imagen lo antes posible. Puedes
incluso poner en mitad de la ruta cambios de imagen aimque no sean necesarios por
si ocurre esta circunstancia. Lo que si tienes que hacer es que la imagen de salto
tenga bytes de borrado en ambos lados pues si no lo tiene y cambia de
dirección, dejaría un rastro.
He añadido este briconsejo en el manual de 8BP (apartado 12.2.5 del manual) , y en mi próximo post además os hablaré de un fabuloso juego que acaba de salir para 8BP y que podréis encontrar en el respositorio github de 8BP
Ya podéis disfrutar de NOMWARS, el último videojuego de 8BP
El juego ha sido editado en formato DES (Dandanator Entertaiment System), un formato que le permite dar nueva vida a tu AMSTRAD CPC con cartuchos, cargándo instantáneamente, con la posibilidad de crear tus propias compilaciones de juegos. El juego esta a la venta en https://hobbyretro.com/retro/nom-wars
NOMWARS es un juego creado en honor al clásico "Commando" creado por Capcom en 1985.La versión programada con 8BP ha sido titulada “NOMWARS”, por estar de moda las historias sobre el nuevo orden mundial como amenaza. El título es lo de menos porque igual se podría haber titulado “el retorno de joe” o “supercommando”, no deja de ser un clon de comando
NOMWARS ha sido programado en BASIC
con 8BP, demostrando una vez más que con 8BP puedes hacer cualquier tipo de
juego.
En esta versión se explota la capacidad de scroll de 8BP
(comando MAP2SP) y se incluye el famoso puente por el que Joe pasa por debajo usando
una técnica basada en el comando SETLIMITS de 8BP.
EL juego se ofrece en dos versiones: la versión de BASIC
pura y la versión de ciclo compilado (ciclo traducido a lenguaje C usando el
wrapper de 8BP y el minibasic de 8BP).
Ambas versiones son idénticas, pues la traducción a C es una réplica
total, casi un espejo de la versión BASIC. De hecho, el juego ha sido programado
en BASIC y el ultimo día ha sido pasado a C con la facilidad que tiene para
ello 8BP.
Historia de NOMWARS
Siglo XXI, el Nuevo Orden
Mundial ha creado una pandemia y se ha hecho con el control de los medios, ha
arruinado la economía y está utilizando técnicas de ingeniería social para que
la población acepte un régimen totalitario basado en la tecnología. Mediante un
plan de vacunación masiva están esterilizando silenciosamente a la población.
Cualquier fiesta está prohibida.
Quedan pocos pensadores
libres como tú, y tu misión es unirte a una fiesta clandestina, para lo cual
deberás destruir al ejército del nuevo orden mundial. Una vez destruido, la
humanidad te agradecerá haber roto sus cadenas
Hay gente a la que le ha “alertado” la historia de NOMWARS, porque contradice lo que se dice en los medios de comunicación sobre el NOM, pero una vez más quiero dejar claro que NOMWARS es un videojuego, no es un libro de actualidad geopolítica ni de historia. Es un simple juego y como tal es una ficción.
La programación del videojuego esta explicada paso a paso en el documento "making of" que encontraras en la sección de documentacion de github , en https://github.com/jjaranda13/8BP
En el documento "making of" encontraras el mecanismo para construir los mapas de cada fase, el scroll, el mecanismo usado para lograr que nuestro personaje pase por debajo del puente, la programación del disparo tan rápido que tiene, el movimiento del personaje, etc
Vamos a explicar aquí el mecanismo del puente, que es sencillo de entender y a la vez interesante:
En estas dos imágenes se ilustra: tras imprimir todos los sprites, se hace un SETLIMITS para restringir el área de impresión de la pantalla y se imprime el personaje. El mecanismo de “clipping” de la impresión de sprites hace que Joe desaparezca justo al entrar en el puente. Justo después de imprimir a Joe se deja el SETLIMITS como estaba para poder usar todo el área de juego al imprimir sprites en el siguiente ciclo de juego
Con 8BP puedes lograr crear juegos de todo tipo y como ves los resultados pueden ser muy profesionales. Espero que disfrutéis de este juego y que os animéis a programar vuestros propios juegos con 8BP!!
ya tenéis disponible la versión V39 de la libreria 8BP, descargable en github https://github.com/jjaranda13/8BP . Esta nueva versión incorpora las siguientes mejoras:
librería: ahora se incluye 8bitsdepoder_v39_001.asm con las siguientes mejoras:
comando |COLSPALL, id : ahora explora a partir del colisionador id+1. Esto tiene mas sentido que buscar desde el sprite id, ya que este comando se usa para detectar nuevas colisiones a las ya detectadas con COLSPALL, y lo logico es que usemos el id del colisionador detectado, de modo que nos interesa explorar a partir de id+1
comando |MUSIC: ahora acepta un nuevo parámetro que permite dejar libre el canal C de sonido mientras suena la musica para usarlo en efectos sonoros con comando SOUND de BASIC
comando PRINTSPALL : ahora primero imprime y luego anima, de modo que el primer fotograma de una explosión se imprimirá. Hasta ahora cuando se asignaba una secuencia de animación, el primer fotograma no se imprimía porque primero animaba y luego imprimía
ahora los comandos PRINTSP y PRINTSPALL pueden usar imágenes ubicadas en cualquier zona de memoria, incluso fuera del espacio destinado por la librería 8BP para sprites. Esto antiguamente funcionaba pero desde que introduje las imágenes flipeadas, un pequeño error hizo que esta posibilidad quedase anulada, pero ya funciona de nuevo.
corregido un minibug detectado en un caso concreto de sobreescritura
manual: he actualizado el manual reflejando los cambios en la libreria
Demos: todas las demos se recopilan en un menú y están hechas con la v39. ahora hay una demo nueva para probar música y FX a la vez
Con esta nueva versión de la librería he programado el nuevo juego "blaster pilot" que pronto veréis y podreis jugar en la próxima feria en la que participaré ( retroparla) . Aun no ha sido publicado.
Es un juego de acción, con scroll multidireccional, musica on-game (compuesta por bitcaffe), sonidos FX a la vez que la música, muchos enemigos animados y 6 niveles. Pronto publicaré un video de este juego para que veáis como ha quedado. Como siempre, el videojuego será gratis y para todos (tanto el .dsk como los fuentes los tendréis a vuestra disposición)
Por cierto, este juego "busca" sponsor: si quieres que el logo de tu empresa o asociación aparezca en este nuevo juego para siempre, contacta conmigo a través de twitter (@8bitsdepoder )
Por último, a los que deseáis programar con 8BP en C, os diré que el wrapper de C ( un 8bp.h) lo tengo a medias y funciona perfectamente, de modo que podréis disfrutar de esta capacidad en la próxima versión V40
Como muchos ya sabreis, Happy monty esta disponible para descarga en https://github.com/jjaranda13/8BP asi como el documento "making of", (en la carpeta de documentación). Os recomiendo que os bajeis el juego de mi URL y no de la que publica byterealms porque he retocado algún detalle tras el concurso y la versión que he publicado yo es "la buena".
uno de los 25 niveles
Nada mas empezar a cargar veréis los logos de la AUA (https://auamstrad.es ) y de 8BP. Eso es porque tenemos una relación de cooperación para fomentar los valores de la cultura retro y promover las creaciones con AMSTRAD, para mantener mas viva la escena, si cabe. Haremos muchas cosas juntos, y las vais a poder disfrutar. Soy aliado de la buena gente que quiere contribuir a dar vida a la escena y a compartir conocimientos y desarrollos. Los amigos de la AUA son de esta pasta.
pantalla de carga
El motivo de haber presentado este videojuego a la CPC retrodev 2019 fue para dar a conocer 8BP a aquellos desarrolladores que aun se están pensando si hacer un juego o una demo con su CPC y dudan si sus conocimientos de BASIC serán suficientes. La respuesta es SI. con tener el emulador winape y sin instalar nada, puedes programar en BASIC sobre el CPC y beneficiarte de la gran potencia de 8BP. Evidentemente no he logrado el impacto que deseaba con la CPCRetrodev porque el juego no ha quedado de los primeros, pero al menos he logrado algo de difusión de esta herramienta 8BP.
No voy a quejarme del puesto (ha quedado el 11) porque cualquier cosa que diga se puede malinterpretar y precisamente yo reconozco el valor de los 35 juegos, porque al ser programador, entiendo como están hechos y al igual que una persona en un museo puede entender mejor un cuadro del Bosco si conoce sus motivaciones y lo que representa, un programador entiende perfectamente lo que esta viendo y lo analiza técnicamente muy deprisa, haciéndose una idea muy clara del esfuerzo que supone cada aspecto del juego. Es como tener la capacidad de ver "mas allá" de tu percepción visual porque "entiendes" lo que estás viendo.
Lo que si que considero y me atrevo a decir es que una mejor posición para 8BP (= para Happy Monty) habría beneficiado a la escena CPC porque habría "democratizado" aun más la programación en 8 bits, con un mensaje claro a programadores BASIC: si sabes BASIC puedes hacer un juego como Happy Monty. A pesar de todo, algo de difusión he logrado y más de uno se animará a desarrollar sus juegos o demos gracias a Happy Monty. Desde este humilde blog os animo a probarlo!
uno de los 25 niveles
uno de los 25 niveles
Voy a dar algunas pinceladas en este post sobre como ha sido construido este juego y cuales son las claves que lo hacen ser una sorprendente creación. Los puntos clave son:
El juego esta íntegramente hecho en BASIC y funciona en BASIC sin compilar. Eso si, usa los comandos extendidos que proporciona la librería 8 bits de poder (8BP).
El juego se mide a si mismo e imprime los FPS que esta alcanzando en la parte inferior de la pantalla. Es un dato de "honestidad", para que en todo momento puedas analizar la velocidad del juego y juzgues lo que le cuesta mas y lo que le cuesta menos, sin trampa ni cartón.
EL juego es un tributo a Mutant Monty, un juego de 1984 escrito en ensamblador y logra alcanzar su misma velocidad (a veces supera 25 FPS) y hasta posee lógicas mas complejas de enemigos que en el juego original. Esto significa que en BASIC se puede lograr el resultado de un juego programado en ensamblador haciendo uso de 8BP y la técnica de lógicas masivas. Si, has leído bien, se puede hacer.
El juego tiene la primera pantalla idéntica a la del juego original. El motivo es muy sencillo: primero porque es un tributo o "segunda parte" (no un plagio ni un clon como ha afirmado algún despistado) y segundo porque quiero que lo compares: un juego en BASIC vs un juego en ensamblador y decidas por ti mismo si 8BP tiene la potencia de un pura sangre o no. Juega a ambos y alucina viendo lo que desde BASIC se puede lograr
EL juego Mutant monty original
El primer nivel de Happy Monty
Monty tiene dos velocidades: si pulsas una tecla , monty camina, pero si la dejas pulsada...monty corre. Este mecanismo también estaba presente en el juego original. Estas mecánicas tienen también su peso en BASIC y como siempre afirmo: "todo cuesta, incluso un simple IF"
EL lenguaje BASIC interpretado es extraordinariamente lento...¿entonces? ¿como se logra la vertiginosa velocidad de Happy Monty? (calificada hasta de excesiva -lo cual es un halago- por algún miembro del jurado de la cpcretrodev) ¿de donde procede su "magia"? pues de dos cosas: de la velocidad de los comandos 8BP ( capaces de mover 32 sprites a la vez a 18 FPS o más) y de la ya popular técnica de "lógicas masivas" de la que hablo ampliamente en el manual de 8BP, así como en muchas de las charlas de programación que he dado y que encontrareis en youtube y en la carpeta de documentación
Algunas claves del juego:
Niveles definidos de forma compacta:
cada nivel se ha creado con 160 caracteres que definen tanto los muros de cada nivel como los enemigos presentes, asi como las trayectorias que deben seguir. tambien en esos 160 caracteres se indica donde se encuentran las piezas de oro, la puerta y la posicion inicial de Monty
Para no definir cientos de rutas de sprites de diferentes longitudes, se han creado sprites inversores invisibles. Cuando un enemigo choca contra un sprite inversor , cambia de dirección. En el mapa expuesto son las letras "z" ,"x" para rutas horizontales y "q", "w" para verticales.
los niveles se dibujan en pantalla leyendo desde Basic 160 caracteres almacenados en memoria y "traduciendo" a muros y enemigos que se van pintando. Es por ello que tarda unos segundos en pintarse cada nivel (casi nada). Podría haber hecho una rutina ASM para ello pero he preferido dejarlo así con fines didácticos. Se ha llegado a decir de monty que tiene un problema porque parece que se pinta el nivel como si estuviese hecho en BASIC....pues claro, es que esta hecho en BASIC!!!!
Lógicas masivas:
cuando un enemigo choca con un inversor este se desactiva, por lo que ya no hay que detectar colisiones con el, hasta que el enemigo choca con el inversor opuesto. en ese momento se vuelve a activar. Esto reduce muchos calculos pues puede haber hasta 12 inversores en pantalla.
el teclado se lee en dos etapas: en los ciclos impares de juego se le OP y en los ciclos pares se lee QA, de modo que hay menos trabajo que hacer en cada ciclo. La velocidad del juego evita que el jugador pueda apreciar esta limitación "invisible"
las comprobaciones sobre si monty puede cambiar de dirección solo se hacen cuando monty se encuentra en X= múltiplo de 4 o Y= múltiplo de 16. Esto reduce muchos cálculos por ciclo de juego. Solo se atiende inmediatamente el cambio de dirección si se trata de ir en la dirección opuesta a la que se encuentra en ese momento. En ese caso Monty da la vuelta inmediatamente.
los enemigos que se mueven mas despacio, tan sólo se imprimen cada dos ciclos gracias a la capacidad de cambio de estado de las rutas 8BP. Esto ahorra tiempo a la rutina de impresión
la detección de colisión con las piezas de oro se hace cada 6 ciclos, al igual que la colisión con la puerta y la detección de pulsación de la tecla M para activar y desactivar la música. Esto ahorra operaciones por ciclo y es imposible que pases por encima de un oro y no lo cojas pues para atravesar completamente un oro hacen falta al menos 8 ciclos.
Gráficos y música
todos los gráficos, secuencias de animación, decorados, etc los he hecho con la herramienta SPEDIT que viene con 8BP. Es muy sencilla y esta escrita en BASIC, la puedes usar desde winape. En cuanto a la música la he hecho con el WYZtracker. El WYZplayer esta integrado dentro de la librería 8BP y para hacer sonar la música on-game basta con invocar el comando MUSIC de 8BP.
Hay mas cosas y detalles que podria contar pero para este post creo que es suficiente. No quiero "saturar" con demasiados detalles. He hablado algo sobre como están hechas "las tripas" del juego para que os hagáis una idea y me alegro de haber compartido este juego con todos vosotros.
Antes de despedirme, quiero también contaros dos novedades muy próximas:
8BP v38 con algunas mejoras y un manual con "primeros pasos" mas fácil aun.
y un vídeo que voy a hacer de "primeros pasos" con 8BP, en el que veréis como en 10 minutos podéis hacer vuestro primer juego/demo usando 8BP, que tan solo requiere que tengáis instalado winape, nada mas.
Un abrazo y hasta pronto amigos! Os dejo con un video del juego
Ya esta disponible la versión v37 de 8BP, disponible para descarga en https://github.com/jjaranda13/8BP la cual incorpora las siguientes mejoras:
comando |COLAY mas rápido y con un cambio en su paso de parámetros. ahora acepta 3,2,1 o ningún parámetro y el nuevo orden de los parámetros es |COLAY umbral,@col,sp . En caso de no usarse ningún parámetro, el comando tiene memoria y usa los de la ultima invocación. Esto permite un incremento notable de velocidad, pasando de 3.5 ms a 2.5 ms
se han acelerado unos cuantos comandos, (MOVER, MOVERALL y otros). Para ello se han modificado algunas partes de código ensamblador comunes a varios comandos
comando |COLSPALL mas potente. ahora puede ser invocado con un parámetro para especificar el colisionador inicial. Esto permite detectar varias colisiones por fotograma si es necesario. luego veremos como.
comando |ANIMALL ya solo se puede invocar mediante un parámetro en PRINTSPALL o mediante CALL pues se ha sacado de la lista para ganar algunos bytes de memoria. El comando normalmente solo se usa desde PRINTSPALL, de modo que no supone ningún problema
manual: he actualizado el manual reflejando los cambios en la librería y he incluido un apéndice con la correspondencia entre cada comando y su equivalente CALL. Además, el manual ha sido revisado y mejorado al completo, en especial el capítulo de lógicas masivas
La velocidad en general ha aumentado un poco en todos los comandos, los cuales unidos a la técnica de lógicas masivas nos permite hacer juegos en BASIC como el nuevo "Happy Monty". Es un juego aun en construcción que reproduce fielmente el funcionamiento del mítico mutant monty. Alcanza los 25 FPS y permite activar y desactivar la musica on-game. El juego es muy rápido y se mide a si mismo, mostrando los FPS alcanzados dentro de los marcadores del juego.
Las colisiones funcionan como siempre (mecanismo de logicas masivas dentro del comando COLSPALL) pero se puede invocar usando como parametro el colisionador de la ultima colisión detectada y si se ejecuta hasta que no haya colisiones, puedes detectar todas las colisiones que sucedan en cada fotograma, aunque es algo que debe usarse solo si es necesario.
Lo que acabo de contar se puede expresar asi:
colisionador=31
while colisionador<32
COLSPALL, colisionador
if colisionador <32 then GOSUB RUTINA
wend
Aqui teneis un video donde podéis ver como esta quedando. Pondré una demo del juego en la feria de la RUN" AUA (Rivas, Sábado dia 19) para que puedas probarla.
Cada nivel se ha construido usando 160 caracteres, apenas lo que ocupa un mensaje de twitter. En 4KB se han metido 25 pantallas y en realidad aun caben mas. Puede que le llegue a hacer 40 niveles.
Aprovecho para deciros que estaré en la RUN"" AUA que tendrá lugar en Rivas el sabado 19 de Octubre (en una semana) y alli contaré como usar la libreria 8BP y diversos trucos de programación usados en space phantom, eridu, frogger, happy monty...
la RUN"" AUA se celebra en la "casa grande ", un espacio ofrecido por el ayuntamiento de Rivas-Vaciamadrid. Teneis mas informacion en https://auamstrad.es/runaua2019/
el fabuloso emplazamiento donde tendrá lugar la RUN"" AUA
Además podreis ver el DES (Dandanator Entertaiment System" https://auamstrad.es/des/) con el cartucho de 8BP en acción, incluyendo el juego "Eridu", "frogger", "space phantom"... todos!!!
Nos vemos en Rivas el sábado día 19, amigos. Hasta pronto!!
Como he anunciado por twitter, en la proxima feria de Amstrad Eterno, que tendra lugar el Sábado 30 de marzo en Barcelona. Es una gran feria, un punto de encuentro obligado para los amantes del Amtrad . En ella, 8BP tendra presencia con un stand en el que os mostraré novedades y juegos y donde podremos charlar sobre nuestro ordenador favorito.
Además, de 11:30 a 12:00 podreis aprender a programar el clasico "frogger" desarrollado por konami en 1981, pero usando 8BP. Os enseñare paso a paso como hacerlo y vereis lo facil que es programar cualquier juego con 8BP. Además, prepararé documentación detallada del juego para los asistentes, aparte de la conferencia/taller
Hablaré de las capacidades de 8BP y de la técnica de lógicas masivas pero a la vez podras comprobar como plasmar esos conceptos en un juego real, llamado "Frogger eterno", al que podrás jugar en el stand ese mismo dia. ¿te animas?
el juego frogger eterno será presentado en Amstrad Eterno 2019
Os dare mas noticias sobre esta contribución de 8BP a medida que nos acerquemos al evento. De momento os dire que tambien estarán disponibles gracias a STAR, ediciones físicas de los juegos de 8BP en dos volúmenes. Cada volumen contiene dos cintas cuidadosamente elaboradas. Las podeis adquirir en la boutique de STAR http://www.matranet.net/boutique/cpc/cpc.php
volumenes de 8BP
STAR realiza unas magnificas ediciones homebrew
En el stand podreis probar los juegos de 8BP, incluido el recientemente premiado "Space Phantom". Como sabeis es un juego de arcade 3D y si funciona rápido es gracias a la velocidad de los comandos 8BP y a la técnica de lógicas masivas de la que os contaré sus secretos. Alli estaré para el que quiera conocer los secretos de la programación de este juego.
Antes de despedirme quiero deciros que he subido una nueva versión del manual (V36_01), mejorada en algunos capitulos para explicar mejor como funciona todo, sobre todo el apartado de rutas de sprites, aunque hay mas mejoras.
Un abrazo y nos vemos en Amstrad Eterno 2019! no te lo pierdas!
Ya esta disponible la versión v36 de 8BP, disponible para descarga en https://github.com/jjaranda13/8BP la cual incorpora las siguientes mejoras:
Comando |PRINTSPALL mejorado, con nuevo parametro de ordenacion
Comando |PRINTSPALL con soporte de 4 modos de ordenamiento de sprites
Se han optimizado en velocidad un poquito la impresion flipeada y el comando STARS
la libreria no ha cambiado de tamaño, ocupa lo mismo
Con las mejoras de ordenamiento de sprites ya podemos hacer fielmente un juego tipo "Golden Axe" o incluso algo que se aproxima a un juego "filmation" ( ya he empezado a hacer uno, pronto lo vereis). Ahora os voy a detallar un poco las mejoras:
Comando |PRINTSPALL mejorado:
Ahora permite un parametro adicional para especificar el primer sprite que se va a ordenar del grupo de sprites ordenados, es decir ahora se usa del siguiente modo: |PRINTSPALL, ordenini,ordenfin,anima,sync
Donde ordenini es el primer sprite que se va a ordenar y ordenfin el ultimo. Veamos un ejemplo de uso:
|PRINTSPALL,0,11,20,anima,sync
imprimiremos secuencialmente los sprites del 0 al 10, ordenados del 11 al 20 y secuencialmente del 21 al 31
Si el parámetro “ordenini” se omite, se considera el último valor asignado, o bien cero si nunca se ha asignado un valor. Ademas, si vas a modificar alguno de los dos parámetros de ordenamiento, conviene primero ejecutar PRINTSPALL,0,0,0,0 para que primero se reordenen los sprites secuencialmente antes de ordenarlos con una nueva configuración.
Imprimir de forma ordenada es más costoso computacionalmente que imprimir de forma secuencial. Ordenar todos los sprites lleva unos 2.5 ms pero si ordenas solo 5 te puedes ahorrar 2ms. Quizás tengas muchos sprites y no merezca la pena ordenar algunos, como los disparos o sprites que sabes que no se van a solapar.
Soporte de 4 modos de ordenamiento:
Ahora se permiten 4 modos de ordenamiento de sprites, que se configuran usando PRINTSPALL con un solo parametro. En 8BP ordenacion "parcial" significa que en cada invocacion solo se corrigen 2 sprites desordenados: PRINTSPALL,0 : ordenacion parcial de sprites basado en Ymin PRINTSPALL,1 : ordenacion total de sprites basado en Ymin PRINTSPALL,2 : ordenacion parcial de sprites basado en Ymax PRINTSPALL,3 : ordenacion total de sprites basado en Ymax Los ordenamientos que usan Ymax se basan en la coordenada Y mayor de los sprites, es decir, donde se encuentran sus pies en lugar de su cabeza. Si los sprites son del mismo tamaño, un ordenamiento basado en Ymin te puede servir, pero si los sprites tienen diferente altura puede que desees ordenar según donde se encuentren los pies de cada personaje y para ello tendrás que usar el modo de ordenar 2 o el 3.
En el siguiente ejemplo se puede ver el modo de ordenacion 2 funcionando. En este ejemplo no he usado sobreescritura, sino tan solo ordenacion de sprites, pero se pueden usar ambas cosas a la vez sin ningun problema.
Los modos de ordenar con Ymax son mas lentos, aproximadamente 0.128 ms por sprite, de modo que úsalos cuando los necesites realmente
comando |ROUTESP mejorado, ahora permite adelantar varios pasos en la ruta para colocar facilmente naves en hilera
he incluido una nueva demo para demostrar ROUTESP
corregido un pequeño bug detectado en v34 en el uso conjunto del codigo 251 y |AUTOALL,1
no ha cambiado el espacio ocupado por la libreria
manual : En la documentacion he reflejado todos los cambios y he mejorado apendice de teclado, asi como el apartado de logicas masivas
JUEGOS: nuevo juego "SPACE PHANTOM" disponible en la carpeta GameExamples. Es un juego pseudo 3D creado con 8BP V35, ocupa unos 18KB de BASIC
Os voy a poner un ejemplo del comando ROUTESP
|ROUTESP, <spriteid>, <pasos>
Este comando mueve un sprite el numero de pasos que desees a lo largo de la ruta que tenga asignada. En el ejemplo he destacado en rojo la asignación de la ruta 8 y los comandos ROUTESP que posicionan cada uno de los sprites en la ruta
10 memory 23999
10 ON BREAK GOSUB 12
11 GOTO 20
12 |MUSICOFF:CALL &BC02:PAPER 0:PEN 1:MODE 1:END
20 CALL &BC02:DEFINT A-Z:MODE 0
50 CALL &6B78
70 ' todas las naves colocada en la misma coordenada inicial
75 ' y con la misma ruta pero con un numero inicial de pasos distinto
76 locate 2,3: Print "comando |ROUTESP "
80 for s=16 to 21: |SETUPSP,s,9,33: |SETUPSP,s,0,137: |SETUPSP,s,15,8:|LOCATESP,s,20,100:next
90 |ROUTESP,21,40:'nave cabeza
100 |ROUTESP,20,30
110 |ROUTESP,19,20
120 |ROUTESP,18,10
130 |ROUTESP,17,0
131 |PRINTSPALL,0,0,0
140 '--- ciclo de juego ---
150 |AUTOALL,1:|PRINTSPALL
160 goto 150
vamos a ver un ejemplo en accion en el siguiente video
https://www.youtube.com/watch?v=9Tk5ZE8lG-c
Ademas de esta nueva versión de la libreria, ahora se incluye el nuevo videojuego "SPACE PHANTOM", un tributo al clasico "Space Harrier" de SEGA, realizado en BASIC con 8BP. Es un juego con capacidades pseudo-3D, logicas masivas, enrutado de sprites avanzado, etc.
Equipado con un jet-pack, debes volar por el espacio y destruir meteoritos y pajaros diabolicos espaciales, despues entrarás en el ultramundo donde te enfrentarás a numerosas naves enemigas y por ultimo tendrás que enfrentarte a un dragon y conseguir su cabeza. Una aventura epica espacial en tu AMSTRAD.
Aunque aun no he liberado la v33, ya esta terminada y suficientemente probada. Solo me queda actualizar el manual, lo cual haré en los próximos días.
Os cuento sus características y lo que incorpora:
Ocupa exactamente lo mismo que la v32
En modo pseudo-3D, ahora tiene capacidad de imprimir segmentos con sobreescritura. Esto es algo que se podía hacer en v32 con todo tipo de sprites menos con los segmentos
Rotación de tintas (comando RINK) sin limitaciones. Hasta ahora se podían hacer patrones de 4 y 8 tintas rotando. Ahora puedes rotar cualquier numero de tintas
Sobreescritura de sprites con posibilidad de elegir el número de bits de fondo: esto te va a permitir si lo deseas usar 4 colores de fondo en tus juegos
sprite flipping horizontal: ahora puedes definir imágenes "virtuales", que en realidad se definen como el "flip" horizontal de una imagen real. Esto te permite ahorrar mucha memoria RAM destinada a gráficos. He hecho el horizontal y no el vertical porque el horizontal es el más útil. Normalmente un personaje que camina a la izquierda es la imagen especular del mismo caminando hacia la derecha, mientras que cuando sube hacia arriba muestra la espalda y al bajar muestra el pecho y la cara.
ejemplo de sprite flipping
Aparte del manual, voy a preparar un par de demos que incorporaré en la v33 de serie y de momento os dejo con una preview del nuevo juego "space phantom" inspirado en el mítico space harrier.
Os prometo publicar la 8BP v33 con su manual en breve
Estuvimos en uno de los eventos retro mas importantes de España: Retromadrid.
Interesantísimo punto de encuentro (no comercial) donde maquinas antiguas, desarrollos homebrew e intercambio de ideas se viven al minuto. Un evento de referencia para todos nosotros, con conferencias y talleres muy interesantes.
Este año fui con un amstrad CPC464, demostrando una vez mas que todos los juegos hechos con 8BP pueden correr en 64KB de RAM, sin trampa ni cartón. También llevé una Bartop para jugar a shooters hechos con 8BP como el Nibiru o el Anunnaki y un video introductorio a 8BP que os adjunto aqui:
Muchos serán los blogs que tratarán el contenido del evento y como no, la participación de Jon Ritman (creador de Batman, Head Over Hells, Match day...), que fue un invitado de excepción.
Estuvimos con Jon Ritman, el creador de Batman (entre otros)
Tuve la oportunidad de charlar con Jon Ritman y contarle lo que 8BP puede hacer. No todos los dias tenemos la ocasión de conocer en persona a una estrella del calibre de Jon.
Yo en este post os voy a contar mi impresión sobre el evento. Lo retro esta mas de moda que nunca. Y no hay una causa sino muchas. Una muy importante es que un videojuego de 8bit lo puede hacer una sola persona en unas pocas semanas (o a lo sumo meses), mientras que un juego para sistemas modernos requiere mas tiempo, mas detalles, mas trabajo. Además las limitaciones de estas máquinas, lejos de verse como un problema, son valoradas positivamente pues estimulan la imaginación y el ingenio.
gran acogida del videojuego "3D-Racing One", creado con 8BP
Los amantes de lo retro poseen una complicidad "silenciosa". Cuando un programador de Amstrad se encuentra con un programador de spectrum, commodore o MSX (o otro sistema antiguo), se dan la mano. Se entienden en el lenguaje secreto de los 8 bit.
El publico disfrutando de Anunnaki, 3D-racing one, Nibiru...
Otra cosa que me sorprendió fue el elevado número de niños que descubrieron y disfrutaron de los juegos de 8 bit. Su simplicidad, su fácil manejo, su clara mecánica...les atrapa. En verdad los juegos tan sencillos ya no están de moda y por lo tanto están "fuera del alcance" de las nuevas generaciones.
Los niños son verdaderos embajadores del sentido común, de lo que significa divertirse y su criterio esta limpio de modas. Son auténticos validadores de estos juegos.
Una distinguida visitante disfrutando con "Fresh fruits & vegetables", creado con 8BP
Incluso el primer juego construido con 8BP "Mutante Montoya", fue la delicia de grandes y pequeños. Incluso yo mismo estaba sorprendido. Es un juego sencillo, pero "engancha".
Publico jugando a "mutante montoya"
Una novedad interesante y que me causó una grata sensación fue ver un juego mio ("Nibiru") en edición física a la venta. No es mi intención ganar dinero y prometo donar lo poco que gane con el, pero reconozco que me hizo mucha ilusión. Fue como un deseo anhelado desde niño, ver un juego mio a la venta, en cassette.
gran acogida del juego "Nibiru" ejecutado con una Bartop con joystick profesional
Nibiru a la venta a precio ochentero
Durante la jornada del Sábado ofrecí una charla sobre programación Pseudo-3D, cuya capacidad está integrada en la librería 8BP desde la versión 32. He de decir que el público era excepcional: gente reunida en torno a un interés y una pasión común. Esa pasión nos conectaba a todos en la sala de conferencias. Para mi fue un placer compartir esas ideas con todos vosotros.
imagen de la charla de pseudo-3D
Hablé de como estaban programados los juegos en los 80: Pole Position, After burner, Space harrier... y tambien de como se hicieron los juegos pseudo 3D en el Amstrad, asi como de la programación pseudo 3D con la libreria 8BP.
Aunque en el canal oficial de Retromadrid aun no ha sido publicado, hay un canal de youtube que ya ha publicado la charla, aqui os la dejo. Cuando esté disponible el de Retromadrid, añadiré dicho video
Y por último solo me queda agradecer a la organización (a la Asociacion de Usuarios de Informatica Clasica - AUIC) y a todos, expositores y visitantes, por hacer de Retromadrid un gran punto de encuentro.
