Desarrollo de una librería de sprites en C

En la entrada anterior hemos visto que el manejo de sprites (y del VIC en general) con cc65 es sencillo. Llega con conocer las estructuras de datos de _vic2.h. y hacer asignaciones de valores a los registros.

Ahora bien, se puede hacer todavía más sencillo. Si recordamos, cc65 aporta header files, es decir, constantes, funciones y otras cosas para el manejo de joystick, ratón, consola, disco, gráficos, etc. ¿Por qué no hacer lo mismo con los sprites? ¿Por qué limitarnos a las estructuras de datos de _vic2.h y similares?

Y esto es precisamente lo que me planteo en esta entrada. Inspirándonos en la librería en ensamblador para manejar sprites del Volumen II, hacer una librería equivalente en C. Y la implementación de esa librería se apoyaría en _vic2.h.

Vamos a ello. Partimos del fichero lib-v2.zip disponible aquí:

https://programacionretroc64.files.wordpress.com/2019/11/lib-v2.zip

El contenido de ese ZIP es así (hay muchas librerías para diferentes propósitos):

Y si analizamos el fichero “LibSprites.asm” veremos que contiene estas rutinas:

  • Una rutina para copiar los datos de un sprite de un origen a un destino.
  • Una rutina para configurar los colores multicolor.
  • Una rutina para hacer la configuración básica de un sprite, es decir, para configurar su bloque, su color y activarlo.
  • Una rutina para posicionar un sprite.
  • Una rutina para hacer la configuración avanzada de un sprite, es decir, para configurar el multicolor, la expansión horizontal y/o vertical, y la prioridad sobre el fondo.
  • Una rutina para decidir si dos sprites están o no en colisión.

Todo esto lo vamos a convertir en dos ficheros en C:

  • sprites.h, que será el header file con los prototipos, constantes y demás.
  • Y sprites.c, que será la implementación de las funciones.

Por claridad, los nombres de las funciones serán similares a los de las rutinas, y lo de los parámetros también, salvando las diferencias lógicas por las nomenclaturas de nombrado en ensamblador y en C.

Fichero de cabecera sprites.h:

El fichero sprites.h quedaría así. Tendría una primera parte con constantes:

Una primera constante (__SPRITES_H) serviría para controlar si el header file ya está incluido en un programa y, en tal caso, no volver a incluirlo. A partir de ahí, habría constantes para el tamaño de los sprites (64 bytes), el número de sprites (8), controlar el multicolor, la expansión X e Y, la prioridad del fondo y las colisiones.

También aprovechamos para definir el tipo byte, que equivale a un unsigned char de C. Este tipo es muy útil para programar el C64, ya que es un ordenador de 8 bits.

Y la segunda parte sería así:

Es decir, primero define una estructura (el tipo de dato) para tener acceso a los punteros de los sprites, y luego define SPRITES_PUNTEROS como un puntero a ese tipo de estructura y lo vincula la posición $07f8, que es donde empiezan los punteros de los sprites ($07f8 – $07ff).

Por último, define los prototipos de las funciones que permiten copiar los datos de un sprite, configurar los multicolores, hacer la configuración básica de un sprite (puntero / bloque, color y activación), posicionar un sprite, hacer la configuración avanzada (multicolor, expansión y prioridad del fondo) y, por último, la función que permite detectar si dos sprites han colisionado.

Por supuesto, se pueden definir más funciones con otros propósitos, por ejemplo, para animar sprites, pero lo anterior es lo básico.

Fichero de implementación sprites.c:

