Rememorando libros que tengo por ahí de programación en BASIC para Commodore 64 me acordé de un ejemplo que vi en el que se "pinta" un globo.
Usando caracteres en BASIC y luego mediante un algoritmo, se convierte el globo en un Sprite y se pinta en pantalla.
El ejemplo es muy bueno, dado que usa los conceptos básicos del uso de un Sprite y se usa un pequeño algoritmo para pasar ese dibujo en caracteres a pantalla.
En la segunda imagen, se ve que hay tres bucles anidados, para ir leyendo los caracteres contenidos en el DATA e ir calculando el valor para el Sprite.
Es un truco muy chulo, pero sumamente lento. Está muy bien, para aprender pero nada más.
Además, va imprimiendo en pantlla el valor entero (de o a 253) de cada cálculo del Sprite.
Os dejo una imagen de disco D64 para poder cargar el código fuente en un emulador en este enlace.
Solo recordar que hay tres entradas, cubriendo el tema de los Sprites, junto con una herramienta de desarrollo en este mismo blog, por si interesa profundizar en el tema.
Hace un tiempo recomendé el entorno de desarrollo para Commodore 64, el CBM .prog Studio.
Aunque tiene carencias básicas con respecto a lo que estoy acostumbrado para el ZX Spectrum (BasinC), como por ejemplo, la imposibilidad de depurar código BASIC, es un entorno bastante completo y que tiene una organización estructural muy buena para el desarrollo de proyectos para el Commodore 64.
Voy a aprovechar que quiero refrescar los conceptos básicos del manejo de Sprites desde el BASIC del Commodore 64, para darle visibilidad a esta herramienta de desarrollo.
Si lo que queremos es desarrollar en ensamblador, la situación es distinta. Para código ensamblador el entorno sí que permite depuración y está mucho más avanzado.
Aprovecharé entonces, el repaso que vamos a hacer de los Sprites en BASIC, para utilizar determinada funcionalidad del entorno CBM .prog Studio y así darlo a conocer.
Lo primero que tenemos que hacer es descargarlo e instalarlo.
Además, si no tenemos el emulador VICE funcionando, nos haremos con él y lo instalaremos también.
Con ambas cosas ya instaladas, lo primero es configurar el CBM .prog Studio para decirle en que directorio por defecto nos creará los proyectos y donde reside el emulador VICE.
En el menú "Tools, Options" podemos definir el valor del directorio por defecto para nuestros proyectos.
Luego nos vamos a "Emulator Control" y le damos el directorio donde tenemos instalado el emulador VICE.
No hace falta tener un proyecto ya abierto para hacer esta configuración, la podemos hacer sin ninguno abierto.
Ahora, procedemos a crear un nuevo proyecto.
El entorno tiene plantillas de proyecto para proyectos tipo BASIC y tipo ensamblador.
Nos vamos a "File" y a "New basic Project".
Nos mostrará una ventana emergente, donde podemos personalizar.
Esta es la pinta que tendrá nuestro entorno:
Ya estamos listos para comenzar con nuestro código.
Una cosa MUY importante que tenemos que hacer, si no queremos recibir petardazos continuamente, es modificar las propiedades del proyecto para decirle cual es el programa principal.
Por defecto lo trata de "adivinar", dado que puede haber código BASIC y ensamblador mezclado, pero esto está dando problemas, si sólo tenemos BASIC.
Así que a "Project", Properties y le decimos que solo compile nuestro programa principal.
Vamos a usar "El Editor de Pantallas" para crearnos una pantalla chula como comienzo del programa.
Botón de la derecha en "Screen Designs" y añadimos uno nuevo.
Luego con doble click abrimos el editor.
Este editor nos deja trabajar tanto con los dos set de caracteres por defecto como con los que hallamos creado nosotros.
Yo me he hecho una pantalla tal que así:
Las posibilidades las podéis explorar, yo he usado lo más básico para hacer un marco con un título.
En el menú "File" podemos exportar a código BASIC, lo que nos abrirá la ventana de "Preview". De ahí podemos copiar y pegar en nuestro código.
Luego de pegado, lo apañamos lo re - numeramos y lo que nos parezca.
En el siguiente capítulo editaremos un sprite y lo cargaremos en pantalla, para lo cual refrescaremos los conceptos básicos para manejar Sprites desde C64 BASIC.
El proyecto completo lo puedes descargar de este enlace.
Una de las cosas que más me llamó la atención cuando me pasé de Sinclair BASIC a Commodore 64 BASIC a cacharrear, es que no hay ¡ PRINT AT !.
¿Como se les puede haber pasado el implementar esta funcionalidad en el comando PRINT del BASIC ?. ¡En qué estaban pensando!.
Bueno, he aquí un par de posibilidades para simular el comando PRINT AT.
Una de ellas, la primera, se basa en "engañar" al comando PRINT del BASIC, con alguna instrucción que otra, para que se posicione donde queremos imprimir en pantalla.
La segunda, fija directamente el cursor en la posición de la pantalla donde queremos imprimir, usando POKEs.
La primera quedaría tal que así:
10 REM Buscando una altgernativa al PRINT AT
20 REM de Sinclair BASIC para el C64 BASIC
30 REM Posibilidad 1. Usando caracteres especiales
40 REM del C64 BASIC y el comando BASIC
50 REM ********* Modo 1 **************************
55 print "{clear}"
60 X$="{home}{right*39}"
70 Y$="{down*24}"
80 x=1:y=1
90 print left$(x$,x)right$(y$,y)" AAAAAAAAAAAAAAAAAAAAAA";
100 x=2:y=2 110
110 print left$(x$,x)right$(y$,y)"hola";
120 x=2:y=10 130
130 print left$(x$,x)right$(y$,y)"mundo";
140 x=10:y=10 150
150 print left$(x$,x)right$(y$,y)"hola mundo!";
152 x=1:y=12:print left$(x$,x)right$(y$,y)"";
155 rem *************************************
Si ejecutamos el programa, vemos el resultado :
Usamos X e Y para fijar donde queremos imprimir, y luego imprimimos el texto en pantalla usando printleft$(x$,x)right$(y$,y)+ el texto que queremos.
Hay una segunda opción, que es la que más me gusta, que es directamente posicionar el cursor en pantalla, donde queremos imprimir, y luego simplemente usar PRINT.
En C64 BASIC esto se consigue con la siguiente rutina, que puedes usar en tus programas:
999 REM Rutina que posiciona el cursor en un determinado sitio
1000 poke 780,0:REM fijamos cero para resetear
1010 poke 781,row:REM a memoria la fila(X)
1020 poke 782,col:REM a memoria la columna(Y)
1030 sys 65520 : REM fijamos el cursor en X,Y
1040 return
Los POKE 781 y 782 son los registros .X y .Y en la máquina, y la istrucción sys 65520 posiciona el cursor en pantalla en las coordenadas que están en 781 y 782.
SAREG 030C 780 Storage for 6502 .A Register SXREG 030D 781 Storage for 5502 .X Register SYREG 030E 782 Storage for 6502 .Y Register PLOT $FFF0 65520 Read/set X,Y cursor position
Usar la rutina se convierte simplemente en esto:
200 row = 5:col = 10:gosub 1000
210 print "hola"
Este método es mucho mejor y más limpio que el primero, en mi opinión, aunque ambos nos permiten saber donde hemos dejado el cursor después de haber impreso en pantalla.
Un pequeño vídeo del programa de demostración en cuestión:
Bueno, es simplemente un texto que va de derecha a izquierda en pantalla, aparece y desaparece en bucle.
Como nosotros leemos de izquierda a derecha, lo conveniente es que el texto aparezca de derecha a izquierda.
Puedes descargar el código fuente en formato TAP de este enlace.
Abajo el código BASIC.
Es muy sencillo
10 CLS 20 PRINT AT 0,0;"Pulsa q para terminar" 30 LET M$="MARQUESINA" 40 LET C=1 50 FOR I=31 TO 0 STEP -1 60 PRINT AT 20,I;M$(1 TO C) 70 IF C<LEN (M$) THEN LET C=c+1 80 IF (31-i)>=LEN (m$) THEN PRINT AT 20,i+LEN (m$);" " 90 GO SUB 170 100 NEXT I 110 FOR i=1 TO LEN (m$) STEP 1 120 PRINT AT 20,0;m$(i TO LEN (m$)) 130 PRINT AT 20,LEN (m$)-i;" " 140 GO SUB 170 150 NEXT i 160 GO TO 40 170 LET i$=INKEY$ 180 IF i$="q" THEN STOP 190 RETURN
Unas coordenadas de origen (X,Y) en modo carácter.
Número de celdas para el desplazamiento.
Una dirección (arriba, abajo y diagonales).
... nos pinte la línea de 8 bits, a modo de misil y atraviese lo que esté en el camino, respetando sus propiedades de dibujo, color y fondo.
Dado que tenemos un límite de 2 colores, por celda, veremos el efecto de como va cambiando de color a medida que el misil va pasando por encima del contenido.
Los efectos más deseables, se logran con el fondo "blanco" y sin brillo ni intermitencia. En el ejemplo se usan estos modos, para que se vea como el programa es capaz de respetar las propiedades de cada cosa.
Veamos el programa en acción:
Con este ejemplo, podemos extrapolar subrutinas, para poder implementar el lanzamiento de misiles en el juego Retro8ogue.
Además, para optimizar al máximo el paso a código máquina, usando el compilador HiBasic, he usado las directivas de compilación apropiadas para marcar (casi) todas las variables como enteros positivos, además de las longitudes máximas de cada variable cadena usada.
El compilador de BASIC funciona de forma óptima, cuando trabaja con enteros, y más, si son enteros positivos.
Todas estas optimizaciones permiten dejar el compilado con solo 278 bytes para variables, además de presentar el mejor rendimiento.
Es muy cómodo trabajar con las coordenadas X e Y de baja resolución, para utilizar comandos como PRINT AT y SCREEN$ en pantalla.
Las coordenadas de "baja resolución" son perfectas para manejarnos en modo "carácter" y con UDG's de 8x8 básicos.
El modo de "alta resolución" de nuestro Spectrum son 255 pixels horizontales por 175 pixels verticales.
Cuando queremos crear formas geométricas, o simplemente pintar una línea recta usamos comandos pomo DRAW y PLOT, que usan las coordenadas de alta resolución.
Es una gran ventaja el poder combinar el uso de ambos modos gráficos ; simplemente usando el comando y las coordenadas que nos interesen a cada fin.
Por ejemplo, el juego Retro8ogue utiliza el modo carácter para casi todo, usando las coordenadas del modo de "baja resolución" (comandos PRINT AT y SCREEN$ básicamente).
Para poder pintar, por ejemplo, una pequeña línea, que viaje a través de la pantalla (es decir, una flecha) parece más apropiado usar el comando PLOT que crear varios UDG's; uno por cada uno de las 4 direcciones en las que la "flecha" se podría desplazar.
Entonces, ¿como combinamos el uso de ambos modos gráficos, en función de lo que hay en pantalla?.
Pues lo más sencillo es , dado un "carácter" o UDG en pantalla (posiciones X e Y de modo "baja resolución") calcular cuales son sus coordenadas X e Y en modo "alta resolución".
Para ello, usamos dos funciones BASIC en nuestro programa:
Para calcular la coordenada X:
DEF FN x(x)=x*8
El valor inicial de la posición X es la coordenada X por 8. Como cada "celda" en el modo de baja resolución es de 8x8, esta función nos devolverá la coordenada X donde se encuentra el primer pixel, en alta resolución.
Para calcular la coordenada Y:
DEF FN y(y)=ABS ((y*8)-168)
Dado que la coordenada Y en el modo de baja resolución, va "al revés" que en el modo de alta resolución (en baja se cuenta de arriba a abajo y en alta de abajo a arriba, en pantalla) sacamos el valor absoluto de la coordenada Y multiplicado por 8, y restando la última posición inicial de las celdas en vertical, que es 168.
Hay que recordar que estas fórmulas nos devuelven los valores iniciales de X e Y.
La celda "completa" que representan las coordenadas de modo carácter que le hemos pasado a las funciones, son las coordenadas X e Y de alta resolución más 8 (bits).
En el código de ejemplo de abajo, calculamos las coordenadas de alta resolución, y pintamos una X en la "celda" a la que pertenecen.
El código fuente en BASIC, del ejemplo también lo puedes descargar aquí.
Después del código hay un vídeo ilustrativo.
10 CLS : LET lx=0: LET ly=0: LET hy=0: LET hx=0
20 DEF FN x(x)=x*8
30 DEF FN y(y)=ABS ((y*8)-168)
40 INPUT "Entra coor. Y :";ly
50 INPUT "Entra coor. X :";lx
60 IF lx<0 OR lx>31 OR ly<0 OR ly>21 THEN PRINT AT 2,2;"Val. no val. 0>X<32. 0>Y<22": GO TO 40
70 PRINT AT 2,2;" ": PRINT AT 2,2;"Lo X: ";lx
80 PRINT AT 3,2;" ": PRINT AT 3,2;"Lo Y: ";ly
90 LET hx=FN x(lx): LET hy=FN y(ly)
100 PRINT AT 4,2;" ": PRINT AT 4,2;"Hi X: ";hx
110 PRINT AT 5,2;" ": PRINT AT 5,2;"Hi Y: ";hy
120 INPUT "Pintar X ?";z$
130 IF z$="s" THEN GO SUB 200
140 INPUT "salir ? s/n ";z$
150 IF z$="s" THEN GO TO 180
160 PRINT AT 2,2;" "
170 GO TO 10
180 STOP
190 RETURN
200 FOR a=0 TO 7
210 PLOT hx+a,hy+a
220 PLOT hx+a,(hy+7)-a
230 NEXT a
240 RETURN
Una de las cosas más comunes en los juegos es implementar un algoritmo que lleve a un personaje del punto A al punto B. En el camino, siempre, obstáculos por donde no se puede pasar.
Estos algoritmos, denominados "Path Finding" o "Búsqueda de Camino", están muy bien documentados y hay muchísimos ejemplos en Internet para entornos de programación actuales.
Bueno, ¿ Que pasa si queremos implementar esta funcionalidad en Sinclair BASIC ?.
Nos encontramos con varios problemas:
El uso de recursos de lenguaje de programación como colas, objectos , etc.
Las limitaciones propias del Sinclair BASIC. Tenemos muy poca memoria donde debe residir todo el programa o juego, no solo el algoritmo y un numero muy limitado de espacio para variables.
La velocidad de proceso en Sinclair BASIC, sobre todo dentro de bucles.
Todo esto comienza como parte del desarrollo del juego Retro8ogue. Estoy en la fase de implementar el movimiento de los monstruos en pantalla, pero con sentido (o lo que llaman también I.A., Inteligencia Artificial).
Una vez dentro del rango de visión / oído del monstruo, éste debe encontrar el camino hacia el personaje, independientemente del mapa y los obstáculos que se pueda encontrar. Como es un juego rogue - like, el mapa es generado aleatoriamente y nunca es igual.
Dadas las limitaciones, partimos de las siguientes premisas:
Un poco de aleatoriedad, para darle al personaje alguna posibilidad, cuando se enfrenta a varios monstruos en avance.
Es decir, simplificar al máximo las posibilidades de búsqueda para minimizar el código y las necesidades de proceso. Añadir un poquito de aleatoriedad en la búsqueda del mejor camino.
Veamos el ejemplo en pantalla de nuestro intento:
Hay una escalera que el personaje tiene que encontrar.
El mapa es aleatorio, pero no muy poblado de bloques para facilitar la labor.
Lo primero que definimos es que hay 8 direcciones posibles para el personaje.
4 5 6
3@7
2 1 8
La idea es que, de las 8 posibles direcciones, ¿cual es la que está mas cerca del objetivo?.
Todo lo hacemos con coordenadas X e Y, para lo que la pantalla del Spectrum es perfecta.
Esto lo calculamos de la siguiente manera:
d = ABS(destino_x - origen_x)+ABS(destino_y-origen_y)
Si calculamos esto sobre las 8 posibles direcciones que podemos seguir, sabemos cual es la que mas cerca nos deja del objetivo. Si esa dirección está ocupada por algo que no nos deja pasar, nos movemos de forma aleatoria 1 vez.
Hay muchas maneras más efectiva de hacer esto, pero la utilizada nos garantiza que:
Eventualmente, lleguemos al objetivo.
El monstruo se comporta de vez en cuando de forma aleatoria en su movimiento, lo que añade jugabilidad al juego.
Es muy fácil de implementar en BASIC y de optimizar para usar el mínimo de código, variables y proceso.
El resultado en BASIC es aceptable en términos de rendimiento, y una vez pasado a código máquina, funciona de forma excelente.
Si al ejemplo le quitamos el uso de detección de UDG's , irá aún más rápido. He utilizado los UDG's para hacer el ejemplo más completo y aplicable al desarrollo de Retro8ogue.
Hay otras optimizaciones hechas en el movimiento aleatorio para que no se pierda tiempo, pero esas las puedes ver en el propio código (como no intentar otra vez un lado que está obstruido en el mismo ciclo).
Puedes descargar una cinta en formato TAP con el código Sincalir Basic aquí.
Puedes descargar una cinta en formato TAP con el programa en código máquina aquí.
He aquí un ejemplo de como podemos implementar un cursor en pantalla.
Está pensado para trabajar, como un cursor en pantalla de modo texto, al uso de lo que estamos acostumbrados.
Para realizar el cursor, tenemos que tener en cuenta tanto las características del BASIC como las limitaciones en pantalla a la hora de imprimir texto.
Es decir, tenemos que gestionar dos cosas:
1) El texto que se encuentra en las coordenadas del cursor.
2) Los atributos de dicho texto (color del texto, color de fondo, brillo e intermitencia).
El cursor debe desplazarse por la pantalla sin modificar el valor original de la celda donde se encuentre. Para ellos tenemos que tener en cuenta los puntos 1 y 2 cuando movamos dicho cursor.
Para esto usaremos dos funciones del BASIC;
1) SCREEN$ para obtener el carácter que está en las coordenadas X,Y.
2) ATTR para obtener sus atributos (color, fondo brillo e intermitencia). Usa el mismo mecanismo de coordenadas X e Y.
La función SCREEN$ nos devuelve (solo) el carácter que está en la celda X,Y. No devuelve ni sus atributos (que se obtienen con ATTR) ni valor cuando el carácter en la celda es un UDG.
Para obtener un valor si es un UDG hay una manera, que se describe en otro ejemplo.
El valor que nos devuelve ATTR es un valor numérico que se descompone de la siguiente manera:
Si el valor es superior a 128, el carácter está en modo intermitente (FLASH 1).
Si el valor es superior a 68, el carácter tiene brillo (BRIGHT 1).
El valor de ATTR (si toca restar porque es mayor de 68 y/o 128) dividido entre 8 nos da el color del fondo (PAPER).
El valor de ATTR menos el valor del fondo (PAPER) nos da el color del carácter (INK).
Extracto del programa de ejemplo:
LET f=0
IF z>128 THEN LET f=1: LET z=z-128
LET b=0
IF z>64 THEN LET b=1: LET z=z-64
LET p=INT (z/8)
LET co=z-(p*8)
PRINT FLASH f; INK co; BRIGHT b; PAPER p;z$
La filosofía del cursor es sencilla:
1) Guardamos en dos variables el valor de la celda y sus astributos.
2) Imprimimos el cursor encima (OVER 1) ,intermitente (FLASH 1) y con brillo (BRIGHT 1) para que se vea fácil en el ejemplo.
3) Al movernos, restauramos el valor de la celda donde estábamos.
Llenamos la pantalla de caracteres generados de forma aleatoria y vemos como funciona el cursor. En la parte de abajo nos da una linea de ayuda con las teclas para mover dicho cursor.
He usado unos UDG de flechas en la linea de ayuda, para hacerlo más amigable.
Una versión del ejemplo pasada a código máquina la tienes aquí.
Debajo de la imagen está el listado completo por si lo quieres copiar y pegar.
5 CLEAR
10 LET t$="Ejemplo de cursor"
20 CLS
30 BORDER 4
40 GO SUB 460
50 PRINT AT 0,INT ((32-LEN t$)/2); INK 2;t$
60 FOR y=1 TO 20
70 FOR x=0 TO 31
80 LET co=INT (RND*8)
90 IF co=2 THEN GO TO 80
100 LET ff=INT (RND*10)
110 LET f=0
120 IF ff>8 THEN LET f=1
130 LET p=INT (RND*8)
140 IF p=2 THEN GO TO 130
150 PRINT AT y,x; INK co; FLASH f; PAPER p;CHR$ (65+(1+(RND*60)))
160 NEXT x
170 NEXT y
180 LET x=0: LET y=1: LET xant=x: LET yant=y: LET z$= SCREEN$ (y,x): LET z=ATTR (y,x): PRINT AT y,x; OVER 1; FLASH 1; INK 2; BRIGHT 1;"\::"
190 PRINT AT 21,0; INK 0;"u(";CHR$ 144;"),d(";CHR$ 145;"),l(";CHR$ 146;"),r(";CHR$ 147;") o q"
200 LET i$=INKEY$
210 IF i$="q" THEN GO TO 420
220 IF i$<>"l" AND i$<>"r" AND i$<>"u" AND i$<>"d" THEN GO TO 200
230 LET xant=x: LET yant=y
240 IF i$="l" THEN IF x>=1 THEN LET x=x-1
250 IF i$="r" THEN IF x<31 THEN LET x=x+1
260 IF i$="u" THEN IF y>1 THEN LET y=y-1
270 IF i$="d" THEN IF y<20 THEN LET y=y+1
280 GO SUB 300
290 GO TO 200
300 LET f=0
310 IF z>128 THEN LET f=1: LET z=z-128
320 LET b=0
330 IF z>64 THEN LET b=1: LET z=z-64
340 LET p=INT (z/8)
350 LET co=z-(p*8)
360 PRINT AT yant,xant; OVER 0; FLASH f; INK co; BRIGHT b; PAPER p;z$
370 LET z$= SCREEN$ (y,x)
380 LET z=ATTR (y,x)
390 PRINT AT y,x; OVER 1; FLASH 1; INK 2; BRIGHT 1;"\::"
400 PRINT AT 0,26;" ": PRINT AT 0,26;y;" ";x
410 RETURN
420 CLS : CLEAR : BORDER 7: PRINT AT 0,0; INK 0;"Adios"
430 STOP
440 DATA 0,24,60,126,126,24,24,0,0,24,24,126,126,60,24,0
450 DATA 0,16,48,126,126,48,16,0,0,8,12,126,126,12,8,0
460 RESTORE 440
470 FOR i=0 TO 15
480 READ a
490 IF i<=7 THEN POKE USR "a"+i,a
500 IF i>7 THEN POKE USR "b"+(i-8),a
510 NEXT i
520 RESTORE 450
530 FOR i=0 TO 15
540 READ a
550 IF i<=7 THEN POKE USR "c"+i,a
560 IF i>7 THEN POKE USR "d"+(i-8),a
570 NEXT i
580 RETURN
Una de las funciones más útiles que tiene el BASIC de nuestro ZX Spectrum es SCREEN$.
Gracias a esta función podemos saber que carácter se encuentra presente en la pantalla, dadas las coordenadas X e Y.
En el modo de "texto" tenemos 22 líneas (Y) y 32 columnas (X). Es muy cómodo, utilizar SCREEN$ como mecanismo de detección de colisiones en un juego en el que hallamos usado caracteres (de 8x8) como gráficos.
Como se puede ver en !Como me gustan los UDG! es muy sencillo usar los 20 caracteres de gráficos de usuario que nos facilita el Spectrum, para hacer nuestros propios sprites de 8x8.
Los podemos usar en pantalla, y todo bien, hasta que se nos ocurre la brillante idea de usar SCREEN$ para obtenerlos de pantalla. SCREEN$ nos devolverá un vacío, dado que no es capaz de gestionar los UDG. Nuestro gozo en un pozo.
He aquí unas cuantas líneas de código para tener nuestro propio "SCREEN$" y poder identificar los UDG en pantalla.
La idea es la misma, le damos unas coordenadas de linea/columna, y el código nos devuelve el código UDG al cual pertenece. Si la variable de control (res) es un cero (0) es que el carácter que se encuentra en las coordenadas proporcionadas, no es un UDG. Si la variable de control res tiene un valor igual o superior a 144, nos está devolviendo el código del UDG que ha encontrado en esas coordenadas.
10 REM Localizacion de UDG por coordenadas x,y 20 REM igual que el SCREEN$(y,x) pero funciona con UDG 30 REM vamos a cargar el UDG 149 (f) 40 FOR i=0 TO 7 50 POKE USR "f"+i,255 60 NEXT i 70 PRINT AT 7,13;CHR$ 149 80 REM le damos las coordenadas y res nos devuelve el UDG 90 LET x=13: LET y=7 100 GO SUB 260 110 PRINT AT 0,0;"El UDG es el ";res 120 GO TO 310 130 LET res=udg 140 LET vY=y*8 150 LET vX=x 160 FOR S=0 TO 7 170 LET iY=vY+S 180 LET BLOCK=INT (iY/64) 190 LET CROW=INT (iY/8) 200 LET YR=iY-(CROW*8) 210 LET CROW=CROW-(BLOCK*8) 220 LET ADD=16384+BLOCK*2048+CROW*32+YR*256 230 IF (PEEK ((USR (CHR$ udg))+s))<>(PEEK (add+vX)) THEN LET res=0: RETURN 240 NEXT S 250 RETURN 260 FOR i=144 TO 164 270 LET udg=i 280 GO SUB 130 290 IF res>=144 THEN RETURN 300 NEXT i 310 STOP
Hay varias cosas que tener en cuenta:
Las coornedas linea/columa las fijamos igual que en el SCREEN$. Ya se encarga el cógido de las "visicitudes" y "saltos" de las direcciones de memoria en pantalla.
Está optimizado para UDG's de 8x8. Con un poco de paciencia y coco, se puede adaptar a 16x16, o 32x32 de forma sencilla.
Me puse como objetivo encontrar un entorno de programación gráfico al estilo de BasinC para ZX Spectrum.
La idea es tener una GUI (Graphical User Inerface) con todas las herramientas necesarias para la programación BASIC del Commodore 64 en nuestro PC. No solamente código fuente, sino herramientas gráficas y de sprites, manuales y otro tipo de complementos que nos permitan hacer todo desde un mismo sitio.
De las varias opciones con las que me he peleado (literal), os propongo como otra opción muy válida para pasar vuestros desarrollos BASIC a código máquina, el compilador "HiSoft BASIC" de Cameron Hayne y publicado en 1986 por HiSoft.
Este compilador soporta los modelos ZX Spectrum, ZX Spectrum +, ZX Spectrum 128 y ZX Spectrum Plus 2.
Para usarlo en los ZX Spectrum +2A/B/3 deberéis usar el modo 48k. El cargador de 128 utiliza comandos CAT y nomenclatura de archivos que los 2A/B no entienden.
En las versiones de 128k soportadas, solo ocupa 500 bytes de RAM de usuario, por lo que nos deja hasta 40k para nuestro programa BASIC.
Estoy trabajando en una versión que cargue en los modelos +2A/B, dado que no hay una versión en cinta para ellos. Si hay una versión en disco para la el ZX Spectrum +3.
Hay otra versión depurada por Zeljko Juric también disponible.
En general es un compilador muy robusto. Tiene varias particularidades muy buenas, como la de poder "mezclar" código máquina de una compilación con otra (al estilo de librerías o módulos) además de soportar básicamente todos los comandos de BASIC, incluyendo matrices de hasta 2 niveles (A(x,y)). Puedes definir renglones / áreas de compilación a Mcode y dejar bloques de BASIC libres. Esto es muy útil para los comandos no soportados desde el compilado. También es posible compilar por separado los segmentos DATA grandes que tengamos y "pegarlos" al código máquina principal del programa.
Los comandos no soportados, los podemos usar directamente con BASIC, yendo y viniendo del código máquina.
La cinta viene con dos caras. Cara A para el 48k y cara B para los 128k soportados.
Hay un montón de ejemplos en la cinta y el manual de uso está muy bien; explica todo con detalle, da ejemplos y tiene un capítulo dedicado a tips para mejorar el rendimiento del código máquina generado por el compilador.
Otra funcionalidad muy curiosa, es la posibilidad de investigar las variables de nuestro programa, con el comando *T.
El propio compilador propone fijar un tipo de datos para la(s) variable(s) (con una directiva especial en una linea REM) , y así obtener un compilado aún más rápido y pequeño.
Soporta funciones de usuario, GOTO/GOSUB calculados, operaciones de floating point y otra gran cantidad de cosas.
El compilado contiene todo lo necesario para que el programa sea independiente (todos los run-time necesarios).
En las pruebas realizadas hasta ahora, con proyectos que tengo en curso, el resultado (y la estabilidad) ha sido mejor que el obtenido con el compilador Softket "FP" Full Compiler.
Tanto en Jugando a los Sprites episodio I como en Jugando a los Sprites episodio II vemos visto las carencias y dificultades de trabajar con los gráficos en sprites desde BASIC y hemos definido un par de trucos / mecanismos para mejorar tanto el rendimiento como el uso de dichos sprites.
Las técnicas descritas en el episodio I y en el episodio II son válidas para hacer bastantes cosas. Todo dependerá de la complejidad del proyecto en el que nos embarquemos.
Por suerte, la compañía Oasis Software en el año 1986 sacó al mercado una extensión del BASIC llamada Laser Basic enfocada completamente a la programación con gráficos y sprites desde BASIC.
Resumiendo mucho las capacidades de esta extensión de BASIC, podemos decir que:
Gestiona hasta 256 sprites de cualquier tamaño.
Se pueden definir ventanas de pantalla y operar con ellas.
Se pueden realizar movimientos en pantalla tanto de los sprites como de las zonas definidas como ventanas, junto con sus atributos de pixeles, de forma muy sencilla.
Animaciones
Optimizaciones para que el rendimiento sea bueno.
Editor de Sprites avanzado.
Gestión de colisión de sprites en pantalla.
Toolkit para el BASIC.
Definición de procedimientos / funciones complejas.
Es decir, que nos brinda todo lo necesario para desarrollar "en serio" aplicaciones y juegos, con una calidad gráfica alta.
Claro, necesitamos cargado en memoria del Spectrum, el código máquina del Laser Basic para que todo funcione.
¿Es esto un problema?.
Pues no, dado que tenemos el Laser Compiler que nos permite pasar nuestros desarrollos a código máquina, añadiendo todo lo necesario del Laser Basic para que el aplicativo sea completamente independiente y distribuirle..
¿Conclusión?.
Porque reinventar la rueda, cuando Laser Basic y Laser Compiler nos da (casi) todo lo que necesitamos para embarcarnos, por ejemplo, en el desarrollo de juegos usando solo BASIC?.
Y ya para los sibaritas y puristas Oasis Software lo condimentó todo con Laser Genius, un editor ensamblador/Mcode.
He creado un Zip con todo juntito, junto con los manuales,para facilitar las cosas.
En Jugando a los Sprites Episodio I vimos como se pinta un OVNI de 16x16 en pantalla usando escrituras directas a la memoria de vídeo.
Para ello usamos un array con las direcciones de memoria, y una rutina de pintado haciendo POKE. Ambas en su versión "bucle" y en su versión "directa", para obtener un mejor rendimiento.
Bueno, usando UDG's podemos hacer exactamente lo mismo, y el resultado es mucho más rápido al ejecutar. Otra ventaja, es que nos queda un código mucho más pequeño, que eso teniendo solo 48k, siempre se agradece.
Esta vez, pintamos el OVNI directamente en bits.
270 REM *El Ovni en Binario
280 DATA BIN 00000111,BIN 11100000
290 DATA BIN 00001000,BIN 00010000
300 DATA BIN 00010000,BIN 00001000
310 DATA BIN 00100011,BIN 11000100
320 DATA BIN 01000011,BIN 11000010
330 DATA BIN 10000000,BIN 00000001
340 DATA BIN 10000000,BIN 00000001
350 DATA BIN 11111111,BIN 11111111
360 DATA BIN 11111111,BIN 11111111
370 DATA BIN 11111111,BIN 11111111
380 DATA BIN 10000000,BIN 00000001
339 DATA BIN 01000011,BIN 11000010
400 DATA BIN 00100011,BIN 11000100
410 DATA BIN 00010000,BIN 00001000
420 DATA BIN 00001000,BIN 00010000
430 DATA BIN 00000111,BIN 11100000
He aquí los cuatro cuadros de 8x8, que vamos a usar en 4 UDG's, de la A a la D (UDG-A,UDG-B,UDG-C y UDG-D).
Si quitas las instrucciones (DATA y BIN) ves perfectamente el OVNI pintado en 0 y 1.
Lo podíamos haber organizado de otra forma, pero parece natural poner los 4 cuadrantes seguidos, de derecha a izquierda y de arriba a abajo.
Ahora los cargamos en los UDG. Primero los cuadrantes de arriba (A y B) y luego los de abajo (C y D).
160 REM *Cargamos nuestro srpite 16x16
170 RESTORE 280
180 FOR I=0 TO 7
190 READ A: READ B
200 POKE USR "A"+I,A: POKE USR "B"+I,B
210 NEXT I
220 FOR I=0 TO 7
230 READ A: READ B
240 POKE USR "C"+I,A: POKE USR "D"+I,B
250 NEXT I
¡Ya los tenemos listos para usar !.
La rutina que los usa, dadas unas coordenadas X e Y y la posición anterior.
120 REM *Esta es nuestra rutina de dibujo
130 PRINT AT (PY),(PX+1);CHR$ 32:
PRINT AT (PY+1),(Px+1);CHR$ 32: PRINT AT POSY,POSX+1;CHR$ 145: PRINT AT (POSY+1),(POSX+1);CHR$ 147: PRINT AT PY,PX;CHR$ 32: PRINT AT (PY+1),(PX);CHR$ 32: PRINT AT POSY,POSX;CHR$ 144: PRINT AT (POSY+1),POSX;CHR$ 146 140 LET PX=POSX: LET pY=POSY
150 RETURN
Usamos CHR$ 32 para "borrar" (espacio en blanco) y los CHR$ 144,145,146 y 147 correspondientes a UDG-A,UDG-B,UDG-C y UDG-D.
Se borran los dos cuadrantes de la derecha primero (arriba y abajo), se pintan los nuevos en la nueva posición y luego se hace lo mismo con los otros dos cuadrantes. Lo he hecho así, pero se pueden borrar todos primero, o los de la izquierda, o como más nos guste.
El programa esta vez, lo mueve directamente 10 posiciones a la derecha. El rendimiento es bueno y el "parpadeo" lo podemos disimular / ajustar al gusto, cambiando el orden en el cual borramos y volvemos a pintar.
Aunque solo tengamos del UDG-A al UDG-U, y para un sprite de 16x16 gastemos 4, hay maneras de tener muchos más, solo hay que tener imaginación ;).
Podemos guardar en memoria tile-sets y asignarlos a los UDG cuando los queramos usar. Así, no tenemos limitación ninguna.
Esta vez el programa es más corto. De todas formas, puedes descargarlo de aquí o descargarlo en formato TAP.
10 REM *Jugando a los Sprites 2*
15 CLS
20 LET POSX=1
30 LET POSY=1
40 LET PX=1
50 LET PY=1
60 GO SUB 160
70 GO SUB 130
80 INPUT "Vamos a moverlo o salir (q/Q)";z$
90 IF z$="q" OR z$="Q" THEN GO TO 440
100 FOR I=0 TO 10: LET POSX=POSX+1: GO SUB 120: NEXT I
110 GO TO 440
120 REM *Esta es nuestra rutina de dibujo
130 PRINT AT (PY),(PX+1);CHR$ 32: PRINT AT (PY+1),(Px+1);CHR$ 32: PRINT AT POSY,POSX+1;CHR$ 145: PRINT AT (POSY+1),(POSX+1);CHR$ 147: PRINT AT PY,PX;CHR$ 32: PRINT AT (PY+1),(PX);CHR$ 32: PRINT AT POSY,POSX;CHR$ 144: PRINT AT (POSY+1),POSX;CHR$ 146
140 LET PX=POSX: LET pY=POSY
150 RETURN
160 REM *Cargamos nuestro srpite 16x16
170 RESTORE 280
180 FOR I=0 TO 7
190 READ A: READ B
200 POKE USR "A"+I,A: POKE USR "B"+I,B
210 NEXT I
220 FOR I=0 TO 7
230 READ A: READ B
240 POKE USR "C"+I,A: POKE USR "D"+I,B
250 NEXT I
260 RETURN
270 REM *El Ovni en Binario
280 DATA BIN 00000111,BIN 11100000
290 DATA BIN 00001000,BIN 00010000
300 DATA BIN 00010000,BIN 00001000
310 DATA BIN 00100011,BIN 11000100
320 DATA BIN 01000011,BIN 11000010
330 DATA BIN 10000000,BIN 00000001
340 DATA BIN 10000000,BIN 00000001
350 DATA BIN 11111111,BIN 11111111
360 DATA BIN 11111111,BIN 11111111
370 DATA BIN 11111111,BIN 11111111
380 DATA BIN 10000000,BIN 00000001
390 DATA BIN 01000011,BIN 11000010
400 DATA BIN 00100011,BIN 11000100
410 DATA BIN 00010000,BIN 00001000
420 DATA BIN 00001000,BIN 00010000
430 DATA BIN 00000111,BIN 11100000
440 REM *Final del programa
Es sabido que el ZX Spectrum no tiene soporte hardware para gestionar sprites. Sus homónimos como el Commodore 64 y el MSX sí que tienen soporte tanto a nivel de hardware como de BASIC, para los sprites.
Después de haber leído una estupenda publicación de Tero Heikkinen en su blog Old Machinery sobre sprites en el ZX me he animado a aplicar varios de los conceptos que Tero explica, única y exclusivamente al BASIC y añadir un par de cosas mi propia cosecha.
La idea es ejemplificar tanto lo malo como lo bueno que tenemos al tratar de usar / crear sprites en el propio Spectrum, desde BASIC.
Para usar sprites de 8x8 , podemos usar directamente los UDG desde BASIC. Fácil, sencillo de usar y con un rendimiento bueno.
Hay que tener en cuenta que el Spectrum está enfocado a usar caracteres de 8x8, por lo que la ordenación en memoria es un poco extraña. Para no entrar en muchos tecnicismos, vamos a decir que las posiciones en memoria de la pantalla, coinciden con determinadas columnas de pixeles, como se ve en la imagen a continuación:
Para no liarnos mucho, podemos usar un algoritmo que nos de, las 176 posiciones (valores) que nos interesan; lo vemos más adelante.
Bueno, yo quería pintar un OVNI en pantalla, así que haciendo un poco de trampa, usando el editor del BasinC he pintado un OVNI de 16x16.
Luego, lo he exportado en valores decimales al BASIC.
1020 REM *Datos del sprite 16x16 en decimal(4 cuadriculas de 8)
1030 DATA 7,224,7,224,8,16,19,200
1040 DATA 35,196,64,2,159,249,255,255
1050 DATA 255,255,159,249,64,2,35,196
1060 DATA 19,200,8,16,7,224,7,224
Ahora, vamos a hacer el pintado en 2 pasos:
1) Las posiciones de memoria válidas en una variable, para calcularlas o cargarlas una única vez.
2) Asignamos coordenadas X e Y, donde queremos pintar y llamamos al pintado.
Las posiciones de memoria.
En la publicación de Tero, se calcula las posiciones en función ya de unas determinadas coordenadas en pantalla que quiere usar. Yo, simplemente, y por tener luego los valores "fijos", he dejado el cálculo en el programa de ejemplo.
Acordaros que la 1ra posición de memoria para el pintado en pantalla es 16384.
490 REM * Para calcular los valores del POKE
500 FOR Y=0 TO 175
510 LET BLOCK=INT (Y/64)
520 LET CROW=INT (Y/8)
530 LET YR=Y-(CROW*8)
540 LET CROW=CROW-(BLOCK*8)
550 LET ADD=(16384+(BLOCK*2048))+(CROW*32)+(YR*256)
560 LET A(Y+1)=ADD
570 NEXT Y
Este bucle es costoso para el Spectrum. Siendo un poco listos, incluimos en el programa un segmento DATA con los 176 valores, que siempre irá mucho más rápido hacer un READ que el cálculo completo.
1080 REM *Datos de los POKE calcualdos, 176 valores posibles* 1090 DATA 16384,16640,16896,17152,17408,17664,17920,18176,16416,16672,16928,17184,17440,17696 1100 DATA .................
¿ Y por que hacemos esto?. Bueno, porque luego vamos a usar nuestra super rutina de pintado en pantalla, asignando las coordenadas X e Y que queremos y llamándola.
370 PRINT AT 19,1;"Con bucle"
380 FOR I=0 TO 15
390 POKE A(I+(POSY))+(POSX),0: POKE A(I+(POSY))+(POSX)+1,0
400 NEXT I
410 LET PV=POSY+DVER
420 LET PH=POSX+DHOZ
430 FOR I=0 TO 15
440 READ L: READ R
450 POKE A(I+(PV))+(PH),L
460 POKE A(I+(PV))+((PH)+1),R
470 NEXT I
La primera parte de la rutina, "borra" de pantalla lo anterior (la posicion anterior del OVNI). La segunda parte, dadas unas nuevas coordenadas, pinta el OVNI.
Como los bucles son más lentos que las instrucciones directas, y como sabemos que solo son 16 instrucciones (nuestro sprite es de 16x16) podemos sustituir el bucle por instrucciones directas, tratando de ganarle algo al rendimiento.
Es decir, que puedes hacer los 16 POKE en 16 instrucciones diferentes, y ganar algo.
READ L
READ R
POKE A(0+(PV))+(PH),L: POKE A(0+(PV))+((PH)+1),R
READ L
READ R
POKE A(1+(PV))+(PH),L: POKE A(1+(PV))+((PH)+1),R
Así, del 0 al 15.
En el código fuente más abajo, tienes todo.
La verdad, es que el resultado es chulo, pero más lento que el caballo del malo. ¿Como solucionar este problema de rendimiento?. Bueno, yo me he liado la manta a la cabeza y he compilado el código BASIC a código máquina y ahora sí soy un panda FELIZ.
En el episodio II, haremos lo mismo, usando UDG y veremos si nos hace falta código máquina o no ;).
Ah, casi se me olvidaba. Aquí os dejo un fichero TAP con el programa.
