Mariano the dragon went to the room and found a spoon.

Pues sí, hoy mismo ha salido para CPC y ZX Spectrum un nuevo silver de CEZGS, Mariano the Dragon: Capers in Cityland, que se nos presenta como “FX Do It Yourself“. Tanto la versión de CPC como la de ZX Spectrum están concebidas como tutoriales sobre diseño de juegos usando dos lenguajes sobre dos plataformas diferentes.

Vete a descargarlo de CEZGS.

En este blog iré desgranando la versión de Speccy. Si soléis leer este blog, recordaréis los artículos que empecé a escribir sobre cómo montarse un juego de plataformas en BASIC compilado. La versión de ZX Spectrum de Mariano está construida usando las técnicas que había explicado y otras que me restaba por explicar. Preferí tener el juego en la calle antes de seguir explicando cosas, porque en conjunto todo se ve mucho mejor que a trozos discretos.

En el próximo artículo de programación empezaremos a ver cómo es la estructura básica del juego dividiéndolo en componentes discretos que iremos construyendo poco a poco. Los conceptos explicados serán aplicables a cualquier tipo de juego de puzzles hecho con cualquier lenguaje, así que quizá puedan serte interesantes aunque no quieras programar en BASIC y tener que aguantarte con movimientos de 8 en 8 píxels. Cómo construir las comprobaciones, cómo armar los triggers para las mismas, etcétera.

Muy pronto en tu blog

Paper TCYR #8

Llegamos ya al número 8, mi preferido. Rima con bizcocho, con chocho, con tocho y con mocho, y además es un cero con el cinturón apretao para estar maquebo y petón. Y, además, contiene muchas cosas divertidas. Descargáoslo y decidme qué os parece, que es gratis

LOKOsoft games

Inauguramos una nueva sección en el blog: LOKOsoft games (aquí), accesible desde la barra superior. En ella iré recopilando y ordenando todos mis viejos juegos a medida que vaya hablando de ellos en el blog. Ahora mismo podéis encontrar todos y cada uno de los juegos que han sido comentados aquí, junto con un par de pantallas y un enlace para la descarga, ordenados más o menos cronológicamente (por años seguro, pero entre ellos… ¡tendréis que confiar en mi memoria!).

Espero que os guste. La verdad es que es un subidón ver toooodos esos juegos ahí juntitos… ¡Y quedan un montón, sobre todo en PC! Huelga decir que la sección se irá actualizando a medida que vaya añadiendo juegos.

Pues eso, ¡a disfrutarla!

Programación #9… El tema de las ROMs de IF2 sin chicha

Sin chicha porque no voy a mostrar nada más, sólo daros una especie de noticia o de update de lo que estoy haciendo, ya que aún no tengo nada sólido (o casi nada) y llevo muchos días sin actualizar por motivos de carga laboral.

El tema es que splib2 tenía sus tejemanejes de lectura/escritura en sus propias variables y había que tocarla un poco para poder adecuarla a su ejecución desde ROM. Por suerte, Alvin Albrecht es el tío más participativo que existe y me ha ayudado muchísimo, hasta el punto de indicarme qué tenía que cambiar específicamente y hacer pruebas él mismo para asegurarse de que todo funcionaba.

Así que, podemos decir que es posible crear juegos de IF2 con z88dk+splib2. Además, Alvin me ha comentado que sería muchísimo más fácil hacerlos con SP1 (a.k.a. “splib3“) en lugar de splib2.

El tema iba de mover cuatro estructuras tochas, separándolas de la biblioteca y considerándolas externas, para poder almacenarlas “aparte” en RAM. Estas estructuras son, básicamente, las que controlan el buffer: el display list, la lista de dirty chars, la localización en memoria de los tiles y una serie de listas empleadas en la actualización de la pantalla. Las estructuras creadas por sp_Initialize() por lo visto resultan ser de sólo lectura, por lo que pueden ir en ROM. El tema, por tanto, quedaría más o menos así:

en ROM:

$0000-$31FF nuestro programa.
$3200-$3FFF rotation tables

en RAM:

