VOLCADO DEL BUFFER CON LA PILA (IV): RUTINA DE VOLCADO II

En esta entrada voy a explicar la subrutina VULVU.
Antes que nada, decir que es una "libre adaptación" de la que usa Mike Lamb en algunos de sus juegos, como Batman: The Movie o WEC Le Mans. Yo la uso en Knightmare 2 ZX.

En el .GIF de abajo puedes ver la forma en la que vuelco el buffer en la pantalla real. Va volcando las líneas de derecha a izquierda y primero vuelca un doce caracteres en horizontal y luego los otros doce.

Volcado del buffer en la pantalla real

Para la explicación, voy a tomar como base que volcamos desde la dirección 8004h del buffer a la 4090h de la pantalla real.

IX va a ser el puntero que lleva las direcciones del buffer, por ello lo cargamos con 8000h (inicio del buffer) + 4 que son los caracteres que dejamos de marco a la izquierda.
HL es el puntero de la pantalla real. Vamos a imprimir a partir del cuarto caracter vertical, dejando un marco de 4 caracteres a la izquierda: 4000h+80h+4=4084h. ¿Por qué lo cargamos con 4090h?, pues porque hay que sumarle 12 (0Ch). 4084h+0Ch=4090h. Ahora entenderás por qué.

  VOLVU LD (STACKV1+1),SP PRIM4 EXX ;VUELCA LOS MITAN PRIMEROS LD SP,IX ;CARACTERES POP HL POP DE ;EN CADA VUELTA, VUELCA CUATRO POP BC ;LINEAS POP AF ;EX AF,AF' EXX ;POP AF POP DE POP BC LD SP,HL PUSH BC PUSH DE PUSH AF INC H EXX ;EX AF,AF' ;PUSH AF PUSH BC PUSH DE PUSH HL DB $DD INC H ;INC IXH

Guardamos SP y lo cargamos con IX que es el inicio del buffer que queremos volcar (8004h).
Salvamos los registros. El que nos interesa es HL que lleva las direcciones de la pantalla real.
Cargamos 6 registros con las primeras 12 direcciones de la primera línea a volcar:

HL'=contenido de las direcciones 8004h,8005h
DE'=contenido de las direcciones 8006h,8007h
BC'=contenido de las direcciones 8008h,8009h
AF= contenido de las direcciones 800Ah,800Bh
DE= contenido de las direcciones 800Ch,800Dh
BC= contenido de las direcciones 800Eh,800Fh

Ahora cargamos SP con HL (SP=4090h) y hacemos PUSH con todos los registros que antes hemos cargado. Ya he comentado que al hacer POP, SP se incrementa, pero al hacer PUSH, primero se decrementa y luego se mete el dato en la dirección donde apunta SP. Por eso hay que sumarle 12 a HL. Al hacer PUSHes, éste se va decrementado. Así que los registros se "PUSHEAN" en orden inverso a como se "POPARON"

El valor de BC se mete en 408Fh,408Eh
El valor de DE se mete en 408Dh,408Ch
El valor de AF se mete en 408Bh,408Ah

En este momento incrementamos H para pasar a la siguiente línea de la pantalla (4190h)
y salvamos los registros.

El valor de BC' se mete en 4089h,4088h
El valor de DE' se mete en 4087h,4086h
El valor de HL' se mete en 4085h,4084h

Como puedes ver, cada byte se ha colocado en su sitio y de la forma como se ve en el .GIF.

Ahora tenemos que pasar a la siguiente línea del buffer, por lo que hay que incrementar el byte alto de IX. Hacer algo así como INC Ix. Este nemónico como tal no existe, pero si ponemos el valor DDh antes de INC H, el Z80 lo interpreta como INC Ix.

Esto lo hacemos cuatro veces para volcar las cuatro primeras líneas.
Después del último volcado miro a ver si hemos llegado a la cuarta línea, con lo que repetimos el proceso, o si hemos acabado con el caracter en curso. Para eso se hace BIT 2,H. Si el resultado es uno, significa que estamos en la línea 4, por lo que repite.

Hemos acabado de imprimir el primer rectángulo de 1 caracter de alto por 12 de ancho.
¿Qué valor tiene IX?: Partíamos de 8004h. Hemos incrementado Ix 8 veces, por lo que IX=8804h.
¿Qué valor queremos que tenga ahora? Queremos que apunte a la posición de inicio (8004h) más los doce caracteres que ya hemos metido, osea 8004h+0Ch=8010h.
La cuenta es sencilla. Restamos 8 a Ix y sumamos 0Ch a iX. Osea, le restamos (800h-0Ch).
Para HL la cuenta es la misma.

RESTA1 EQU $800-MITAN ;$800 ES LO QUE MIDE UN TERCIO DE PANTALLA CUATS LD DE,-RESTA1; ;DESDE DONDE TERMINA IX ADD IX,DE ;HASTA LA POSICION PARA LOS ;SIGUIENTE DOCE CARACTERES ADD HL,DE ;HAY QUE RESTARLE $800-MITAN

Ya podemos volcar los otros 12 caracteres.

¿Cuánto vale ahora IX? Empezó en 8010h y hemos incrementado Ix 8 veces. IX=8810h.
¿Cuánto queremos que valga? Pues queremos que se nos posicione en el siguiente caracter en vertical de donde empezó en un principio. Empezó en 8004h y queremos que valga 8024h.
Podemos restar 8 a Ix, restar 0Ch a iX y sumarle 20h. (800h-20h=7E0h.)
Basta con restar a IX (7E0h+0Ch). 8810h-(7E0h+0Ch)=8024h.

Ya tenemos volcado el primer rectángulo de 1 caracter de alto por 24 de ancho. HL e IX apuntan al inicio del segundo rectángulo... siempre que no se cambie de tercio. Este problema ya se solucinó en la anterior entrada.


Si he conseguido que entiendas esto, no te será muy complicado cambiar el tamaño del buffer que se vuelca. De todas formas he dejado preparada "alguna pista". Si queremos un buffer 4 caracteres más ancho, tenemos que volcar dos caracteres más por vuelta. Para eso hay que usar un registro doble más. Yo he elegido AF'. Si quitas los ";" delante de EX AF,AF' y de los PUSH AF y POP AF volcamos 4 datos más, por lo que el buffer volcado será de 28 caracteres de ancho. Pero recuerda darle a MITAN el valor de 14. Para centrar algo mejor el buffer puedes dar  a CHAR el valor de 2.
Si queremos menos caracteres verticales, tenemos que quitar VOLVUs de nuestra pila "artificial".

Como siempre te digo, experimenta, que es la mejor manera de entender las cosas.

La rutina de restablecimiento del fondo no tiene nada de especial.

VOLCADO DEL BUFFER CON LA PILA (III): RUTINA DE VOLCADO I

Vamos a ir volcando el buffer en la pantalla real en bloques de un caracter de alto por 24 de ancho.
Para que quede centrada en la pantalla dejamos un marco de 4 caracteres a la izquierda.
Estos valores se establecen al principio de CONTENIDA.ASM. Así podrás cambiarlos para hacer tus pruebas sin comerte mucho la cabeza.

MITAN EQU 12 CHAR EQU 4


MITAN es el ancho en caracteres del recuadro que vamos a volcar partido por 2.
CHAR es el número de caracteres que dejamos en blanco.

EL corazón de la rutina es VOLVU que vuelca primero los 12 primeros caracteres y luego los otros 12  desde la dirección que le marca IX (buffer) hasta que le marca HL. Además, retorna con la dirección del siguiente caracter tanto en IX como en HL. Pero no comprueba si cambiamos de tercio, por lo que tendremos que comprobarlo nosotros "a mano".

Por esto es por lo que hay que llamar a VOLVU varias veces (tantas como caracteres verticales tenga el trozo de buffer que queremos imprimir). Esto supondría realizar 16 CALL VOLVU. Nosotros vamos a utilizar otro método:  construimos una "pila artificial" donde ponemos a qué dirección tiene que saltar cada vez que se ejecute un RET (en concreto con el que termina VOLVU).

Esta es nuestra pila:

STACCR DW VOLVU,VOLVU,VOLVU,VOLT,VOLVU,VOLVU,VOLVU, VOLT1,VOLVU,VOLVU,VOLVU,VOLTF,VOLVU,VOLVU,VOLVU,STACKV

Si hacemos LD SP,STACCR cuando se ejecuten los RETs, saltará a la dirección que indique SP:

RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLT
RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLT1
RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLVU
RET: salta a VOLTF
etc...
RET: salta a STACV que es el final de la rutina.
De esta manera nos ahorramos las llamadas.

VOLCADO LD SP,STACCR LD HL,$4080+CHAR+MITAN ;INICIO MAS MARCO IZQUIERDO PANT. REAL ;MAS MITAD DE LAS COLUMNAS DEL BUFFER LD IX,$8000+CHAR ;INICIO BUFFER MAS EL MARCO IZDO. JP VOLVU ;;CADA VEZ QUE SALTA A VOLVU VUELCA PRIMERO MITAN CARACTERES ;;DE LA IZQUIERDA Y LUEGO LOS OTROS MITAN ;;AL LLEGAR AL RET, SIGUE DONDE LE MARCA LA PILA ;;DESPUES DE CUATRO CARACTERES EN VERTICAL HAY QUE PONER HL AL ;;PRINCIPIO DEL SIGUIENTE TERCIO PERO QUEDAN 4 CARACTERES ;;PARA QUE IX CAMBIE DE TERCIO, POR LO QUE IX NO SE TOCA VOLT LD HL,$4800+CHAR+MITAN JP VOLVU ;;DESPUES DE CUATRO CARACTERES EN VERTICAL HAY QUE PONER IX AL ;;PRINCIPIO DEL SIGUIENTE TERCIO PERO QUEDAN 4 CARACTERES ;;PARA QUE HL CAMBIE DE TERCIO, POR LO QUE HL NO SE TOCA VOLT1 LD IX,$8800+CHAR JP VOLVU ;;DESPUES DE CUATRO CARACTERES EN VERTICAL HAY QUE PONER HL AL ;;PRINCIPIO DEL SIGUIENTE TERCIO PERO QUEDAN 4 CARACTERES ;;PARA QUE IX CAMBIE DE TERCIO, POR LO QUE IX NO SE TOCA VOLTF LD HL,$5000+CHAR+MITAN

Pues lo dicho, ponemos SP apuntando a STACCR (nuestra pila artificial).
HL va a llevar las direcciones de la pantalla real donde se va a volcar nuestro rectángulo e IX lleva las direcciones del buffer desde donde se vuelcan.
Los datos  se van cogiendo del buffer con POP (al hacer POP se coge el dato de la pila y ésta se incrementa) y se van metiendo en la pantalla real con PUSH (al hacer PUSH, se decrementa primero la pila y luego se mete el dato).

Por eso IX se carga con $8000+CHAR: inicio del buffer más el marco de 4 caracteres a la izquierda.
HL se carga con $4080+CHAR+MITAN: vamos a volcar a partir del 4 caracter horizontal (dirección $4080) más el marco (CHAR) más los doce primeros caracteres  horizontales a volcar. Ya he comentado que al hacer PUSH la pila se va decrementando, por eso a HL se le suma MITAN.

Comenté que VOLVU vuelca un rectángulo de un caracter de alto por 24 de ancho desde IX hasta HL y devuelve IX y HL con el valor para el siguiente caracter. Osea, que si cambiamos de tercio no vale.

Si te das cuenta, HL empieza en el cuarto caracter vertical. Podemos llamar a VOLVU cuatro veces hasta que llegue al cambio de tercio. Así que hacemos JP VOLVU (1 vez) y en nuestro stack tenemos VOLVU (2 veces),VOLVU (3 veces),VOLVU (4 veces) y VOLT.
En VOLT cargamos HL con la dirección del principio del segundo tercio $4800 más el marco más MITAN.

Pero los caracteres verticales también van pasando para el buffer. Empezó en $8000. Cuando VOLT se haya ejecutado 8 veces tenemos que cambiar de tercio a mano.
Hasta ahora VOLVU se ha ejecutado 5 veces (VOLT también salta a ella), así que en nuestro stack hemos puesto VOLVU (6 veces),VOLVU (7 veces),VOLVU (8 veces) y VOLT1.
En VOLT1 cargamos IX con el inicio del segundo tercio del buffer $8800 más el marco y saltamos otra vez a VOLVU. Despúes de cuatro VOLVUs tenemos que actualizar HL con la dirección del tercer tercio de la pantalla más el marco más MITAN.

Si quisiéramos posicionar el volcado del buffer en la pantalla real en otra dirección, por ejemplo a partir del segundo caracter vertical ($4040+CHAR+MITAN) deberíamos cambiar nuestra pila artificial. Si has entendido esto, deberías ser capaz de hacerlo.

VOLCADO DEL BUFFER CON LA PILA (II): GUARDANDO EL FONDO

Este programa es idéntico al VOLCADO DEL BUFFER CON LDI en lo concerniente al control de enemigos y prota. Pero cambia sustancialmente a la hora del guardado de fondo, impresión de sprites, volcado y restauración del fondo.