La implementación de la librería de sprites es el fichero sprites.c. Este fichero incluye el sprites.h (#include <sprites.h>) y, a partir de ahí, aporta implementaciones para sus funciones. Estas implementaciones lógicamente se apoyan en las estructuras de datos de _vic2.h.

A modo de ejemplo, la implementación de la función sprites_conf_basica() sería así:

Es decir:

  • Recibe tres parámetros, el número de sprite, el bloque donde está almacenada la definición y el color deseado.
  • Guarda el bloque recibido en el puntero del sprite.
  • Guarda el color deseado en el registro del VIC encargado del color.
  • Y, mediante un OR, es decir, mediante el operador | de C, activa el bit correspondiente al sprite en el registro encargado de habilitar los sprites.

Las otras funciones tienen implementaciones similares. Su revisión queda como ejercicio para el lector interesado.

Programa de ejemplo:

Lo último sería hacer un programa de ejemplo que, usando la nueva librería, maneje sprites. Para ello nos inspiramos en el ejemplo de la entrada:

La versión en C sería así:

Es decir:

  • Limpia la pantalla con la función clrscr() de conio.
  • Instala el driver de los joysticks.
  • Configura los sprites.
  • Y, a partir de ahí, entra en un bucle que mueve un sprite, analiza las posibles colisiones y espera un tiempo. Y lo mismo con el otro sprite.

Las funciones para configurar los sprites, moverlos y analizar las colisiones se apoyan en la nueva librería.

Para configurar los sprites, la función conf_sprites() hace así:

A saber, configura los multicolores, que son compartidos entre todos los sprites, copia la definición del sprite 0 en el bloque 0 (254), hace su configuración básica (pone el puntero apuntando al bloque 254, configura el color verde y activa el sprite), hace su configuración avanzada (activa el multicolor, desactiva las expansiones y da prioridad al fondo), y termina con su posición. Y algo análogo con el sprite 1.

Por otro lado, para mover los sprites las funciones mueve_sprite_0() y mueve_sprite_1() hacen así:

Es decir, leen el joystick 1 y 2 respectivamente, y, en función del movimiento leído incrementan o decrementan la coordenada X o la Y. Finalmente, vuelven a posicionar el sprite.

Por último, para detectar las colisiones la función analiza_colision():

Es decir, se apoya directamente en la función sprites_colision() de la nueva librería. Y, en caso de detectar la colisión, termina la ejecución con exit().

El resultado es un viejo conocido:

En conclusión, que no hay por qué limitarse al uso de las estructuras de datos de _vic2.h. Sobre éstas es posible programar librerías que simplifiquen todavía más la programación con sprites o del VIC en general.


Código de ejemplo: sprites

Un ejemplo de sprites en C

Como hemos comentado varias veces, cc65, a través de su header file c64.h, tiene estructuras de datos que permiten manejar fácilmente el VIC, el SID, la RAM de color y las CIAs. Por ejemplo:

Y en el caso particular del VIC (ver header file cc65\include\_vic2.h):

Esto quiere decir que mediante una sintaxis de C tan sencilla como ésta (asignaciones):

VIC.spr0_x = 100

VIC.spr0_y = 100

es posible modificar la posición del sprite 0, por poner un ejemplo.

Veamos entonces cómo podemos hacer un ejemplo sencillo en C para manejar sprites. Si recordamos de alguna entrada antigua de este blog, para definir un sprite necesitamos:

  • Diseñar el aspecto gráfico del sprite y guardar los 64 bytes que lo definen (en realidad 63) en alguna zona de memoria.
  • Copiar esos 64 bytes a uno de los 256 “bloques” a los que tiene acceso el VIC.
  • Poner el puntero del sprite (posiciones $07f8 –$07ff, según el número de sprite) apuntando al bloque elegido.
  • Habilitar el sprite.
  • Elegir el color del sprite.
  • Posicionar el sprite.

Pues bien, veamos cada uno de estos pasos:

Diseñar el aspecto gráfico del sprite:

En este caso vamos a reutilizar algún sprite ya diseñado. Se trata de nuestra vieja amiga la pulga:

Guardar la definición del sprite en una zona de memoria:

Como sabemos, ese diseño de 24 x 21 pixels se traduce en (yendo de izquierda a derecha y de arriba abajo):

  • 3 bytes por fila (24 pixels).
  • 21 filas (21 pixels).
  • En total, 63 bytes.

En ocasiones, en vez de 63 bytes se manejan 64, aprovechando el byte 64 para guardar la información del color (o colores, en el caso multicolor). También puede ser mero relleno o, simplemente, manejar 63 bytes.

En nuestro ejemplo en C esos 64 bytes se traducen en este array de 64 bytes (o char, en C vienen a ser lo mismo):

Usamos notación hexadecimal (0x…) porque resulta lo más directo en este caso.

Copiar la definición del sprite a uno de los 256 bloques:

Se podría intentar que al cargar el programa PRG en el C64, esos 64 bytes se cargaran ya directamente en el bloque en el que tienen que estar. Sin embargo, no es lo más práctico.

Por ello, lo que vamos a hacer es copiar esos 64 bytes desde la posición que les haya tocado “en suerte” al compilar, hasta el bloque en que queremos que se almacenen. Esto lo hacemos con la función copia_def_sprite(), de la que lógicamente necesitamos prototipo e implementación.

La implementación es así:

Como se puede ver, el código es sencillo:

  • A partir del número de bloque determinamos la dirección destino multiplicando por 64.
  • Utilizamos la función estándar memcpy() para copiar los 64 bytes del sprite desde el origen (el array de bytes) hasta el destino (el bloque elegido).

Ya tenemos la definición del sprite en su sitio.

Configurar el puntero del sprite:

Para configurar el puntero del sprite tenemos que guardar el número de bloque elegido en la posición correspondiente al sprite, que es la $07f8 en el caso del sprite 0 y así sucesivamente hasta la $07ff en el caso del sprite 7 (en total, 8 sprites).

Esto lo hacemos con la función conf_ptr_sprite() que, en una primera aproximación, tiene una implementación muy similar a la de copia_def_sprite(), es decir, basada en memcpy():

Posteriormente, veremos otras implementaciones mejores y más claras.

Habilitar el sprite:

Lo siguiente es habilitar el sprite, para lo que ni siquiera necesitamos una función, ya que se trata de asignar el valor 1 (o el valor previo OR 1) a la posición SPENA = $d015, que está accesible mediante VIC.spr_ena.

Esto es tan sencillo que no merece un pantallazo propio, así que aprovechamos para presentar el programa principal en su conjunto. Véase la línea 29 en particular:

Como se puede ver en las primeras líneas del programa principal main(), estamos usando el sprite 0 y el bloque 254. Pero cambiar esto se ha hecho fácilmente configurable mediante variables (sprite y bloque).

Elegir el color y posicionar del sprite:

Con estas dos últimas operaciones ocurre lo mismo que con la habilitación del sprite, son tan sencillas que no requieren de funciones propias. En el caso del color se trata de dar valor a la variable VIC.spr0_color y en el caso de la posición a las variables VIC.spr0_x y VIC.spr0_y.

Una cosa chula del header file _vic2.h es que hay dos formas de usar los registros, bien mediante un nombre específico para cada sprite, o bien mediante un array con un índice que indica el número de sprite. Por ejemplo, en el caso de las posiciones (ídem colores, etc.):

Es decir, la posición del sprite 0 se puede cambiar:

  • Bien con VIC.spr0_x = X y VIC.spr0_y = Y.
  • O con VIC.spr_pos[0].x = X y VIC.spr_pos[0].y = Y.

La segunda forma me parece mejor, ya que permite trabajar con una variable “sprite” o “num_sprite” que en ocasiones valdrá 0, en otras 1, en otras 2, … Es más general.

Resultado:

Bueno, pues el resultado de compilar y ejecutar el programa es el que cabría esperar:

En realidad, el resultado no es tan espectacular. El tema sprites lo tenemos controlado desde hace tiempo. Lo que me resulta más espectacular es lo sencillo y directo que resulta hacerlo en C.

Y más sencillo que se puede hacer, lo que me dará pie a futuras entradas…

Mejoras:

En el ZIP adjunto encontraréis la versión original de este programa (sprite1.c), así como varias mejoras:

  • sprite2.c: En vez de usar el sprite 0 de forma fija usamos el sprite indicado por la variable “sprite”. Es decir, usamos las variables de _vic2.h en su variante por índice.
  • sprite3.c: Definimos un header file (sprite3.h) con variables para tener acceso de forma fácil a los punteros de los sprites (posiciones $07f8 – $07ff), de forma que no tengamos que usar memcpy() para algo tan sencillo como darles valor.
  • sprite4.c: Mejoramos el header file (ahora sprite4.h) para poder usar los punteros de los sprites mediante un índice, no con nombres fijos.

Mediante el uso de uniones de C se puede hacer un nuevo header file (sprite5.h) que permita tanto nombres fijos (SPR_PTR.spr0_ptr, SPR_PTR.spr1_ptr, …) como nombres con índice (SPR_PTR.spr_ptr[sprite]). Esto se deja como ejercicio para el lector.


Código de ejemplo: sprites

Entorno de ejecución de cc65 para el C64

Como ya comentamos algunas entradas más atrás, el resultado de compilar y enlazar un programa en C para el C64 con cc65 es un programa en código máquina con un cachito de BASIC que llama al código máquina con un comando SYS. Por tanto, los programas preparados con cc65 se cargan y ejecutan como si fueran programas en BASIC, pero su grueso es código máquina. Esta es la configuración por defecto, aunque se puede cambiar.

Respecto al mapa de memoria de los programas, estos empiezan en $0801, puesto que tienen ese trocito de BASIC, y pueden llegar hasta $cfff. Esto es así porque cc65 desactiva el intérprete de BASIC ($a000 – $bfff), pero mantiene los chips de entrada / salida (VIC, SID, RAM de color y CIAs) y el kernal.

La RAM de pantalla, salvo que se utilice el driver de Conio para 80 columnas, sigue en su sitio habitual: $0400 – $07e7. La pila de C empieza en $cfff y crece hacia abajo; no hay que confundir esta pila con la pila del C64 (página 1; $0100 – $01ff). Por último, el “heap”, que es de donde C saca la memoria para las estructuras de datos dinámicas que pudiera usar el programa (ej. listas enlazadas, árboles, etc.), se ubica al final del programa y crece hacia la pila (la pila de C).

Por tanto, el mapa de memoria sería algo así:

Ya comentamos anteriormente que cc65 tiene header files específicos para el C64 (cbm.h y c64.h), así como estructuras (structs) vinculadas a las direcciones de memoria del VIC, SID, RAM de color y CIAs, lo que permite manipular cómodamente desde C los registros de estos chips, básicamente haciendo asignaciones de valores a los campos de esas estructuras.

cc65 también tiene drivers para que el C64 pueda manejar gráficos TGI, la consola con Conio, el ratón, el joystick, etc., como hemos ido comentando en entradas anteriores.

También es interesante comentar que, para que el programa en C pueda recibir parámetros del entorno, se puede usar esta sintaxis al ejecutar el programa desde BASIC:

RUN : REM ARG1 “ARG 2” ARG3 “ARG 4” …

Igualmente, el programa en C puede devolver un valor de retorno al BASIC en la posición de memoria STATUS = $90 = 144.

Por último, es interesante comentar que es posible programar en C sacando provecho de las interrupciones del C64, si bien para ello las rutinas de interrupción tienen que estar en ensamblador.

Todo esto y mucho más se puede ver en detalle en la página:

https://cc65.github.io/doc/c64.html


Código de ejemplo: argumentos

Manejo de GEOS con geos.h

Es increíble, pero el C64 tuvo un sistema operativo con interfaz de usuario gráfica (GUI) ya en el año 1986. Se llamaba GEOS y podéis ver una descripción aquí:

https://es.wikipedia.org/wiki/GEOS

El GEOS se distribuyó sobre todo con el modelo C64C, y como mi modelo era la “panera” original, he de reconocer que en los 80 no caté mucho GEOS. Pero sí lo vi en funcionamiento en alguna ocasión.

Algunos aspectos increíbles de GEOS son:

  • Residía en disco. Había que cargarlo desde ahí.
  • Tenía interfaz de usuario gráfica.
  • Permitía el uso de ratón.
  • Incluía aplicaciones de edición de textos, hojas de cálculo, para pintar, etc. También había aplicaciones hechas por terceros.
  • Tenía un cargador turbo para disco.
  • Permitía el uso de múltiples impresoras.
  • Etc.

Un sitio interesante para aprender mucho sobre GEOS y descargarlo es éste:

https://cbmfiles.com/geos/

Concretamente, la descarga de GEOS para C64 en formato D64 se puede realizar desde aquí:

https://cbmfiles.com/geos/geosfiles/GEOS64.ZIP

En realidad, lo que te descargas es un fichero ZIP de unos 380 KB con varios discos en formato D64:

El disco / fichero que más nos interesa es el “GEOS64.D64”. Si lo arrastras a VICE…

Ahora sólo queda configurar un ratón o un joystick en VICE (puerto de control 1) y empezar a jugar con GEOS. ¿No es increíble?

En particular, con el menú de VICE File > Attach disk image > Drive 8 se puede conectar cualquiera de los otros discos, por ejemplo, el “APPS64.D64”, y explorar su contenido:

En cualquier caso, aquí estamos para hablar de cc65. Y ocurre que cc65 también soporta la programación en C para un C64 con GEOS mediante el header file geos.h. De hecho, si nos vamos a cc65\include veremos que no sólo tenemos el fichero geos.h, sino toda una carpeta geos con este contenido:

Es decir, que la programación en C para GEOS tiene su miga, hasta el punto de que no hay un único header file, sino 13, cada uno de ellos especializado en funciones concretas de este sistema operativo (constantes, disco, memoria, procesos, sprites, etc.).

La programación para GEOS, incluso en C que será más fácil que en ensamblador, queda fuera del objetivo de este blog, al menos de momento. Pero el que tenga interés puede profundizar en esta página de cc65:

https://cc65.github.io/doc/geos.html

Gráficos bitmap con tgi.h

TGI significa “Tiny Graphics Interface”, es decir, algo así como “interfaz para gráficos pequeña”. Por tanto, se trata de una librería para hacer gráficos con máquinas basadas en el 6502, en nuestro caso el C64.

Lo primero sería repasar los modos gráficos del C64:

Modos gráficos del C64:

Los modos gráficos del C64 ya los vimos hace tiempo en este blog:

  • Modo carácter estándar.
  • Modo carácter multicolor.
  • Modo carácter con color de fondo extendido.
  • Modo bitmap estándar.
  • Modo bitmap multicolor.

Todos estos modos pueden combinarse con sprites. Es más, usando interrupciones raster, también pueden combinarse varios modos gráficos entre sí, cambiando el modo cuando el raster llega a la línea X.

Y por recordar un poco más, el modo bitmap estándar tiene una resolución de 200 x 320 pixels y cada uno de esos pixels se puede activar / desactivar independientemente de todos los demás. El estado activado / desactivado de esos 64.000 pixels sale de 8.000 bytes de la RAM (no de la RAM de pantalla), y su color sale de la RAM de pantalla (no de la RAM de color). El color de los pixels activos y el de los pixels inactivos de un carácter 8 x 8, pueden ser diferentes de los colores de los pixels activos e inactivos del carácter 8 x 8 de al lado, pero esto no suele ser lo habitual. A final, en el modo bitmap estándar o “HIRES” lo habitual es tener un color uniforme para pintar formas (pixels activos) y otro color uniforme para el fondo (pixels inactivos). Por ejemplo, líneas blancas sobre fondo negro. En definitiva, es útil para líneas, polígonos, etc.

Por su parte, el modo bitmap multicolor es parecido al modo bitmap estándar, pero los pixels se agrupan de dos en dos en sentido horizontal. Por tanto, la resolución es de 200 x 160 pixels y, a cambio, en vez de dos fuentes de color se utilizan cuatro (por cada carácter 8 x 8). Es útil para gráficos tipo foto, dibujo, etc.

Pues bien, lo que nos ofrece tgi.h es una interfaz de programación, es decir, un conjunto de funciones y constantes, para programar en modo bitmap estándar con el C64.

Inspección de tgi.h:

Lo mejor es que le echemos un vistazo al header file tgi.h:

Como podemos ver, hay funciones para:

  • Pintar puntos o pixels.
  • Pintar una línea entre dos posiciones.
  • Continuar una línea desde la posición actual hasta otra.
  • Pintar círculos.
  • Pintar elipses.
  • Pintar arcos.
  • Pintar sectores.
  • Pintar rectángulos.
  • Pintar textos.
  • Etc.

Esta es la parte más representativa u obvia, pero también hay funciones y constantes para:

  • Cargar e instalar un driver.
  • Inicializar el modo gráfico o salir de él.
  • Cargar e instalar fuentes (tipos de letras).
  • Consultar códigos y mensajes de error.
  • Borrar la pantalla gráfica.
  • Contar el número de páginas disponibles.
  • Elegir la página que se ve y la que se pinta.
  • Consultar los colores disponibles.
  • Consultar y fijar el color con que se pinta.
  • Consultar la resolución.
  • Cambiar la posición actual.

Como siempre, lo mejor es verlo con un ejemplo o, mejor todavía, con un par.

Primer programa de ejemplo con tgi.h:

El primer programa va a ser muy sencillo. Básicamente vamos a instalar el driver y luego vamos a preguntarle cosas. Algo así:

De este modo, si compilamos y ejecutamos:

averiguamos que el driver de TGI para el C64:

  • Soporta una única página.
  • Soporta dos colores, que son el blanco y el negro.
  • Que la resolución es 320 x 200, es decir, bitmap estándar.
  • Y que la ratio de aspecto es 212.

Bueno, no está mal para empezar, vamos con el segundo.

Segundo programa de ejemplo con tgi.h:

El segundo programa tiene una primera parte que instala el driver, inicializa el modo gráfico y llama a una función pinta_tgi() (también tiene una última llamada que sale del modo gráfico, pero actualmente está comentada para ver el resultado):

Por su parte, la función pinta_tgi() es así:

Es decir:

  • Borra la pantalla gráfica.
  • Fija el color blanco como color de pintado.
  • Activa el pixel (10, 10).
  • Pinta una línea entre un origen y un final.
  • Continúa la línea hasta otro nuevo final.
  • Pinta un círculo.
  • Pinta una elipse.
  • Y pinta una barra o rectángulo.

Adicionalmente hay unas líneas finales relativas al pintado de algún texto, pero yo no he conseguido que me funcionen. Quizás algún lector se anime a dar alguna pista extra.


Código de ejemplo: tgi