$4000-$5AFF VRAM, aunque estoy pensándome emplear el primer tercio ($4000-$47FF) para pila y tiestos.
$5B00-$6FFF libre para nuestros datos descomprimidos desde ROM o lo que sea.
$7000-$7FFF las cuatro estructuras de splib2 anteriormente mencionadas y nuestras globales.

Ahora mismo tengo toda esta información, sólo tengo que armarme el proyecto en condiciones y empezar a programar algo real y que se mueva. Cuando tenga algo tangible, os explicaré cómo montar todo el tema y eso y veréis que tampoco es tan coñazo… Sólo un poco laborioso la primera vez.

¡Deseadme suerte!

Programación #7: Creando una ROM de Spectrum con z88dk

Buenas. Lo siguiente dentro de la lista de hitos para conseguir hacer un juego para Interface 2 usando z88dk + splib2 viene a ser conseguir generar un archivo de ROM. Antes de meternos en verea, vamos a explicar unas cosillas. z88dk es un compilador multi-plataforma. El +zx que especificamos al compilar simplemente sirve para que se lea un archivos de configuración con código y parámetros específicos para el ZX Spectrum. Este archivo es lib/config/zx.cfg (lib/config/zx.lnx en linux). En este archivo, además de definirse qué reglas de optimización se emplearán y qué parámetros específicos necesita el compilador para generar un binario para Spectrum, se especifica el crt0 que se empleará. Un crt0 no es más que código de inicio. Básicamente se suele colocar la pila, preparar el sistema un poco, establecer el punto de entrada para ejecutar (dónde está main, vamos) y cosas así. El tema es que el crt0 para Spectrum no nos sirve ya que está preparado para programas que se ejecuten en RAM. En este capítulo crearemos nuestro propio archivo de configuración y nuestro propio crt0 para juegos en ROM, y al final escribiremos un programa pocho para probar que funciona todo. En el próximo capítulo veremos cómo colocar variables globales e intentaremos linkar contra splib2 (¡¡espero que no emplee código automodificable ni variables ni nada!!).

Programación #6: Juego en ROM para Spectrum 16K usando z88dk+splib2

Pues sí, me ha picado el gusanillo con el concurso que anuncia Radastan para el año que viene. Se trata de hacer un juego que funcione como cartucho ROM del IF2 para Spectrum y que funcione en cualquier Spectrum de 16K. Eso significa que debe ser un juego que ocupe 16K (de $0000 a $3FFF, reemplazando a la ROM), y que tenemos aproximadamente unos 9K de RAM extra para hacer que se mueva (si le quitamos a los 16K del Spectrum 16K los 7K que ocupa la pantalla (VRAM) nos quedamos con 9K).

Esto implica importantes limitaciones (¡por si no tuviéramos ya bastantes!):

• No podemos usar ninguna rutina de la ROM. Como el juego lo voy a hacer en C usando splib2 para todo, esto no es un problema.
• Toda la RAM que tenemos está en la zona de la memoria en contienda (la ULA y la CPU se pelean por esta memoria y gana la ULA siempre), por lo que responderá más lentamente.
• ¡Sólo! tenemos 9K de RAM para jugar, y aquí tendré que meter los aproximadamente 5K que ocupan las estructuras de la splib2, lo que nos deja con 4K para la pila y lo que pueda caber.

La idea es la siguiente: Colocar las estructuras de la splib2 y todas las variables en los 9K de RAM, configurar la splib2 para que ocupe lo justo en la pantalla (de las 24 lineas de carácteres) para que se tarde menos en actualizar el display, usar Orfeus para una musiquilla del menú (si cabe), tener el mapa comprimido en ROM y descomprimirlo en la RAM que quede libre para tener más sitio para código y gráficos y poco más.

En el momento de estar escribiendo estas lineas aún no tengo la seguridad de que lo que quiero hacer sea factible, así que tómate estos artículos más como un “cuaderno de bitácora” que como un “tutorial“, ya que los tutoriales se hacen, por lo general, cuando uno sabe cómo resolver los temas de los que trata, y este no es el caso. Veamos…

Programación #5: Enemigos plataformeros en BASIC.

Continuando con los artículos de programación BASIC, seguimos con los enemigos. Ya tenemos completamente solucionado el movimiento de nuestro héroe, así que ahora toca proveerle de antagonistas que haga que el juego tenga algún aliciente.