;;;;;;;;GUARDAMOS EL FONDO DE TODOS LOS SPRITES A IMPRIMIR;;;;; LD IY,DATFON-6 ;PUNTERO PARA GUARDAR LOS DATOS DE LOS CACHOS ;DE PANTALLA DONDE VA A IR EL SPRITE ;;PARA CADA SPRITE SE GUARDAN 6 DATOS ;0=ALTURA/2, 1=ANCHURA, 2,3=DIR BUFFER PANTALLA, 4,5=DONDE SE GUARDA ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; LD (STACKV+1),SP ;GUARDO EL STACK LD DE,FONDOS ;A PARTIR DE FONDOS SE GUARDAN LOS FONDOS DONDE LD (GFONDI+1),DE ;VA A IR EL SPRITE LD SP,SPIMP ;INICIO DE LA COLA DONDE SE METEN LAS TABLAS ;DE LOS SPRITES A IMPRIMIR CSPIM LD A,0 ;NUMERO DE SPRITES QUE HAY QUE IMPRIMIR LD (CSPIMR+1),A ;SE ACTUALIZA EN METEIMPS LD B,A PINTSR EXX POP IX ;COJO EL DATO DE LA COLA DE IMPRESION DE SPRITES LD DE,6 ADD IY,DE ;ACTUALIZAMOS IY LD L,(IX+0) ;COORD Y LD H,$F9 ;COGE EL DATO DE LA DIRECCION DEL BUFFER DE LA TABLA LD D,(HL) ;DE TIENE LA DIRECCION DE LA LINEA PARA IMPRIMIR LD A,(IX+1) ;DIVIDE LA COORDENADA X POR 8 SRL A SRL A SRL A DEC H ADD A,(HL) ;LO SUMA AL BYTE BAJO DE LA DIRECCION LD E,A JP NC, NOCA INC D NOCA LD (DIRPBUF+1),DE ;DE=DIRECCION DEL BUFFER DONDE VA EL SPRITE ;SE METE EN LA RUTINA ;PARA NO VOLVER A HALLARLO GF1 EX DE,HL LD (IY+2),L ;LO METEMOS EN SU TABLA LD (IY+3),H LD C,(IX+2) ;ANCHO DEL SPRITE LD A,(IX+1) ;SI LA COORDENADA Y ES DIVIDIBLE POR OCHO AND 7 ;OCUPA LA ANCHURA, SI NO LO ES, HAY QUE INCREMENTARLA JP Z, NOINC ;YA QUE OCUPA UN CARACTER MAS INC C NOINC LD A,C LD (IY+1),A ;LO METEMOS EN SU TABLA LD (GF6+1),A ;SE METE EN LA RUTINA LD (GF3+1),A DEC A ;PARA NO VOLVER A HALLARLO LD (SUMLDR+1),A ADD A,2 LD (SUMLDD+1),A

Esta primera parte de la rutina es muy parecida. Vamos metiendo los datos que necesitamos en la tabla de recuperación del sprite, calculamos la dirección del buffer donde  lo imprimimos y colocamos los valores que vamos a utilizar. Sólo cambia que el contador de sprites a imprimir va a ser el registro B, ya que el A se va a usar para hallar la dirección de pantalla inferior a una dada.





GFONDI LD DE,FONDOS ;DONDE SE GUARDA EL FONDO DEL BUFFER DONDE VA EL SPRITE LD A,96 ;LO QUE PUEDE OCUPAR COMO MAXIMO EL FONDO DE UN SPRITE DE 2X2 ADD A,E ;4*3*8 SI EL TAMAÑO MAXIMO POR SPRITE ES 3X3 JP NC, NOPASB ;SI E+48>255, SE INCREMENTA D Y E=0 LD E,0 ;PARA QUE NO SE PASE DE BYTE INC D NOPASB LD (IY+4),E ;LO METEMOS EN SU TABLA LD (IY+5),D LD A,(IX+3) ;ALTURA/2 LD (IY+0),A ;LO METEMOS EN SU TABLA

Con este código nos aseguramos de que después de sumar el ancho a la dirección donde se va guardando el trozo de buffer, (SUMLDR y SUMLDD), E no pase de FFh.  En esta rutina el tamaño máximo de los sprites lo he fijado en 3x3. El trozo a guardar puede ser 3x4, por lo que el tamaño máximo en bytes a guardar será de 3X4X8=96 bytes. Si al sumar la dirección donde voy a guardar el cacho más 96 tiene acarreo, significa que E ha pasado de 255. Así que lo ponemos a 0 e incrementamos D.

LD B,0 GF5 EX AF,AF' GF6 LD C,0 ;ESTE DATO SE METE MAS ARRIBA GF2 LDI JP PE, GF2 ;REPITE HASTA QUE BC=0 DEC L INC H SUMLDR LD A,0 ;SE METE ARRIBA ADD A,E LD E,A ;SE SUMA EL ANCHO PARA HACER EL LDD GF3 LD C,0 ;ESTE DATO SE METE MAS ARRIBA GF4 LDD ;REPITE HASTA QUE BC=0 JP PE, GF4 INC L SUMLDD LD A,0 ;SE METE ARRIBA ADD A,E LD E,A ;SE SUMA EL ANCHO PARA HACER EL LDI INC H ;SI DESPUES DE INCREMENTAR H, ESTE NO ES MULTIPLO LD A,H ;DE 8, ENTONCES PERTENECE AL MISMO CARACTER Y SOLO AND 00000111B ;HAY QUE INCREMENTAR H JP NZ, GF15 LD A,L ;SUMAMOS 32 A L ADD A,32 LD L,A JP C, GF15 ;SI ES MAYOR QUE 256, ENTONCES CAMBIA DE TERCIO LD A,H ;SI NO CAMBIA DE TERCIO, TENEMOS QUE RESTAR 8 A H SUB 8 LD H,A GF15 EX AF,AF' DEC A JP NZ, GF5 POSGU LD (GFONDI+1),DE ;ACTUALIZAMOS GFONDI PARA QUE EL FONDO DEL ;SIGUIENTE SPRITE LO GUARDE SEGUIDO.


En esta rutina de guardado, va haciendo LDI para guardar el fondo. Al final tiene que decrementar L ya que con el último LDI se ha incrementado de más. Por eso, no podemos usar todo el ancho de la pantalla, ya que hay zonas en las que el LDI ha hecho que HL pase de 40FFh a 4100h.(por ejemplo). Si decrementamos sólo L, nos daría 41FFh y lo correcto sería 40FFh.

Incrementamos H para pasar a la siguiente línea del buffer. Como la coordenada es par, sabemos que no va a cambiar ni de caracter ni de tercio.
Sumamos a DE el ancho ya que ahora vamos a guardar de decrecha a izquierda con LDD. Incrementamos L ya que el último LDD nos lo ha decrementado de más y se vuelve a sumar el ancho a DE para volver a guardar de izquierda a derecha.

Ahora sí que tenemos que comprobar si al pasar a la siguiente línea cambia de caracter o de tercio.
Se repite el bucle y cuando se guarda todo el fondo del sprite se actualiza GFONDI+1 para el siguiente.

En cuanto a la rutina de impresión de sprites es muy parecida a la que uso en el VOLCADO DEL BUFFER CON LDI. Simplemente cambia el método de hallar la dirección de la línea inferior a una dada, ya que aquí estamos usando la estructura real de la pantalla.

VOLCADO DEL BUFFER CON LA PILA (I)

En esta serie de entradas voy a explicar otra forma de usar un buffer de impresión. Es bastante más rápido que el anterior, y a mi modo de ver más elegante, si bien ocupa algo más de memoria.

Te puede bajar el código de AQUI:
He metido un fondo más aparente.

Este buffer que vamos a usar copia literalmente la estructura de la pantalla del spectrum. No es como en las entradas anteriores, que lo creábamos a nuestra conveniencia. En este caso, todas las operaciones a realizar serán las mismas que si estuviéramos imprimiendo directamente en la pantalla. Por ello, es muy importante que entiendas la estructuración de la misma
Parece muy enrevesada para nuestra mente decimal, pero si piensas en Hexadecimal, tiene toda su lógica.
Ya comenté que viene muy bien explicado en el curso de Romero. Por favor, échalo un vistazo, ya que si no dominas cómo funciona el asunto, estas entradas se te pueden hacer un poco duras.

De todas formas, voy a dar un repaso rápido, que nunca viene mal.

La pantalla del Spectrum tiene 192 líneas.
Está dividida en tres tercios de 24 líneas.
Cada tercio está dividido en 8 caracteres.
Cada caracter está dividido en 8 líneas.
Cada línea mide 32 caracteres de ancho.
La pantalla empieza en la dirección 4000h y termina en la 57ffh.


Los tres tercios tienen la misma estructura, por lo que nos fijaremos sólo en uno.

Seguro que has visto cargar una pantalla en el spectrum muchas veces, y no lo hace de forma secuencial.

Carga las 32 direcciones de memoria de la primera línea, y la siguiente dirección es la primera línea del segundo caracter. Carga las 32 direcciones y la siguiente será la primera línea del tercer caracter... Así hasta que ha cargado las 32 direcciones de memoria de la primera línea del octavo caracter, que es el último del primer tercio.

Las siguiente dirección será la segunda línea del primer caracter y todo vuelve a empezar pero esta vez con las segundas líneas de cada caracter. Así hasta que carga el tercio.

Si estamos en la primera dirección de la primera línea del primer caracter (4000h) y queremos pasar a la dirección que está inmediatamente debajo de ésta (primera dirección de la segunda línea del primer caracter), ¿qué debemos hacer? He dicho antes que después de la dirección 32 de la primera línea del octavo caracter se pasa a la dirección 0 de la segunda línea del primer caracter. Osea que hemos avanzado 8 líneas*32 direcciones por línea=256 (100h) direcciones.  Sumamos 4000h+100h=4100h.
Osea, si el registro HL=4000h, nos basta con INC H y tendremos HL=4100h.

Para hallar la segunda línea, incrementamos H otra vez, y así con todas las líneas del caracter.
El problema es que si estamos en la última (4700h) e incrementamos H, nos da HL=4800h como dirección de la primera línea del segundo caracter. Y eso no es así. La primera línea del segundo caracter, como hemos visto, es 4000h+32 direcciones de memoria que ocupa la primera línea, o lo que es lo mismo en hexadecimal 4020h.

Esto nos supone ir comprobando cada vez que incrementemos H para pasar de línea, si nos hemos pasado al siguiente caracter. Esto se hace viendo si H es múltiplo de 8. Si lo hemos hecho, basta con restar 8 a H, y sumarle 20h a L.
48h-8=40h. 00h+20h=20h. Total que HL=4020h. Ya tenemos la dirección que buscábamos.

Así podemos hallar la dirección que está debajo de una dada dentro de un tercio, pero ¿qué pasa si nos pasamos de tercio? Con nuestro método, cuando estemos en el octavo caracter del primer tercio y en su última línea estaremos en la dirección 48E0h, H es múltiplo de 8, por lo que nos hemos pasado de caracter. Hacemos 48h-8=40h. E0h+20h=00. HL=4000h. Nos vuelve a la primera línea del primer caracter. Para cambiar de tercio basta sumarle 20h a L, sin restar 8 a H.
E0h+20h=00. HL=4800h, que es la primera dirección de la primera línea del segundo tercio.
4800h-4000h=800h. 800h no es otra cosa que lo que nos ocupa un tercio entero.

¿Cómo sabemos si al incrementar H nos hemos pasado de tercio además de caracter?
Pues porque al sumar 20h a L, nos va dando esto:

4700h     última línea primer caracter
4720h     última línea segundo caracter
4740h     última línea tercero caracter
4760h     última línea cuarto caracter
4780h     última línea quinro caracter
47A0h    última línea sexto caracter
47C0h    última línea séptimo caracter
47E0h    última línea octavo caracter

HL=47E0h. INC H para cambiar de línea. HL=48E0h. H es múltiplo de 8, por lo que hay que cambiar de caracter. Sumo 20h a L. HL=4800. Si te das cuenta L vuelve a ser igual a cero, por lo que en la operación de la suma ha habido acarreo (FLAG C=1). Esto significa que se nos ha acabado el tercio y no tenemos que restar 8 a H.

Todo esto lo hace la rutina SIGLIN de CONTENIDA.ASM, que ya medio expliqué, pero que seguro que ahora la entiendes perfectamente.

;;;ESTA RUTINA NOS CALCULA LA DIRECCION DE PANTALLA INMEDIATAMENTE ;;;INFERIOR A UNA DADA EN HL SIGLIN INC H ;SI DESPUES DE INCREMENTAR H, ESTE NO ES MULTIPLO LD A,H ;DE 8, ENTONCES PERTENECE AL MISMO CARACTER Y SOLO AND 00000111B ;HAY QUE INCREMENTAR H RET NZ LD A,L ;SUMAMOS 32 A L PARA PASAR A LA LINEA SIGUIENTE ADD A,32 LD L,A RET C ;SI ES MAYOR QUE 256, ENTONCES CAMBIA DE TERCIO LD A,H ;SI NO CAMBIA DE TERCIO, TENEMOS QUE RESTAR 8 A H SUB 8 LD H,A RET



Como puedes ver, pensando en Hexadecimal, la distribución de la pantalla no es tan "rara" como parece.

En esta rutina se va a usar todo este planteamiento constantemente.

Como ya sabes, guardo los sprites en zigzag, así cuando termino de imprimir el último caracter del sprite, me basta con hallar la dirección que está debajo y volver de a imprimir de derecha a izquierda.

Esta rutina tiene alguna limitación. La coordenada Y tiene que ser siempre par. Esto es por lo siguiente: Sólo va a haber cambio de caracter al hallar la dirección que está debajo de una dada cuando la coordenada de partida sea impar (condición necesaria pero no suficiente). Si nuestra coordenada es siempre par, nos ahorramos una comprobación de cambio de caracter, ya que sabemos que nos basta con incrementar H para cambiar de línea.

Por la distribución de la pantalla, para pasar de una dirección a la contigua cuando imprimamos el sprite, sabemos que L nunca va a ser FFh ni 0. Por ello, todos estos incrementos y decrementos se pueden hacer con INC/DEC L en vez de con INC/DEC HL, con lo que ganamos mucha velocidad.
El problema de usar INC/DEC L cuando lo que queremos es INC/DEC HL ya lo hemos visto. Tenemos que estar seguros de que L nunca sea FFh al incrementar ni 0 al decrementar ya que éste pasaría a ser 0/FFh y H se quedaría con el mismo valor.

Esta ganancia en velocidad no es oro todo lo que reluce. En realidad, L sí que va a ser 0 o FFh, pero sólo en determinados puntos de los bordes de la pantalla. Por eso, la coordenada X nunca puede ser menor que 8 ni mayor que 248.
En este ejemplo volcamos 16 caracteres de alto por 24 de ancho.

Todo esto se verá  con el examen de la rutina.

Intenta comprender todo esto muy bien.

VOLCADO DEL BUFFER CON LDI ( Y VIII): VOLCADO DEL BUFFER Y RESTAURACIÓN DEL FONDO

Esta rutina es muy sencilla: simplemente cogemos cada línea del buffer y la volcamos a la pantalla real con tantos LDIs como ancho es el buffer (ANPAN).

Lo único que tenemos que saber es la dirección de la pantalla real que se corresponde con el primer carácter de cada línea.
Para eso, en CONTENIDA.ASM creamos otra tabla:

;;;;;CREA LA TABLA DE COORDENADAS PARA LA RUTINA DE VOLCADO LD IX,TVOLCADO ;PARA VOLCAR MAS RAPIDO EL BUFFER ;CREO UNA TABLA CON LA DIRECCION LD HL,DIRPAN ;DE LA PANTALLA REAL DEL INICIO DE CADA LINEA LD B,ALPANA LINEL1 LD (IX+0),L LD (IX+1),H CALL SIGLIN INC IX INC IX DJNZ LINEL1

Cargo IX con el incio de la tabla.
HL con la dirección de la pantalla real que corresponde con la coordenada (0,0), osea, con la esquina superior izquierda del cuadro donde voy a volcar el buffer.
B con el número de líneas.
En el bucle voy metiendo las direcciones en la tabla.
En SIGLIN hallo la dirección inmediatamente inferior a una dada en la pantalla real:

;;;ESTA RUTINA NOS CALCULA LA DIRECCION DE PANTALLA INMEDIATAMENTE ;;;INFERIOR A UNA DADA EN HL SIGLIN INC H ;SI DESPUES DE INCREMENTAR H, ESTE NO ES MULTIPLO LD A,H ;DE 8, ENTONCES PERTENECE AL MISMO CARACTER Y SOLO AND 00000111B ;HAY QUE INCREMENTAR H RET NZ LD A,L ;SUMAMOS 32 A L ADD A,32 LD L,A RET C ;SI ES MAYOR QUE 256, ENTONCES CAMBIA DE TERCIO LD A,H ;SI NO CAMBIA DE TERCIO, TENEMOS QUE RESTAR 8 A H SUB 8 LD H,A RET

Si no estás familiarizado con la estructura de la pantalla del Spectrum, te recomiendo que eches un vistazo aquí.

Ahora vemos la rutina de volcado:

LD SP,TVOLCADO ;APUNTO EL STACK A LA TABLA DE VOLCADO LD BC,TAMPAN ;DONDE VIENE LAS PRIMERAS DIRECCIONES DE LD HL,PANTVIR ;CADA LINEA EN LA PANTALLA REAL BUCV POP DE ;DE=PRIMERA DIRECCION DE LA LINEA REPT ANPAN ;HAGO TANTOS LDI COMO ANCHO ES EL BUFFER LDI ENDM JP PE, BUCV ;REPITE HASTA QUE BC=0

Cargamos SP con la tabla.
BC con el tamaño del buffer.
HL con el inicio del buffer.
Al hacer POP DE, DE tiene la dirección de la primera línea donde vamos a volcar.
REPT y ENDM no son nemónicos del Z80. Es una forma de crear un bucle en PASMO: repite la instrucción LDI ANPAN veces. Osea, ensambla ANPAN LDIs, que es la anchura del buffer.
Como ya hemos visto, se ejecuta JP PE hasta que BC=0 (tamaño del buffer).

No tiene más misterio.


RECUPERACION DEL FONDO DEL BUFFER

Este es el último paso de nuestra rutina. Vamos a ir restaurando los trozos de fondo del buffer donde hemos imprimido un sprite. Para eso usamos las tablas que hemos ido creando al guardar los cachos. Esta recuperación hay que hacerla en orden inverso a como se guardaron. Y precisamente, IY apunta a la tabla del último cacho.

;;;;;RESTAURAMOS EL FONDO;;;;; ;IY ES EL PUNTERO DE LA TABLA PARA RESTAURAR EL FONDO Y APUNTA ;A LA TABLA DE RESTAURACION DEL ULTIMO SPRITE QUE SE IMPRIMIO ;LOS FONDOS HAY QUE RESTAURARLOS EN ORDEN INVERSO A COMO SE GUARDARON CSPIMR LD A,0 ;NUMERO DE SPRITES GFR10 EX AF,AF' LD E,(IY+2) ;DONDE HAY QUE RESTAURAR DEL BUFFER LD D,(IY+3) LD L,(IY+4) ;DONDE ESTA GUARDADO LD H,(IY+5) LD A,(IY+1) ;ANCHO DEL SPRITE LD (GF6R+1),A LD (GF3R+1),A NEG ;HALLAMOS LO QUE HAY QUE SUMAR A HL PARA PASAR ADD A,ANPAN ;A LA LINEA SIGUIENTE (ANPAN-ANCHO) A RECUPERAR LD (RECU+1),A LD (RECU1+1),A LD B,0 ;REPITE C VECES Y B=0 LD A,(IY+0) ;ALTURA/2 DEL SPRITE GF5R GF6R LD C,0 GF2R LDI JP PE, GF2R ;REPITE BC VECES (ANCHO GUARDADO) EX DE,HL RECU LD C,0 ;SIGUIENTE LINEA ADD HL,BC EX DE,HL GF3R LD C,0 GF4R LDI JP PE, GF4R EX DE,HL RECU1 LD C,0 ADD HL,BC EX DE,HL DEC A JP NZ, GF5R ;LO HACE (ALTURA/2 DEL SPRITE) VECES LD DE,-6 ;SIGUIENTE TABLA DE RESTAURACION ADD IY,DE EX AF,AF' ;LO HACEMOS CON CUANTOS SPRITES HEMOS IMPRIMIDO DEC A JP NZ, GFR10 JP INICIO

En CSPIMR+1 se guardó en su momento el número de sprites.
Guardamos AF como contador.
Vamos cargando los distintos registros con los valores guardados en la tabla de recuperación.
Y el resto es muy parecido a la rutina que guarda los trozos del fondo.


Ahora es cuando tú puedes cambiar distintos parámetros, tales como sprites, tamaño del buffer, de la pantalla real donde se vuelca el buffer... en fin, todo lo que se te ocurra para que estés seguro de entender su funcionamiento.

VOLCADO DEL BUFFER CON LDI (VI): IMPRESIÓN DE SPRITES

Antes de proceder a estudiar la rutina, voy a intentar explicar algunos conceptos en el movimiento a pixeles (alta resolución).

A la hora de imprimir gráficos en el spectrum, lo que se hace es meter ciertos valores en las direcciones de pantalla (en nuestro caso en el buffer).
Si yo quiero imprimir el sprite del esqueleto en las coordenadas[(Y,X))] (0,0) tendré que empezar a meterlo en la dirección 8000h que es donde le corresponde (Gráfico sin desplazar). Para imprimirlo en la coordenada (0,2), lo meto también a partir de la dirección 8000h, pero desplazado 2 pixeles a la derecha. Y lo mismo en (0,4) y (0,6). Para imprimirlo en (0,8) se empezará a meter en la dirección 8001h sin desplazarlo y así sucesivamente.

8000h     8001h      8002h 

Gráfico sin desplazar (0,0)




Gráfico desplazado dos pixeles a la derecha (0,2)




Gráfico desplazado cuatro pixeles a la derecha (0,4)




Gráfico desplazado seis pixeles a la derecha (0,6)

Esto significa que si la coordenada X es cero o múltiplo de 8, el gráfico se mete sin desplazar y si no lo es, hay que desplazarlo el número de veces que la coordenada X exceda del múltiplo de 8 inmediatamente anterior.

Como podrás imaginar, para conseguir esto hay que hacer muchos desplazamientos y esto enlentece la rutina de impresión.

Yo uso un método explicado por Pablo Ariza en una Microhobby Especial.

;;;;;;;;;;;;ROTACIONES;;;;;;;;;;;;;;;;;;;;;;;;; ;;;EMPIEZAN EN $FA00=64000 TABROT LD C,3 ;CREA LA TABLA DE ROTACIONES LD H,$FA ;METE BYTES DESPLAZADOS A LA DERECHA 2,4 Y 6 VECES LCRTCR LD A,9 ;EN $FA00-$FAFF,$FC00-$FCFF Y $FE00-$FEFF RESPECTIVAMENTE SUB C SUB C ;METE EL SOBRANTE DEL DESPLAZAMIENTO EN LD L,0 ;EN $FB00-$FBFF,$FD00-$FDFF Y $FF00-$FFFF ROTACU LD B,L LD E,0 LD D,A ;SI QUIERO SABER LO QUE VALE $C0 DESPLAZADO 4 VECES A LA VERROT DEC D ;COJO EL VALOR DE $FCC0 Y SU SOBRANTE EN $FDC0 JR Z, VEREXI SRL B RR E JR VERROT VEREXI LD (HL),B INC H LD (HL),E DEC H DEC L JR NZ, ROTACU INC H INC H DEC C JR NZ, LCRTCR

Esta rutina nos crea una tabla de tal manera que:

• En FANNh nos mete el número NN desplazado 2 veces a la derecha y en FBNN nos mete el sobrante de este desplazamiento.
• En FCNNh nos mete el número NN desplazado 4 veces a la derecha y en FDNN nos mete el sobrante de este desplazamiento.
• En FENNh nos mete el número NN desplazado 4 veces a la derecha y en FFNN nos mete el sobrante de este desplazamiento.

¿Qué quiero decir con sobrante?

Fíjate en este gráfico:

8000h                   8001h

Arriba tenemos un cuadrado sin desplazar que ocupa a partir de la posición 8000h. Abajo lo hemos desplazado dos pixeles a la derecha que nos ocupa la dirección 8000h y la 8001h. ¿Qué parte del gráfico nos ocupa la dirección 8001h? Pues lo que nos ha sobrado al desplazarlo dos pixeles. Aquí verás más claro lo que decía en la entrada anterior sobre que si la coordenada X no es cero o múltiplo de 8 (si hay desplazamiento) el cacho de buffer a guardar ocupa un caracter más de ancho que el sprite.

Esta tabla se usa así: Supongamos que un byte del sprite es 11111111b (FFh) y queremos imprimirlo en la coordenada (0,2). Necesitamos desplazarlo 2 veces a la derecha. Cargamos H con FAh y L con FFh. Al hacer LD A,(HL) en A obtenemos 00111111b y lo metemos en 8000h. Ahora necesitamos la parte sobrante. Pues  cargamos H con FBh y L con FFh. Al hacer LD A,(HL) obtenemos 11000000h y lo metemos en 8001h. Si hacemos lo mismo con los 8 bytes del gráfico lo habremos imprimido en la coordenada X=2.

Este sistema es rápido, pero supone reservar desde FA00h hasta FFFFh y el movimiento mínimo horizontal va a ser de 2 pixeles. Creo que estas dos limitaciones merecen la pena.


MÁSCARAS

Como ya he comentado, esta rutina imprime sprites, osea que no alteran el fondo por donde pasa (para eso guardamos los trozos de buffer) y tiene partes transparentes, por lo que se ve el fondo que hay a través de ellos.
Para conseguir esto último se usa la máscara: a cada byte del gráfico le corresponde su máscara, que es otro byte en el cual los unos son las partes transparentes, y los ceros las opacas. Por eso los sprites ocupan el doble que los gráficos.

Aquí podemos ver un cuadrado con su máscara correspondiente:

GRÁFICO                                                              MASCARA

Como puedes, ver he puesto unos en la máscara en los pixeles que quiero que sean transparentes; es decir en los bordes y en el centro. Suelo dejar un pixel opaco entre la máscara y el gráfico para que éste se defina mejor la imprimirlo sobre el fondo.