Además, lo vamos a hacer bien. Lo más fácil a la hora de ponerse a hacer un juego (y más en BASIC Spectrum) es liarse a hardcodear como locos. Lo ideal, sin embargo, es construir los motores de juego lo más generales que sea posible, de forma que toda la forma del juego (pantallas, objetos, enemigos …) puedan leerse de ristras de datos que el motor interprete. Así podremos reaprovechar partes del motor (o todo él, esto es muy divertido), obteniendo nuevos juegos en muy poco tiempo símplemente cambiando los datos.

Por tanto, vamos a crear un sistema de manejo de enemigos totalmente parametrizable y ampliable, en el que nos sea muy sencillo añadir nuevos patrones de movimiento o tipos de enemigos. Pasen y vean, señores.

Programación #4: Intercalando datos de sprites en z88dk+splib2

Sigo repasando temas que no quedan realmente claros en la documentación y con los que me tuve que enfrentar en tiempos a la hora de programar mis juegos. Hoy le toca el turno al intercalado de sprites en memoria. Si hemos usado alguna vez la splib2, sabremos que las columnas de los sprites se almacenan en memoria intercalando un byte de gráfico, uno de máscara. La cosa es que si vamos a usar los sprites con OR o XOR no necesitamos la máscara y estamos tirando un byte de memoria por cada byte de gráfico, lo cual no mola en absoluto teniendo tan poca memoria disponible.

El “truco” que me comentó Alvin Albrecht se basaba en intercalar las definiciones de sprites de forma que se ocupen los valores que suelen emplearse para almacenar una máscara guardando los datos gráficos de otra columna de otro sprite. El tema es realmente sencillo y trivial, pero antes hay que entender un poco cómo funciona el tema. Espero que este artículo os ayude a entenderlo al 100% de forma que podáis hacer uso de la técnica cuando no necesitéis máscaras.

Programación #3: Mejorando el motor de plataformas BASIC y otras coserías.

Buenas. Tras el éxito demoledor de mi anterior entrada (de valor arqueológico demostrado, rescatando una parte perdida de la Historia de los Videojuegos como es una versión RC del Tomb Raider 2 para PSX y que prometí que investigaría pero que no he tenido tiempo ni de tocar), con ningún comentario, y una baja de visitas acojonante en la última semana (por mi culpa y no actualizar :P), me dispongo a seguir con el tema de la programación, que aunque también me resulte parco en cuanto a comentarios (y eso que se supone que se piden por vuestro bien), sé que al menos ayuda a algunos programadores anónimos. Como no he recibido ninguna indicación sobre el nivel, doy el empleado en el anterior artículo sobre BASIC como “bueno” y sigo en mi linea.

Como hablamos adelantamos el martes pasado, en el anterior artículo, hoy nos dedicaremos a pulir un poco el motor de plataformas BASIC símplemente añadiéndole soporte para pulsaciones simultáneas de teclas, lo que aumentará la jugabilidad muchísimos enteros. Sin más dilación, pasemos a hablar de los puertos de E/S.

Programación #2: Memoria dinámica en splib2

Hoy toca comentario. Tengo uno muy jugoso (amigos, ha aparecido una beta de Tomb Raider 2 para PSX ¡¡y yo la tengo!!), pero como no sé si tendré tiempo de elaborarlo, pongo esto que es más rápido y lo considero muy interesante para los que están usando z88dk+splib2 para hacer sus juegos.

Se trata de un tema que yo tuve que currarme un poco a cabezazos, entre la parca documentación y las explicaciones del propio Albrecht, y que resulta realmente indispensable para poder sacar el máximo partido a esta biblioteca: comprender cómo gestiona la memoria. 48K son pocos, y hay que aprovechar hasta el último byte. Comprendiendo qué estructuras maneja splib2 en memoria tendremos más herramientas para saber dónde colocar cosas para apretujar todo al máximo y que no tengamos problemas de ningún tipo. En próximos capítulos, explicaremos cómo usar la paginación para poder acceder a los 128K, pero para ello es muy importante tener claros los conceptos que vamos a explicar en este breve articulín.