En este gráfico de abajo he fusionado el gráfico con la máscara para que lo veas más claro. En amarillo está el gráfico y en negro la máscara. En blanco están los pixeles que dejo de borde entre la máscara y el gráfico.

¿Cómo se maneja esto a la hora de imprimir?: Pues cogemos el byte de la máscara y hacemos un AND con el byte del fondo y a esto le hacemos un OR con el byte del gráfico.

Para crear los sprites uso el editor SevenuP de Metalbrain, que funciona de maravilla. Te explico lo fundamental de su uso para lo que nos ocupa.

En File pulsas New y te pedirá el tamaño del gráfico a crear en pixeles. Te aparecerá una cuadrícula como la de estos ejemplos. Al pulsar la flecha blanca te cambia el modo del cursor. Pinta el gráfico que quieras y luego pulsa en Mask y activa Use mask y View mask. Aquí pintas la máscara.

Yo para mi rutina de sprites necesito la máscara invertida (ya lo explicaré) por lo que tienes que pulsar en el botón INV. Ya podemos salvar el sprite.

En File pulsas Output options y tienes que dejar las opciones como en esta figura:

El byte de la máscara va antes que el del gráfico y lo guardo en Horizontal Zig Zag osea, que se guarda la primera línea del gráfico de izquierda a derecha y después la segunda de derecha a izquierda, la tercera de izquierda a derecha y la cuarta de derecha a izquierda, etc. Esta forma de guardar los sprites nos supone que podamos programar una rutina de impresión más rápida.

Finalmente  en File, pulsamos en Export data y elegimos que nos lo grabe con extensión .BIN.


Con todo esto vamos a ver la rutina de impresión de sprites.

;;;IMPRIME EL SPRITE;;;;;;; IMPBUF LD B,(IX+3) ;ALTURA/2 DIRPBUF LD DE,0 ;ESTE DATO SE METE MAS ARRIBA IMB2 LD L,(IX+4) ;DIRECCION DEL GRAFICO LD H,(IX+5) LD (STACKSP+1),SP ;SE GUARDA EL STACK LD SP,HL ;STACK=DIRECCION DEL GRAFICO EX DE,HL ;HL=DIRECCION DEL BUFFER POSAR LD A,(IX+2) ;ANCHURA DEL SPRITE LD (ANF+1),A ;LO METE EN LOS BUCLES PARA QUE LD (ANF1+1),A ;SEA MAS RAPIDA LA RUTINA LD (ANFJ+1),A LD (ANFJ1+1),A POSBIT LD A,(IX+1) ;SI LA COORDENADA X ES DIVISIBLE POR 8, AND 7 ;SIGNIFICA QUE NO HAY ROTACIONES, ASI JP Z, IMPBUFCARACTERJUSTO ;QUE LE MANDO A UNA RUTINA ESPECIAL ADD A,$F8 ;LO SUMO AL PRINCIPIO DE LA TABLA DE LD (INDEX3+1),A ;ROTACIONES Y LO METO EN LA RUTINA INC A LD (INDEX3V+1),A ;;;LA RUTINA SE REPITE 2 VECES. UNA EN PASADA A DERECHAS Y OTRA A IZQUIERDAS;; AT33 LD DE, ANPAN ANF LD C,0 ;ANCHO DEL SPRITE LA5 EXX POP DE ;MASCARA=E GRAFICO =D INDEX3 LD H,0 ;POSICION EN EL BYTE LA METO ARRIBA LD L,E LD A,(HL) ;MASCARA ROTADA CPL EXX AND (HL) ;HACE AND DE LA MASCARA CON EL FONDO EXX LD L,D ;HAYA LA ROTACION DEL GRAFICO OR (HL) ;HACE OR DEL GRAFICO ROTADO CON LO ANTERIOR EXX LD (HL),A ;HASTA AQUI HEMOS IMPRIMIDO EL PRIMER CACHO INC HL EXX ;HACEMOS LO MISMO CON LA PARTE DEL SIGUIENTE INC H ;CARACTER LD L,E LD A,(HL) CPL EXX AND (HL) EXX LD L,D OR (HL) EXX LD (HL),A DEC C JR NZ, LA5 ;REPITE LAS VECES QUE OCUPA DE ANCHO EL SPRITE ADD HL,DE ;SIGUIENTE LINEA ;;;ESTO ES LO MISMO, PERO YENDO HACIA LA IZQUIERDA;; ANF1 LD C,0 LA5V EXX POP DE INDEX3V LD H,0 ;VAMOS A LA IZQUIERDA. AQUI H VALE UNO MAS QUE EN INDEX3 LD L,E LD A,(HL) CPL EXX AND (HL) EXX LD L,D OR (HL) EXX LD (HL),A DEC HL EXX DEC H LD L,E LD A,(HL) CPL EXX AND (HL) EXX LD L,D OR (HL) EXX LD (HL),A DEC C JR NZ, LA5V ADD HL,DE ;SIGUIENTE LINEA L7 DJNZ AT33 ;REPITO (ALTO DEL SPRITE/2) VECES AT10 STACKSP LD SP,0 ;PONGO EL STACK EN SU SITIO FINSPR ;LO HAGO CON CUANTOS SPRITES EX AF,AF' ;TENGO QUE IMPRIMIR DEC A JP NZ, PINTSR

En el registro B metemos la altura del gráfico dividido por 2.
Cargamos DE con la dirección del buffer donde va el gráfico (este dato lo metimos en DIRPBUF+1 cuando lo hallamos en la rutina de guardar los fondos).
Cargamos HL con la dirección del gráfico a imprimir.
Guardamos el registro SP y lo cargamos con HL. Los datos del gráfico los vamos a ir cogiendo a base de POPs, como los datos de la cola de impresión de sprites.
Al hacer EX DE,HL, metemos en HL la dirección del buffer donde vamos a imprimir.
En A metemos la anchura del sprite y lo guardamos en las direcciones que nos hace falta para que la rutina sea más rápida.

Si la coordenada X es 0 o múltiplo de 8 significa que no hay rotaciones por lo que saltamos a IMPBUFCARACTERJUSTO, que es una rutina semejante pero sin rotar nada y más rápida.

Lo que nos ha sobrado de ser múltiplo de 8 se suma a F8h. Así ya sabemos qué tabla de rotaciones tenemos que usar y guardo este dato en la rutina: si X=12 (00001100b) y hacemos AND 7, nos da como resultado 4 (00000100b) osea que hay que usar la tabla de 4 desplazamientos. F8h+4=FCh que es donde está esta tabla. Lo guardo donde la voy a usar y lo incremento donde voy a usar los restos.
Cargo DE con el ancho del buffer, C con el ancho del sprite y con EXX paso a los registros alternativos.
Con POP DE cargo E con la máscara del primer byte del sprite y D con el gráfico.
En H meto el inicio de la tabla de desplazamientos. Al hacer "LD L,E",  en (HL) tengo la máscara rotada.
La cargo en A (LD A,(HL)) y la invierto con CPL, ya que las máscaras las salvamos invertidas desde SevenuP.

¿Por qué salvo la máscara invertida y luego la vuelvo a invertir en la rutina en vez de salvarla normal? Pues porque esta máscara que estoy invirtiendo es la original desplazada. Como usamos las tablas, a la izquierda nos ha metido ceros y eso no nos interesa ya que la parte desplazada ha de ser transparente. Por eso al hacer CPL nos convierte en unos los bits transparentes de la máscara y en ceros los opacos que es lo que nos hace falta.

Al hacer EXX, HL contiene la dirección del buffer, por lo que hacemos un AND (HL) como expliqué antes.
Volvemos a hacer EXX, por lo que H contiene la tabla de rotaciones. Con LD L,D conseguimos que en (HL) esté el gráfico rotado (D tenía el gráfico) y hacemos el OR.

Hasta este punto hemos imprimido el gráfico con la máscara desplazado. En la siguiente dirección de memoria (INC HL) meteremos el resto.
Para eso hacemos EXX  e incrementamos HL. Así H tiene el inicio de la tabla de los restos de los desplazamientos y hacemos lo mismo que antes.
Repetimos lo que nos ocupa de ancho el sprite y a partir de ANF1 nos ponemos a imprimir la siguiente línea del sprite. Para eso sumamos ANPAN (que está en DE) a la dirección del buffer donde terminó de imprimirse la primera línea del sprite y hacemos el mismo proceso pero de derecha a izquierda.

Por eso el dato de la tabla del sprite que guarda el alto del mismo se divide por la mitad: hacemos dos pasadas por cada iteración del bucle.

Recupero el Stack y repito todo el proceso con el siguiente sprite: guardo el fondo y lo imprimo.

Aquí he puesto un .GIF para que se vea más claro el proceso (espero).






Cuando la coordenada X es cero o múltiplo de 8, no hay rotaciones, así que saltamos a una rutina especial que imprime más rápido el sprite: IMPBUFCARACTERJUSTO

IMPBUFCARACTERJUSTO ;IMPRIME EN CARACTER JUSTO Y NOS AHORRAMOS LA TABLA DE ROTACIONES CERO ;FUNCIONA IGUAL QUE LA ANTERIOR PERO SIN ROTAR NADA. ANFJ LD C,0 ;ESTE VALOR LO METEMOS EN IMPBUF LA5J POP DE ;MASCARA=E GRAFICO =D LD A,E CPL AND (HL) OR D LD (HL),A ;HASTA AQUI HEMOS IMPRIMIDO EL PRIMER CACHO INC HL DEC C JR NZ, LA5J LD DE,ANPAN-1 ADD HL,DE ;;;AHORA IMPRIMIMOS LA SIGUIENTE LINEA DE DERECHA A IZQUIERDA ANFJ1 LD C,0 ;ESTE VALOR LO METEMOS EN IMPBUF LA5JV POP DE ;MASCARA=E GRAFICO =D LD A,E CPL AND (HL) OR D LD (HL),A DEC HL DEC C JR NZ, LA5JV LD DE,ANPAN+1 ADD HL,DE L7J DJNZ ANFJ JP STACKSP


Una vez imprimidos todos los sprites, tenemos que volcar el buffer a la pantalla real para que se vea lo que hemos hecho.

VOLCADO DEL BUFFER CON LDI (V): GUARDANDO EL FONDO DEL BUFFER

Una vez que hemos actualizado las coordenadas de todos los sprites vamos a proceder a su impresión. Esto requiere unos cuantos pasos:

• Primero guardamos el fondo existente en el buffer donde vamos a meter el sprite para que no se modifique a su paso.
• Luego imprimimos el sprite en el buffer.
• Cuando hemos hecho esto con todos los sprites, se vuelca el buffer en la pantalla real.
• Por último recuperamos todos los fondos del buffer que se modificaron al pintar el sprite. Así el buffer queda totalmente limpio para la próxima impresión de sprites.

En esta entrada voy a explicar cómo guardo el fondo del buffer donde voy a imprimir los sprites.

Lo primero que tenemos que saber es cómo hallar la dirección del buffer correspondiente a unas coordenadas dadas. Yo uso una tabla, donde meto la dirección del primer carácter de cada línea del buffer. Esta tabla se crea en CONTENIDA.ASM.

La tabla empieza en TABCOOR (F800h). Metemos el byte bajo de las direcciones del primer caracter de cada línea del buffer en F8nn y el byte bajo en F9nn.

;;;;;CREA LA TABLA DE COORDENADAS PARA LA RUTINA DE IMPRESION DE SPRITES CREATABLACOOR LD DE,PANTVIR ;INICIO DEL BUFFER LD HL,TABCOOR ;INICIO DE LA TABLA $F8YY EL BYTE BAJO Y $F9YY EL ALTO LD B,ALPANA ;ALTURA EN PIXELS DEL BUFFER LINELOOP: LD (HL),E INC H LD (HL),D DEC H INC L PUSH HL LD HL,ANPAN ;ANCHO DEL BUFFER ADD HL,DE EX DE,HL POP HL DJNZ LINELOOP

Cargamos DE con PANTVIR, que es el inicio del buffer (8000h) y HL con TABCOOR (F800h). Esto corresponde con (coordY=0, coorX=0). Iniciamos B con el número de líneas que tiene el buffer.

En F800h metemos el byte bajo de la dirección del buffer (00h) incrementamos H (HL=F900h) y metemos el byte alto (80h). Decrementamos H, incrementamos L y le sumamos el ancho del buffer (ANPAN) para que HL tenga la dirección de la siguiente línea del buffer (coordY=1, coorX=0) y repetimos esto con todas las líneas del buffer.

Una vez que sabemos la dirección del primer carácter de la línea del buffer donde está el sprite, sólo tenemos que sumarle la coordenada X para hallar su dirección exacta. En realidad su coordenada X dividida por 8, ya que tenemos que sumarle caracteres y no pixeles.

Veamos un ejemplo práctico. Supongamos que un sprite está en las coordenadas Y=20h X=18h.
Primero vamos a hallar la dirección del primer carácter de la línea del buffer donde está el sprite.
Para eso hacemos lo siguiente;

LD L,(IX+0) ;COORD Y LD H,$F9 ;COGE EL DATO DE LA DIRECCION DEL BUFFER DE LA TABLA LD D,(HL) ;DE TIENE LA DIRECCION DE LA LINEA PARA IMPRIMIR LD A,(IX+1) ;DIVIDE LA COORDENADA X POR 8 SRL A SRL A SRL A DEC H ADD A,(HL) ;LO SUMA AL BYTE BAJO DE LA DIRECCION LD E,A JP NC, NOCA INC D NOCA

El registro L se carga con la coordenada Y del sprite. L=20h. H se carga con la tabla que tiene los bytes altos de las direcciones del buffer. H=F9h. Por lo que HL=F920h Al hacer LD D,(HL) en D metemos el byte alto de la dirección del primer carácter del buffer correspondiente a la coordenada 20h.

Ahora metemos en A la coordenada X del sprite. A=18h y la dividimos por 8. A=3, ya que la coordenada X son pixeles y a nosotros nos hace falta saber el número de caracteres a sumar a la dirección del primer caracter de la línea. Al hacer DEC H, HL=F820h que es donde está el byte bajo de la dirección del primer caracter de la línea 20h del fuffer. Se lo sumamos a la coordenada X en caracteres (teniendo cuidado de incrementar D si ha habido acarreo) y así lo metemos en E. De esta manera, DE tiene la dirección donde se va a imprimir el sprite.

Con este método, aunque ocupa algo de memoria, las direcciones de impresión en el buffer se hallan rápidamente.

Una vez guardados los "cachos" del buffer que ocupan los sprites hay que recuperarlos. Para eso se crea una tabla para cada cacho. Cada una consta de 6 bytes:

byte 0: Altura del cacho dividida por 2
byte 1: Anchura del cacho
byte 3 y 4: dirección del buffer donde se debe reponer el cacho
byte 5 y 6: dirección donde se ha guardado el cacho

Estos datos se empiezan a guardar en DATFON (al final de APRINCIPAL.ASM) y se manejan con el registro IY.


El cacho de buffer que se guarda de un sprite no ocupa siempre lo mismo. Debido a que en el Spectrum siempre se imprime en baja resolución, si queremos que su movimiento (byte 12 de la tabla) horizontal sea de menos que 8 pixeles (en este caso puede ser de 2,4 ó 6; siempre par), debido a que hay que desplazar los gráficos, el trozo a guardar ocupará un caracter más si su coordenada X no es cero o múltiplo de 8.
En resumen, un sprite que tenga n caracteres de ancho, si su coordenada X no es cero o múltipo de 8, ocupa n+1 caracteres.
Para saber si un número es múltiplo de 8, basta con hacerle un AND 7. Si este resultado es igual a cero, es que lo es y por lo tanto ocupa n caracteres. Eso es lo que se hace con la coordenada X.
De todas formas, el tema de las rotaciones de los gráficos lo explicaré en la rutina de impresión.


Una última consideración. Como ya he explicado, las tablas de los sprites que se tienen que imprimir se van metiendo en una cola que empieza en SPIMP. Para ir cogiendo estos datos uso la pila, que es un método muy rápido.

Supongamos que en la cola de impresión de sprites he metido: ENEM2,ENEM3,ENEM4,PROTA.
Primero cargo SP con SPIMP (LD SP,SPIMP). Para recuperar el primer dato hago POP IX con lo que IX=ENEM2. Una vez que termino con este sprite hago de nuevo POP IX con lo que ahora IX=ENEM3 y así sucesivamente hasta IX=PROTA.

Para usar la pila de esta manera hay que tener en cuenta que:

• Las interrupciones han de estar deshabilitadas, ya que al saltar una interrupción se guarda la dirección de retorno en la pila, con lo que se nos machacarían los datos y a saber a dónde retorna.
• No se puede usar ninguna instrucción que maneje la pila, tal como CALL, hacer PUSH para guardar registros, etc. Obviamente esto también nos machacaría los datos. 

Después de todo este rollo, vamos a ver la rutina en sí.

;;;;;;;;GUARDAMOS EL FONDO DE TODOS LOS SPRITES A IMPRIMIR;;;;; LD IY,DATFON-6 ;PUNTERO PARA GUARDAR LOS DATOS DE LOS CACHOS ;DE PANTALLA DONDE VA A IR EL SPRITE ;;PARA CADA SPRITE SE GUARDAN 6 DATOS ;0=ALTURA/2, 1=ANCHURA, 2,3=DIR BUFFER PANTALLA, 4,5=DONDE SE GUARDA ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; LD (STACKV+1),SP ;GUARDO EL STACK LD DE,FONDOS ;A PARTIR DE FONDOS SE GUARDAN LOS FONDOS DONDE LD (GFONDI+1),DE ;VA A IR EL SPRITE LD SP,SPIMP ;INICIO DE LA COLA DONDE SE METEN LAS TABLAS ;DE LOS SPRITES A IMPRIMIR CSPIM LD A,0 ;NUMERO DE SPRITES QUE HAY QUE IMPRIMIR LD (CSPIMR+1),A ;SE ACTUALIZA EN METEIMPS PINTSR EX AF,AF' POP IX ;COJO EL DATO DE LA COLA DE IMPRESION DE SPRITES LD DE,6 ADD IY,DE ;ACTUALIZAMOS IY LD L,(IX+0) ;COORD Y LD H,$F9 ;COGE EL DATO DE LA DIRECCION DEL BUFFER DE LA TABLA LD D,(HL) ;DE TIENE LA DIRECCION DE LA LINEA PARA IMPRIMIR LD A,(IX+1) ;DIVIDE LA COORDENADA X POR 8 SRL A SRL A SRL A DEC H ADD A,(HL) ;LO SUMA AL BYTE BAJO DE LA DIRECCION LD E,A JP NC, NOCA INC D NOCA LD (DIRPBUF+1),DE ;DE=DIRECCION DEL BUFFER DONDE VA EL SPRITE ;SE METE EN LA RUTINA ;PARA NO VOLVER A HALLARLO GF1 EX DE,HL LD (IY+2),L ;LO METEMOS EN SU TABLA LD (IY+3),H GFONDI LD DE,FONDOS ;DONDE SE GUARDA EL FONDO DEL DONDE VA EL SPRITE LD (IY+4),E ;LO METEMOS EN SU TABLA LD (IY+5),D LD C,(IX+2) ;ANCHO DEL SPRITE LD A,(IX+1) ;SI LA COORDENADA Y ES DIVIDIBLE POR OCHO AND 7 ;OCUPA LA ANCHURA, SI NO LO ES, HAY QUE INCREMENTARLA JP Z, NOINC ;YA QUE OCUPA UN CARACTER MAS INC C NOINC LD A,C LD (IY+1),A ;LO METEMOS EN SU TABLA LD (GF6+1),A ;SE METE EN LA RUTINA LD (GF3+1),A ;PARA NO VOLVER A HALLARLO NEG ;HALLAMOS LO QUE HAY QUE SUMAR A HL PARA PASAR ADD A,ANPAN ;A LA LINEA SIGUIENTE (ANPAN-ANCHO A GUARDAR) LD (METAN+1),A LD (METAN1+1),A LD A,(IX+3) ;ALTURA/2 LD (IY+0),A ;LO METEMOS EN SU TABLA LD B,0 ;REPITE C OSEA QUE B=0 GF5 GF6 LD C,0 ;ESTE DATO SE METE MAS ARRIBA GF2 LDI JP PE, GF2 ;REPITE HASTA QUE BC=0 METAN LD C,0 ;SIGUIENTE LINEA ADD HL,BC GF3 LD C,0 ;ESTE DATO SE METE MAS ARRIBA GF4 LDI JP PE, GF4 ;REPITE HASTA QUE BC=0 METAN1 LD C,0 ;SIGUIENTE LINEA ADD HL,BC DEC A JP NZ, GF5 POSGU LD (GFONDI+1),DE ;ACTUALIZAMOS GFONDI PARA QUE EL FONDO ;DEL ;SIGUIENTE SPRITE LO GUARDE SEGUIDO.

Cargamos en IY la dirección donde se van a ir guardando las tablas de los cachos del buffer-6.
Guardamos el registro de la pila, ya que lo vamos a usar para ir sacando las tablas de los sprites de la cola de impresión.
Metemos en GFONDI+1 el inicio de la zona donde vamos a guardar los cachos.
Apuntamos la pila a la cola de impresíón.
Aquí aparece CSPIM que es el número de sprites que hay en la cola y que se actualiza en METEIMPS cada vez que metemos uno.
Ya que está en A, lo metemos también en CSPIMR+1 que es el contador del bucle para restaurar los fondos.
Con POP IX cogemos el primer dato de la cola de impresión, osea, IX=tabla del primer sprite a imprimir.
Después hallamos la dirección del buffer a partir de las coordenadas como vimos antes, y la metemos en la tabla. Luego metemos en la tabla la dirección a partir de donde se guarda el cacho.
Miramos si la coordenada X es múltipo de 8. Si no lo es, el trozo a guardar tiene un caracter más que el ancho del sprite.
Antes comenté que para hallar la dirección inmediatamente inferior a una dada en el buffer había que sumarla ANPAN. Como al ir guardando líneas esta dirección se va a incrementar en el ancho del trozo a guardar, la dirección inmediatamente inferior a la  del inicio del trozo será de ANPAN-(ancho del cacho).
Guardamos la (altura/2) en la tabla .

Ponemos B=0 ya que el bucle en GF2 se repetirá hasta que BC=0  y volcamos la primera línea con LDI. Para ir a la segunda, se le suma ANPAN-(ancho del trozo).
Se vuelve a repetir el asunto (ya que el bucle dura  (altura del sprite/2)) y se guarda la dirección de inicio donde se va a meter el siguiente trozo.


Ya estamos preparados para imprimir el sprite.

VOLCADO DEL BUFFER CON LDI (IV): CONTROL DE ENEMIGOS Y DISPARO

Siguiendo el bucle principal, nos encontramos con el control de los los enemigos:


  ;;;CONTROL DE LOS ENEMIGOS;;; NUMEN EQU 6 ;EN PRINCIPIO, EL NUMERO MAXIMO DE ENENMIGOS ES 6 CONTE LD B,NUMEN LD IX,ENEM1 ;;MOVIMIENTO HORIZONTAL CONTS LD A,(IX+19) BIT 7,A JP Z, CONTS1 ;MIRAMOS SI VA A MITAD DE VELOCIDAD AND 127 ;PONEMOS EL BYTE 7 A CERO XOR 1 SET 7,A ;LO PONEMOS A UNO OTRA VEZ LD (IX+19),A JP Z, PONSP ;CADA DOS VECES, SOLO LO IMPRIME CONTS1 LD A,(IX+1) ;SI LLEGA AL LIMITE IZQUIERDO O DERECHO OR A ;CAMBIA LA DIRECCION DEL SPRITE JP Z, CHANGE LD C,A ADD A,(IX+18) CP ANPANA LD A,C JP NC, CHANGE NOFIS ADD A,(IX+12) ;SI NO HAY CAMBIO DE SIGNO DEL INCREMENTO, LD (IX+1),A ;SIMPLEMENTE ACTUALIZAMOS LA COORDENADA X CALL GESTFAS ;CAMBIAMOS LA FASE ;;MOVIMIENTO VERTICAL LD A,(IX+0) OR A JP Z, CHANGEV LD C,A LD A,(IX+3) SLL A ADD A,C CP ALPANA JP NC, CHANGEV LD A,C ADD A,(IX+11) LD (IX+0),A PONSP CALL METEIMPS ;METEMOS EL SPRITE A LA COLA DE IMPRESION LD DE,ENEM2-ENEM1 ADD IX,DE DJNZ CONTS

NUMEN es una etiqueta en la que indicamos el número de los enemigos que vamos a controlar. En este ejemplo será de 1 a 6.

En CONTE se inicia un bucle con ese número ya que vamos a hacer lo mismo con todos.
Metemos en IX la tabla del primer enemigo.

En CONTS miramos si el bit 7 del byte 19 de la tabla está a uno. Si es así, significa que este sprite va a mitad de velocidad que el prota.
Voy a usar el bit 0 de este mismo byte para saber si hay que mover al sprite o no. Para eso ponemos el bit 7 a cero (ya que sólo nos interesa el bit 0), hacemos un XOR 1 para usarlo como contador y volvemos a poner el bit 7 a uno. Si el resultado del XOR 1 es cero saltamos a PONSP, osea no se mueve el sprite, pero sí que se imprime. En este ejemplo el sprite que va a mitad de velocidad es el esqueleto de arriba.
Al hacer XOR 1, si A vale cero pasa a valer 1 y si A vale 1 pasa a valer cero. Por eso es cero una de cada dos veces, por lo que el sprite va a mitad de velocidad. Primero ponemos a cero el bit 7 para que no influya en el resultado del XOR 1 y luego lo ponemos a 1 para que nos siga valiendo de testigo como que es un sprite que se mueve a mitad de velocidad.

EN CONTS1 mira si ha llegado al límite izquierdo o derecho del buffer. Si es así, salta a CHANGE para que cambie el sentido de la marcha del sprite. Si no, actualiza su posición con el incremento (o decremento) que está en el byte 12 de la tabla y llama a GESTFAS para que cambie de fase.

Para el moviento vertical vuelve a comprobar si está en los límites de arriba o abajo del buffer. Para el de arriba basta ver si está en la coordenada Y=0. Para el de abajo cogemos el valor del byte 3 de la tabla que es la altura del sprite dividida por 2 y la multiplicamos por 2 (SLL). La sumamos a la coordenada Y, y si se pasa del número máximo de líneas verticales del buffer salta a CHANGEV para que cambie el sentido del movimiento vertical del sprite.
En caso de que esté dentro del buffer, simplemente actualiza la coordenada Y con el incremento (o decremento) vertical (byte 11 de la tabla).

Una vez hecho esto, llamamos a la rutina que nos mete la dirección de la tabla del sprite en la cola de impresión de sprites (METEIMPS), pasamos a la siguiente tabla sumando el tamaño de la tabla a IX y continuamos con el bucle hasta que el registro B sea igual a cero.

CHANGE Y CHANGEV están en ARUTINAS.ASM

;;;CAMBIA LA DIRECCION Y EL GRAFICO DE LOS ENEMIGOS CHANGE LD A,(IX+12) ;COGEMOS EL INCREMENTO O DECREMENTO EN LA NEG ;COORDENADA X Y LO CAMBIAMOS DE SIGNO LD (IX+12),A JP M, NEGAT ;SI AL NEGAR EL INCREMENTO DE LA COORDENADA X ;EL NUMERO QUE RESULTA ES NEGATIVO (M) ES QUE SE ;VA A MOVER A LA IZQUIERDA Y SALTA A NEGAT, CON LO ;QUE PONE EL GRAFICO MIRANDO A LA IZQUIERDA POSIT LD L,(IX+14) ;PONE EL GRAFICO MIRANDO A LA DERECHA LD H,(IX+15) JP POSNP NEGAT LD L,(IX+16) ;PONE EL GRAFICO MIRANDO A LA IZQUIERDA LD H,(IX+17) POSNP CALL METEG ADD A,(IX+1) ;ACTUALIZAMOS LA COORDENADA X LD (IX+1),A JP PONSP

Cogemos el incremento (o decremento) de la posición horizontal del sprite (byte 12 de la tabla) y lo negamos.
Si al negarlo da un número negativo, es que pasa de moverse a la derecha a moverse a la izquierda. Por ello ponemos el JP M, NEGAT que significa algo así como "si el registro A es negativo, salta a NEGAT".
Si es positivo, la cosa queda en POSIT donde metemos el gráfico mirando a la derecha (bytes 14 y 15) y saltamos a PONSP. Aquí llamamos a METEG que ya explicamos en el control del prota y actualizamos la coordenada X con el incremento corresponsiente.

;;CAMBIA DE DIRECCION VERTICAL SI UN ENEMIGO LLEGA A LOS LIMITES DE LA PANTALLA CHANGEV LD A,(IX+11) ;COGEMOS EL INCREMENTO O DECREMENTO EN LA NEG ;COORDENADA Y Y LO CAMBIAMOS DE SIGNO LD (IX+11),A ADD A,(IX+0) LD (IX+0),A ;ACTUALIZAMOS LA COORDENADA X JP PONSP

CHANGEV es muy parecida. Aquí no nos interesa si hay incremento o decremento, ya que el gráfico no cambia si sube o baja.


LA COLA DE IMPRESIÓN

Más arriba he comentado que si queremos que un sprite se imprima, hay que llamar a METEIMPS para que lo incluya en la cola de impresión.
Esto funciona de la siguiente manera: tenemos una cola de impresión FIFO (el primero que entra es el primero que sale) donde vamos metiendo las direcciones de las tablas de los sprites que queremos imprimir cada vez.

Si queremos imprimir los sprites ENEM1, EMEM4, ENEM6, el disparo y el prota, cuando llegue el turno a la rutina de impresión, ésta busca en la cola qué sprite imprimir en ese momento. Así nuestra cola quedará // ENEM1, EMEM4, ENEM6,DISPARO,PROTA//. Esta rutina los va "sacando" en orden y los imprime. Los sprites que se imprimen primero van quedando por debajo de los siguientes. En realidad no hace falta usar la cola, ya que podemos ir mandando imprimir los sprites a medida que se van actualizando, pero a efectos prácticos es más interesante usarla. Además de que teniendo los sprites en una cola, se pueden ordenar para que se impriman en orden descendente de la coordenada Y que ocupa cada uno, por lo que nos da sensación de profundidad. Esto se usa en el juego Renegade y es fundamental en los juegos isométricos. En este ejemplo no se ordenan.

METEIMPS
Está en ARUTINAS.ASM

Si recuerdas cuando comenté la estructuración de la memoria había una etiqueta que se llamaba SPIMP en la cual reservaba 20 bytes con un DS 20.
SPIMP es el inicio de la cola. Cada dato que voy a meter en la cola es de 2 bytes (las direcciones de las tablas de los sprites)

;;RUTINA PARA METER UN SPRITE EN LA COLA DE IMPRESION METEIMPS DIRAMET LD (SPIMP),IX ;METEMOS LA TABLA DEL SPRITE LD HL,(DIRAMET+2) ;SUMAMOS DOS AL PUNTERO DE LA COLA INC L INC L LD (DIRAMET+2),HL LD HL,CSPIM+1 ;INCREMENTAMOS EL CONTADOR DE SPRITES INC (HL) ;A IMPRIMIR RET

Metemos IX en la cola e incrementamos el puntero de la cola en 2. Este incremento se hace de una manera "especial". Si es el primer sprite, DIRAMET+2 vale SPIMP, ya que es el principio de la cola. Para incrementarlo 2 veces deberíamos hacer INC HL, INC HL y luego volver a guardar este dato (SPIMP+2). Por qué hago INC L, INC L? Pues porque he colocado SPIMP en la dirección F900h+192=F9C0h. La cola nunca va a llegar a FA00h (F9C0h+20=F9D4h) así que podemos incrementar sólo el byte bajo de HL que es más rápido que incrementar HL entero.

A ver si me explico. Imagina que llegamos a un punto que SPIMP vale F9FEh. Tenemos que incrementar dos veces. Si hacemos INC HL, INC HL, el valor será F9FFh,FA00h. Hemos pasado de F9FEh a FA00h al incrementar HL dos veces. Si queremos usar INC L dos veces porque es más rápido, si partimos de SPIMP=F9FEh qué valor nos daría? F9FFh con el primer incremento y al incrementar otra vez el registro L sería F900h ya que H no lo actualiza, por lo que lo estaríamos haciendo mal.
Por eso es fundamental estar seguros de que al incrementar direcciones de una tabla no se nos incremente nunca el byte alto si queremos incrementar sólo el byte bajo para ganar velocidad.

Aquí no es muy importante, pero en rutinas de impresión que se mueven mucho datos, la diferencia de velocidad es significativa. Lo veremos.

Después de actualizar SPIMP, incrementamos el contador de sprites a imprimir (CSPIM).  Este contador lo utiliza la rutina de impresión para saber cuántos sprites tiene que imprimir y ese contador lo carga en el registro A:

CSPIM LD A,0

Para incrementarlo lo que hacemos es LD HL,CSPIM+1 ya que la instrucción LD A,n ocupa dos bytes e incrementamos el valor que contiene la dirección de HL; osea, hacemos INC (HL).

Por último, decir que cada vez que se ejecuta el bucle principal, hay que poner a cero el número de sprites a imprimir y poner la cola de impresión de los sprites al principio (SPIMP):

;;;COLOCAMOS LAS VARIABLES PARA EMPEZAR A IMPRIMIR SPRITES XOR A LD (CSPIM+1),A ;CONTADOR SPRITES A IMPRIMIR LD HL,SPIMP ;PONEMOS EL INICIO DE SPRITES A LD (DIRAMET+2),HL ;IMPRIMIR EN SPIMP

Esto se hace en INICIO justo antes de leer las teclas.



CONTROL DEL DISPARO

;;;;;;;VER SI DISPARA;;;;;; PONQDIS LD A,(JOY+1) ;DISPARAMOS? BIT 4,A JP Z, MTT ;;;PONEMOS EL DISPARO LD A,$C3 ;OPCODE DE JP LD (PONQDIS),A LD HL,DISPON LD (PONQDIS+1),HL ;;;;CON ESTO ANTERIOR PONEMOS EN PONQDIS: JP DISPON LD A,20 LD (DISPON+1),A ;DISPARO ACTIVADO POR 20 MOVIMIENTOS LD A,(HORIEN+1) ;MIRO LA HORIENTACION DEL PROTA OR A ;SI ES CERO, ES QUE MIRA A LA DERECHA JP Z, PONDDCHA ;;PONEMOS EL DISPARO A LA IZDA DEL PROTA;; LD C,-8 ;POSICION A LA IZDA DEL PROTA LD B,-4 ;MOVIMIENTO A LA IZDA DEL DISPARO JP COLOD PONDDCHA LD C,14 ;POSICION A LA DCHA DEL PROTA LD B,4 ;MOVIMIENTO A LA DCHA DEL DISPARO ;;PONEMOS EL DISPARO A LA DCHA DEL PROTA;; COLOD LD A,(PROTA) ADD A,6 LD (DISPARO),A ;COLOCO EL DISPARO EN SU POSICION VERTICAL LD A,(PROTA+1) ADD A,C LD (DISPARO+1),A ;COLOCO EL DISPARO EN SU POSICION HORIZONTAL LD A,B LD (DISPARO+12),A ;COLOCO EL SENTIDO DEL DISPARO ;;;CONTROL DEL DISPARO ACTIVADO;;;;;;;;; DISPON LD A,0 DEC A LD (DISPON+1),A ;DECREMENTAMOS LA DURACION DEL DISPARO JP Z, FINDISP ;SI LLEGA A CERO, LO DESACTIVA SIGDIS LD IX,DISPARO LD A,(IX+1) CP 4 ;SI EL DISPARO LLEGA A LOS LIMITES DE LA JP C, FINDISP ;PANTALLA, SE DESACTIVA CP ANPANA-10 JP NC, FINDISP ADD A,(IX+12) ;SI NO, ACTUALIZA LA COORDENADA X LD (IX+1),A CALL METEIMPS ;MANDAMOS AL DISPARO A LA COLA DE IMPRESION

El control del disparo se realiza de la siguiente manera:
Si el disparo no está activado, miramos si se ha pulsado la tecla de disparo. Si lo está, metemos el opcode de JP DISPON en PONQDIS, establecemos la duración del disparo (el disparo está activo siempre que su contador de duración sea mayor que cero o no llegue a los límites del buffer), y dependiendo de la dirección a la que mira el prota ponemos el disparo a su derecha o a su izquierda y le damos el sentido del movimiento que corresponda.
Cuando el disparo está activado, decrementamos la duración del mismo y si es ésta llega a cero, lo desactiva llamando a FINDISP que está en ARUTINAS.ASM. Si se nos sale de los límites del buffer lo desactivamos también, y si no, actualizamos su coordenada X (el disparo se mueve de 4 en cuatro pixeles). Por último lo mandamos a la cola de impresión.

Lo interesante de esta rutina es la manera en que se comprueba si el disparo está activado o no.
Lo más normal sería comprobar si (DISPON+1)=0, ya que en ese caso el disparo estaría desactivado y procederíamos a comprobar la tecla. Pero las comprobaciones no son demasiado demasiado rápidas. Lo que hago es cambiar el código del programa directamente.

En CONTENIDA.ASM, antes de saltar a INICIO he metido este código para desactivar el disparo, que es el mismo que FINDISP:

;;QUITAMOS EL DISPARO LD A,$3A ;OPCODE DE LD A,(NN) LD (PONQDIS),A LD HL,JOY+1 LD (PONQDIS+1),HL

¿Qué hace esto?

Si te das cuenta, para saber si se ha pulsado la tecla del disparo tenemos que meter en el registro A el valor de (JOY+1) o lo que es lo mismo, que se ejecute esta instrucción: LD A,(JOY+1). El código de esta instrucción no es otro que 3Ah,JOY+1. Pues eso es lo que metemos en PONQDIS. Así, cuando el disparo está desactivado, directamente se ejecuta la lectura de la tecla.

Cuando la tecla se pulsa, ponemos (DISPON+1)=20 con lo que se activa el disparo y sabemos que en ese caso no hay que comprobar la tecla hasta que (DISPON+1)=0.
Pues volvemos a cambiar el código y en PONQDIS ponemos directamente JP DISPON poniendo el disparo con:

;;;PONEMOS EL DISPARO LD A,$C3 ;OPCODE DE JP LD (PONQDIS),A LD HL,DISPON LD (PONQDIS+1),HL

Esto lo que hace es poner C3h en (PONQDIS) y DISPON en (PONQDIS+1) con lo que en PONQDIS nos queda JP DISPON y directamente pasa a controlar el disparo sin leer la tecla.

Esto de cambiar el código es muy práctico para ganar velocidad, pero éste se complica y puede llegar a ser muy lioso de depurar. Joffa lo usa mucho en Cobra, por ejemplo.

Para terminar, después de la gestión del disparo, mandamos al prota a la cola de impresión. Lo meto el último para que quede por encima de todos los sprites al imprimirlos:

;;MANDAMOS AL PROTA A LA COLA DE IMPRESION LD IX,PROTA CALL METEIMPS


En esta entrada hemos visto algunos conceptos un poco complicados (más de explicar que de entender).
Prueba a cambiar parámetros en las tablas, como coordenadas de los sprites, sentido de la marcha al principio, velocidades, gráficos...
Ten en cuenta que la comprobación de si un sprite llega al límite izquierdo o superior del buffer no es demasiado fina. Simplemente mira si ha llegado a la coordenada cero. Esto puede dar problemas dependiendo del incremento que se le de a la coordenada. Por ello, sitúa al sprite en una coordenada múltiplo de la velocidad que le des.

VOLCADO DEL BUFFER CON LDI (III): TABLAS DE SPRITES Y CONTROL DEL PROTA

En esta entrada voy a explicar cómo se realiza el control de los sprites. Para poder hacer esto, necesitamos unas tablas que nos digan las características del sprite, su posición y toda la información necesaria.

Estas tablas se encuentran en ATABLAS.ASM.
En este ejemplo voy a manejar al PROTA, al disparo (si existe) y a 6 enemigos.

Aquí vemos una tabla tipo de un sprite enemigo:

ENEM1 DEFB 80,48,2,8 ;0,1,2,3 DEFW CABAD ;4,5 DEFB 2 ;6 DB 0 ;7 DW CABAD ;8,9 DB 1 ;10 DB 0 ;11 DB 4 ;12 DB 64 ;13 DW CABAD ;14,15 DW CABAI ;16,17 DB 16 ;18 DB 0 ;19

El significado de cada byte de la tabla es el siguiente:

byte 0: Coordenada Y del sprite
byte 1: Coordenada X del sprite
byte 2: Ancho del sprite en caracteres
byte 3: Alto del sprite en líneas dividido por dos.
Si un sprite tiene un tamaño de 3 caracteres de ancho por 3 de ancho, el byte 3 valdrá 3             caracteres*8 líneas que tiene cada caracter dividido por 2, osea: 12. Se divide por dos por el  método que usamos para imprimir el sprite.
byte 4 y 5: Dirección donde se guarda el gráfico a imprimir con la fase actual
byte 6: Pausa que se hace cuando cambiamos antes de cambiar la fase (o frame) a un sprite. Si no se    pone  pausa, parece que va bailando y si se pone demasiada, parece que va patinando.
byte 7: Fase actual del sprite
byte 8 y 9: Gráfico de la primera fase del sprite.
byte 10: Número de fases que tiene el sprite menos 1.
byte 11: Número de pixels que se mueve el sprite en la coordenada Y. Siempre tienen que ser pares.
byte 12: Número de pixels que se mueve el sprite en la coordenada X. Siempre tienen que ser pares.
byte 13: Tamaño que tiene el sprite para cambiar de fase. Si pasamos de la fase 1 a la fase 2, tenemos que saber cuánto ocupa el sprite y así sumarlo a la fase anterior.
byte 14 y 15: Gráfico del sprite mirando a la derecha
byte 16 y 17: Gráfico del sprite mirando a la izquierda
byte 18: Anchura del sprite en pixels. Esto lo uso para saber cuando llegamos al límite derecho de la   pantalla y así darle la vuelta y cambiar el sentido de movimiento. Este dato lo podemos hallar dividiento por dos el byte 2, pero así es más rápido y ocupa muy poco.
byte 19: Este byte se usa para que el sprite vaya a la mitad de velocidad (el esqueleto que sale arriba   del todo). Si el bit 7=1 (10000000b=128) es que este sprite va a la mitad de velocidad que el prota.

No te asustes con toda esta información. A medida que se vaya usando en el programa lo iré explicando más exhaustivamente.

CONTROLANDO AL PROTA

;;;;;;;;;CONTROL DEL PROTA;;;;;;;;;; CONTPRO LD IX, PROTA TEC15 LD A,(JOY+1) BIT 1,A JP Z, NOIZQ ;;TECLA IZQUIERDA PULSADA;; ;;SI LA HORIENTACION DEL PROTA ES IZDA, NO CAMBIAMOS EL GRAFICO;; ;;SI ES DERECHA, PONEMOS EL GRAFICO MIRANDO A LA IZQUIERDA;; ;;Y LE DAMOS ESA HORIENTACION ;;LO MISMO CON LA DERECHA HORIEN LD A,0 ;0=DCHA, 1=IZDA OR A JP NZ, NOCAMI INC A LD (HORIEN+1),A LD HL,PROTAI ;GRAFICO MIRANDO A LA IZDA CALL METEG NOCAMI LD A,(PROTA+1) ;MIRO SI LLEGA AL LIMITE IZQUIERDO OR A JP Z, NOIZQ SUB 2 ;RESTAMOS 2 COORDENADAS A LA X JP METX1


Lo primero que hacemos es cargar IX con el inicio de la tabla del prota.
Como vimos en otra entrada, las teclas pulsadas se guardan en JOY+1.
Si el bit 1 de este valor es uno, es que la tecla izquierda está pulsada.
Al pulsar la tecla izquierda, el sprite se tiene que mover para la izquierda y además poner el gráfico mirando en esta dirección...si no lo está ya. Para eso usamos HORIEN. Yo no suelo usar direcciones de memoria para guardar variables como tal. Si te das cuenta, directamente pongo:

HORIEN  LD A,0

LD A,n ocupa dos bytes, por lo que mi variable se va a guardar en HORIEN+1.

Si HORIEN+1 vale cero, es que está mirando a la derecha, por ello tenemos que meter el gráfico de la izquierda y si vale cero, ya está metido, así que nos ahorramos este paso.

Antes de saltar a INICIO, en contenida ponemos al prota mirando a la derecha:

XOR A LD (HORIEN+1),A ;EL PROTA EMPIEZA MIRANDO A LA DERECHA LD HL,PROTAD ;GRAFICO DEL PROTA MIRANDO A LA DERECHA LD IX,PROTA CALL METEG


Con OR A sabemos si vale cero o no. Si vale cero, incrementamos A y actualizamos la variable HORIEN+1 para saber que ya está mirando para la izquierda. Metemos el gráfico de la izquierda y llamamos a METEG, que está en ARUTINAS.ASM:


;;METE LA DIRECCION DEL GRAFICO QUE TIENE HL EN LA TABLA DEL SPRITE;; METEG LD (IX+6),0 ;CONTADOR DE ESPERA DE CAMBIO DE FRAME A CERO LD (IX+8),L ;PRIMER FRAME DEL GRAFICO DEL SPRITE LD (IX+9),H LD (IX+4),L ;FRAME ACTUAL DEL SPRITE LD (IX+5),H RET


Aquí, ponemos a cero el contador de frames del sprite para que no cambie enseguida y metemos el gráfico de la izquierda en el sitio correspondiente de la tabla.

Luego cogemos la coordenada X del sprite (como sé que IX=PROTA, en vez de usar LD A,(IX+1), uso LD A,(PROTA+1) que es más rápido) y miro que no haya llegado al límite izquierdo de la pantalla (coordenada X=0). Si no lo ha hecho, le resto dos y salto a METX1 para que lo guarde en la tabla.

Veamos el control de la derecha:

;;TECLA DERECHA PULSADA;; LD A,(HORIEN+1) ;0=DCHA, 1=IZDA OR A JP Z, NOCAMD DEC A LD (HORIEN+1),A LD HL,PROTAD CALL METEG NOCAMD LD A,(PROTA+1) CP ANPANA-16 JP Z, VERARRIBA ADD A,2 METX1 LD (PROTA+1),A CALL GESTFAS ;CAMBIAMOS LA FASE, YA QUE SE HA MOVIDO


Básicamente es lo mismo. Si el valor de HORIEN+1 es cero, significa que ya estaba mirando a la derecha, por lo que no cambiamos el gráfico de sentido. Si es uno se procede como cuando se pulsa la tecla izquierda. Luego se mira si hemos llegado al borde derecho (vemos si la coordenada X es el ancho del buffer-16 que es el ancho del sprite en pixels) y si no lo ha hecho le sumo 2 y guardamos la coordenada actualizada.

Después llamamos a la rutina que nos cambia la fase del sprite, ya que se ha movido . Esta rutina se llama GESTFAS y por supuesto, está en ARUTINAS.ASM.

Voy a explicar cómo funciona el tema de las FASES del sprite o FRAMES.
A la hora de mover un sprite y para que la sensación de movimiento sea más real se usan fases. Por ejemplo, nuestro prota tiene 2. Así, al alternarlas mientras se mueve parece que anda.

(Llamaré a la fase con los pies juntos, FASE A y a la de los pies separados, FASE B)

Si echas un vistazo en ASPRITES.ASM verás que los gráficos se guardan en orden de fases

PROTAD INCBIN "PROTAD1.BIN" INCBIN "PROTAD2.BIN"

PROTAD1.BIN es la FASE A del prota mirando a la derecha y PROTAD2.BIN es la FASE B.
Esta es la manera de guardar todos los gráficos de los sprites.


Los bytes de la tabla de sprites que controlan las fases son:

• Byte 6: es una pausa que se hace para que no cambie de fase cada vez que se mueve el sprite. En este caso cambia cada 3 veces que se mueve. Esto es para que el efecto de movimiento sea más "real".
• Byte 7: aquí se guarda el número de la fase en curso. Cuando es igual al número total de fases-1, se pone otra vez a cero.
• Byte 10: número total de fases -1
• Bytes 4 y 5: En estos bytes se guarda la dirección donde está el gráfico del sprite que se tiene que imprimir. 
• Bytes 8 y 9: En estos se guarda la dirección del primer gráfico del sprite.
• Byte 13: guarda los bytes que ocupa cada gráfico del sprite. Cada fase.

Empezamos con la FASE A. El byte 7=0 y no tenemos que hacer pausa. En FASE miramos si ya estamos en la última fase (byte 10). Si no es así, seguimos en LA3 con lo que incrementamos el contador de fase (byte 7) y sumamos al gráfico que tenemos que imprimir el tamaño del mismo. Osea, a la FASE A le sumamos 64, que es lo que nos ocupa el gráfico y lo guardamos otra vez en los bytes 4 y 5 para que se imprima ese gráfico, que no es otro que FASE B.

Si tuviera más fases esto se repetiría con la FASE C, FASE D, FASE E... Cuando el contador (byte 7) sea igual al número total de fases -1 (byte 10) pasaríamos a FASDER. Aquí se pone a cero el contador y en los bytes 4 y 5 se mete la primera fase del sprite (FASE A) que está guardada en  los bytes 8 y 9.

RUTINA GESTFAS

;;CAMBIA EL FRAME DEL SPRITE GESTFAS LD A,(IX+6) ;CAMBIA DE FRAME CADA 3 VECES QUE SE LE LLAMA INC A AND 3 ;4 AND 3=0 LD (IX+6),A RET NZ FASE LD A,(IX+7) CP (IX+10) JP Z, FASDER ;NO HEMOS LLEGADO AL ULTIMO FRAME LA3 INC (IX+7) ;INCREMENTAMOS EL CONTADOR LD L,(IX+4) ;CAMBIO DE FASE LD H,(IX+5) ;DE TIENE LA DIRECCION DEL GRAFICO LD E,(IX+13) ;TAMAÑO SPRITE LD D,0 ADD HL,DE LA33 LD (IX+4),L ;METEMOS EN EL FRAME ACTUAL EL ANTERIOR MAS EL TAMAÑO LD (IX+5),H ;DEL SPRITE RET ;HEMOS LLEGADO AL ULTIMO FRAME FASDER LD (IX+7),0 ;CONTADOR A CERO LD L,(IX+8) ;PONE EL PRIMER FRAME EN EL FRAME ACTUAL LD H,(IX+9) LD (IX+4),L LD (IX+5),H RET

En cuanto al contador de pausa que se gestiona en GESTFAS funciona como sigue:

Lo primero que hacemos es ver si hay que cambiar la fase, ya que como comenté más arriba, no conviene cambiarla cada vez que se mueve el sprite. En este caso se cambia cada tres veces.
Metemos en A la pausa lo incrementamos y hacemos AND 3. Esto es un contador que cada tres veces vale cero.

 Los valores que puede tener son los siguientes:

0=00000000b
1=00000001b
2=00000010b
3=00000011b
4=00000100b

Como hacemos AND 3 (00000011b), el registro A sólo va a ser distinto de cero cuando valga 1,2 o 3. Si vale 4 al hacer el AND nos queda cero. Por lo que el contador vuelve a empezar y podemos cambiar de fase. Esto es una manera de usar contadores más rápida.


Con todo este lío no sé si te habrás dado cuenta de un detalle. El sprite del prota es un gráfico de 2x2 caracteres, por lo que debería ocupar: 2 caracteres de alto * 8 líneas que tiene cada caracter * 2 caracteres de ancho=32 bytes. Pero yo he puesto 64. Esto es porque esta rutina no maneja gráficos, maneja sprites (ya sé que hay controversia con estos términos, pero a mí me gusta esta distinción).
Los sprites son gráficos que se imprimen en la pantalla fusionándose con el fondo. Es decir tienen partes transparentes.Además, al moverse, respetan el fondo. Si te das cuenta, a través del agujero del donut se ven las líneas del fondo, lo mismo que en los bordes. Para conseguir este efecto, necesitamos lo que se llama máscara que nos indica qué parte del sprite es transparente. Esta máscara nos ocupa los mismos bytes que el gráfico. De ahí los 64 bytes.
Todo esto de la máscara se verá más adelante.


Para el control vertical del prota creo que no es necesaria ninguna explicación, más que los comentarios del código.

VERARRIBA LD A,(JOY+1) BIT 3,A JP Z, VERABAJO ;;TECLA ARRIBA PULSADA;; ;;SI NO LLEGA ARRIBA DEL TODO, RESTA 2 A LA COORDENADA Y;; LD A,(PROTA) OR A JP Z, FINTECLAS SUB 2 LD (PROTA),A JP FINTECLAS VERABAJO LD A,(JOY+1) BIT 2,A JP Z, FINTECLAS ;;TECLA ABAJO PULSADA;; ;;SI NO LLEGA ABAJO DEL TODO, SUMA 2 A LA COORDENADA Y;; LD A,(PROTA) CP ALPANA-16 JP Z, FINTECLAS ADD A,2 LD (PROTA),A FINTECLAS

VOLCADO DEL BUFFER CON LDI (II): INICIO Y LECTURA DEL TECLADO

Como ya he dicho, el programa se ejecuta desde la dirección 24000. Esto corresponde a la memoria contenida. Lo primero que hacemos es deshabilitar las interrupciones, ya que no las vamos a usar de momento y colocar la pila.


ORG 24000 DI LD SP, $FA00


Luego hay una serie de rutinas que sirven para crear las tablas que necesitamos para que el invento funcione y de momento no nos interesan.

A partir de la línea 102, tenemos lo siguiente:


XOR A OUT ($FE),A CALL BOREAL ;BORRA LA PANTALLA REAL LD HL,PANTVIR ;PINTA LAS RAYAS EN EL BUFFER LD DE,PANTVIR+1 LD (HL),1 LD BC,TAMPAN-1 LDIR JP INICIO

Con XOR A, ponemos A=0 y con OUT (FEh),A ponemos el borde negro.

Llamamos a la rutina que nos borra la pantalla real:


;;BORRA LA PANTALLA REAL BOREAL ;;BORRA LOS GRAFICOS LD HL,$4000 LD D,H LD E,L INC E LD (HL),0 LD BC,$1800-1 LDIR ;;BORRA LOS ATRIBUTOS LD HL,$5800 LD D,H LD E,L INC E LD (HL),6 ;PONE COLOR AMARILLO LD BC,$300-1 LDIR RET

Cargamos HL con el inicio de la pantalla real (4000h) y DE con HL+1 (4001h). Metemos en la primera dirección un cero y hacemos LDIR con BC igual al tamaño de la zona de los gráficos.

Para los atributos hacemos lo mismo desde el inicio de la zona de atributos, pero metemos un 6, con lo que pintamos la pantalla de amarillo.

Este método no es que sea muy optimizado, pero me da lo mismo, ya que aquí la velocidad no importa demasiado. Al borrar la pantalla real conviene hacer un HALT antes, para que el efecto sea más uniforme.

Después de esto, pintamos las rallas en el buffer y saltamos a INICIO que ya pertenece a la zona no contenida y que está en APRINCIPAL.ASM.

Para no liar mucho el asunto, voy a ir directamente a la lectura del teclado.


;;;;;;;;LECTURA DE TECLAS;;;;;;; ;;;LEO LOS PUERTOS NECESARIOS Y ACTUALIZO EL REGISTRO L;;; ;;;REGISTRO L: BIT 0=1 DERECHA PULSADA ;;;REGISTRO L: BIT 1=1 IZQUIERDA PULSADA ;;;REGISTRO L: BIT 2=1 DABAJO PULSADA ;;;REGISTRO L: BIT 3=1 ARRIBA PULSADA ;;;REGISTRO L: BIT 4=1 DISPARO PULSADO NOJOY1 LD L,0 NOJOY23 LD A,$7F ;PARA EL DISPARO IN A,($FE) TSAL AND 1 JP NZ, NOJOY2 SET 4,L NOJOY2 LD A,$DF ;TECLA IZQUIERDA IN A, ($FE) TIZ AND 2 JP NZ, MIRATD JIZ SET 1,L JP MIRATAR LEEJOY ;LEE EL JOYSTICK LD A,$FF IN A,(31) JP FINTE1 MIRATD DERE1 LD A, $DF ;TECLA DERECHA IN A, ($FE) TDER AND 1 JP NZ, MIRATAR SET 0,L MIRATAR NOJOY4 LD A, $FB ;TECLA DE ARRIBA IN A, ($FE) SALBT AND 1 JP NZ, MIRATAB SET 3,L JP FINTEC MIRATAB QUITO2 LD A, $FD ;TECLA ABAJO IN A, ($FE) TARR89 AND 1 JP NZ, FINTEC SET 2,L FINTEC LD A,L FINTE1 LD (JOY+1),A ;METO EL RESULTADO EN JOY+1

Todo lo concerniente a la teoría sobre la lectura del teclado lo puedes ver aquí.

Yo lo que hago es ir leyendo las letras que me interesan, OPQA y disparo y dependiendo de si están pulsadas o no, pongo a 1 un determinado bit del registro L. Ni que decir tiene que primero hay que poner L a cero...

REGISTRO L: BIT 0=1 DERECHA PULSADA REGISTRO L: BIT 1=1 IZQUIERDA PULSADA REGISTRO L: BIT 2=1 DABAJO PULSADA REGISTRO L: BIT 3=1 ARRIBA PULSADA REGISTRO L: BIT 4=1 DISPARO PULSADO

Por ejemplo, si pulsamos a la vez la tecla derecha, la de arriba y el disparo, L=00011001b

En FINTEC paso el valor resultante de L al registro A, y lo guardo en la dirección JOY+1.

He dejado por ahí un código que en este ejemplo no uso, y es la lectura del Joystick Kempston en LEEJOY. Lo usaré más adelante.

El valor que voy dando al registro L según la tecla que esté pulsada no es trivial. Coincide con el valor que resulta de leer el Joystick, por lo que así unifico el resultado independientemente de que el personaje se maneje con teclado o Joystick.

VOLCADO DEL BUFFER CON LDI (I): ORGANIZACIÓN DE LA MEMORIA

Este primer ejemplo va a consistir en realizar un programa que nos maneja (e imprime) a un sprite protagonista que podemos mover con las teclas OPQA y dispara con espacio; seis sprites (cinco de 2x2 caracteres y uno de 3x3) que podríamos llamar enemigos y el disparo.

Si no lo has hecho antes, bájate el código fuente de aquí VOLCADO DEL BUFFER CON LDI.

¿Qué significa el título de esta entrada?
A la hora de mover gráficos por la pantalla del spectrum, la forma más habitual de hacerlo es imprimir el gráfico, borrar el gráfico, mover el gráfico y volverlo a imprimir. Esto es lo que da sensación de movimiento. El problema es que la pantalla del Spectrum se refresca cada cierto tiempo, y si el haz de electrones coincide (que es muy probable) con la zona de tu gráfico cuando estás borrando e imprimiendo, se produce un parpadeo.
Esto te viene muy bien explicado aquí.
En la mayoría de juegos antiguos (digamos antes de 1984) se pueden ver estos molestos parpadeos.
Se crearon técnicas para disimularlos, pero aún así se notaba algo raro en los gráficos.

Una manera de solucionar esto es realizar todas las operaciones necesarias que se hagan en un buffer. Reservamos una zona de la memoria para estos menesteres y cuando hemos acabado con todos los sprites la volcamos a la pantalla real.

El problema de esto es que es mucho más lento que imprimir directamente en la pantalla, ya que hay que mover muchos datos. Por ello, la zona de juego no conviene que sea muy grande.

Para este volcado se podría usar la instrucción LDIR, pero es más rápido usar tantos LDI como caracteres de ancho tenga el buffer.

Todo esto es lo que voy a intentar explicar en esta sección.

Para que veas cómo va la rutina, ensambla el programa ejecutando AENSAMBLA.BAT y ejecútalo en un emulador desde la dirección 24000. Podrás mover a nuestro héroe, disparar y ver a los enemigos.

ORGANIZACIÓN DE LA MEMORIA

A la hora de programar un juego es muy importante organizar bien la memoria para que luego no nos dé problemas. Echa un vistazo en APRINCIPAL.ASM.

INCLUDE "CONTENIDA.ASM" ORG 32768 ;;;;;PANTALLA VIRTUAL;;;;;;;;;;;; PANTVIR DS TAMPAN

• Al principio del todo aparece un INCLUDE "CONTENIDA.ASM". Como he comentado anteriormente, la memoria contenida llega hasta la dirección 32768 (8000h). Yo uso desde la dirección 24000 (5dc0h). Es cierto que hay más memoria contenida que se puede usar, en concreto desde el buffer de la impresora 23296 (5B00h), pero no suelo usar esas direcciones. Es una manía. Sólo apuré tanto en Knightmare 2ZX, ya que anduve muy justo de memoria. Pero si nos hace falta, podremos tirar de ellas.

• Después pongo el origen del código en 32768. A partir de aquí va el buffer de la pantalla que lo he llamado PANTVIR. Su tamaño es TAMPAN que si miras al principio de CONTENIDA no es otra cosa que multiplicar le número del columnas por el de filas de nuestro buffer.  

ANPAN EQU 24 ;ANCHO DE LA PANTALLA ANPANA EQU ANPAN*8 ;ANCHO PANTALLA EN ALTA ALPAN EQU 16 ;ALTO DE LA PANTALLA ALPANA EQU ALPAN*8 ;ALTO DE LA PANTALLA EN ALTA RESOLUCION TAMPAN EQU ALPANA*ANPAN ;TAMAÑO DEL BUFFER DIRPAN EQU $4064 ;DIRECCION DE PANTALLA DONDE SE ;PONE EL CUADRO

En este caso, el ancho de pantalla es de 24 caracteres, el alto es de 16, por lo tanto, el tamaño del buffer será 24*16*8=3072 bytes. Si buscas la etiqueta TAMPAN en APRINCIPAL.TXT, verás que tiene el valor C00h que en decimal es 3072. Vamos bien.

• Al final de la memoria es donde coloco el resto del código que no está en el bucle principal.

INCLUDE "ARUTINAS.ASM" INCLUDE "ASPRITES.ASM" INCLUDE "ATABLAS.ASM" ;;;;;TABLA DE COORDENADAS PARA VOLCADO;;;;; TVOLCADO DS 320 ;;AQUI GUARDAMOS LOS FONDOS DEL BUFFER QUE SE MACHACAN AL IMPRIMIR LOS SPRITES FONDOS ORG $F500 ;;;;;TABLA DE COORDENADAS PARA IMPRIMIR;;;;; TABCOOR ORG $F800 DS 192 DATFON DS 100 ;DATOS DE LA TABLA DE RECUPERACION DE LOS FONDOS ;0=ALTURA/2, 1=ANCHURA, 2,3=DIR BUFFER PANTALLA, 4,5=DONDE SE GUARDA TABCOO1 ORG $F900 DS 192 SPIMP DS 20 ;COLA DE LOS SPRITES QUE SE IMPRIMEN ;;;;TABLA PARA LAS ROTACIONES;;;; ORG $FA00

Incluyo las rutinas, los gráficos y las tablas para el control de los sprites.

• Después va TVOLCADO. Es una tabla que creo en CONTENIDA con la primera dirección del cada línea de la pantalla real para que el volcado del buffer sea más rápido. Reservo 320 bytes.

• Desde F500h hasta F800h está FONDOS, donde guardo el fondo del buffer que se machaca al pintar el sprite y que se recuperará después de volcar el buffer. Son 768 bytes pero depende del número de sprites que pinte y de su tamaño.

• De F800h a FA00 están TABCOOR y TABCOO1, donde creo la tabla de direcciones de la primeras primeras líneas del buffer. Así, sabiendo la coordenada Y del sprite es muy rápido hallar la dirección donde imprimirle.

• Para aprovechar memoria, y ya que de F800h a F900h hay 255 y sólo uso 192 como mucho (es la coordenada Y máxima que puedo usar) meto DATFON. Es una tabla que voy creando para meter los datos de los fondos guardados al imprimir cada sprite. Ocupa 6 bytes por sprite con lo que, en principio, con 60 bytes tenemos de sobra.

• Lo mismo pasa con con SPIMP. Aprovecho 20 bytes para crear la cola de los sprites que tengo que imprimir. Son 2 bytes por sprite, osea que con 20 me vale

• A partir de FA00h y hasta el final meto una tabla con los desplazamientos y rotaciones necesarios para mover los gráficos de dos en dos pixels como mínimo. Aunque nos ocupa memoria (unos 1500 bytes), nos ahorra una gran cantidad de tiempo.

• El stack lo pongo al principio de CONTENIDA en FA00h ya que a partir de F900h sólo uso 192+20=212 bytes, con lo que tengo 43 para manejar la pila. SP siempre lo pongo en memoria NO contenida.

Todo esto es sólo para comentar la estructuración de la memoria. En sucesivas entregas explicaré para que sirven todas estas tablas y cómo se usan