Merge pull request 'Añadidos los días 2, 3 y 4 al tutorial en español de Uxn' (#1) from jota/compudanzas:tutorial_de_uxn_días_2_a_4 into main

Reviewed-on: #1
This commit is contained in:
sejo 2022-01-07 21:13:54 +00:00
commit abaec8f8ce
3 changed files with 2825 additions and 4 deletions

File diff suppressed because it is too large Load Diff

View File

@ -1,3 +1,773 @@
# tutorial uxn: día 3
# tutorial de uxn: día 3, saltos condicionales y el teclado/controlador
traducción en proceso
¡esta es la tercera sección del tutorial uxn!
=> ./tutorial_de_uxn.gmi {tutorial de uxn}
aquí introducimos el uso del dispositivo controlador en la computadora uxn varvara: esto nos permitirá añadir interactividad a nuestros programas, y empezar a discutir el flujo de control en uxntal.
también hablamos de las instrucciones lógicas y de manipulación de la pila en uxntal.
# el dispositivo controlador
el dispositivo controlador del ordenador varvara nos permite leer las entradas del teclado y/o de los botones del controlador.
la definición de sus puertos tendría el siguiente aspecto en un programa típico:
```
|80 @Controlador [ &vector $2 &boton $1 &tecla $1 ]
```
## el byte de botón
el byte de botón codifica en cada uno de sus ocho bits el estado de ocho "botones" diferentes, basados en la disposición del controlador de NES.
=> https://wiki.nesdev.com/w/index.php/Standard_controller controlador NES estándar
numerando los bits de derecha a izquierda, y de 0 a 7, las teclas correspondientes (y los botones de NES) son
* 0: Ctrl (botón A)
* 1: Alt (botón B)
* 2: Shift (botón de selección)
* 3: Esc (botón de inicio)
* 4: Arriba
* 5: Abajo
* 6: Izquierda
* 7: Derecha
codificar los estados de los botones de esta manera nos permite presionar y leer muchas de estas teclas al mismo tiempo.
## el byte de la tecla
el byte de la tecla almacena el código ascii de la tecla del teclado que se está pulsando en ese momento.
la diferencia entre el byte 'de la tecla' y el byte 'de botón' puede ser confusa, especialmente cuando se ejecuta varvara desde uxnemu donde los botones están en el mismo lugar que las teclas.
una posible manera de recordar podría ser pensar en el byte 'botón' como refiriéndose a un controlador de gamepad.
## el vector del controlador
en el contexto de la programación de uxn, un vector se refiere a una dirección en la memoria principal donde se asigna a uxn para que salte cuando ocurra un evento específico.
en el caso del vector controlador, este evento específico consiste en cada vez que se pulsa o suelta una tecla.
en otras palabras: uxn saltará a la dirección asignada como vector controlador, cada vez que se pulse o suelte una tecla.
la siguiente línea de código asignaría ese vector, utilizando la dirección absoluta de la etiqueta en-controlador:
```
;en-controlador .Controlador/vector DEO2
```
¡veamos a continuación como funcionaría!
# flujo de control: subrutinas vectoriales
hasta ahora nuestros programas uxntal han seguido un flujo lineal: comienzan en la dirección 0100, y terminan en la primera instrucción BRK que se encuentra.
podemos pensar en estos programas como rutinas de configuración: configuran los colores del sistema, pueden dibujar o imprimir algunas cosas, y luego dejan a uxn esperando. ¿qué estaría esperando uxn?
sí, una opción sería: ¡esperar la entrada del teclado!
vamos a empezar a organizar nuestros programas uxntal en términos de subrutinas que corresponden a diferentes vectores.
cada una de estas subrutinas terminará con la instrucción BRK, para que puedan hacer que uxn vuelva al estado de espera.
## subrutina del vector controlador
para ilustrar ese comportamiento, leamos el siguiente programa.
este utiliza el procedimiento de dibujo de sprites que probamos el día anterior, pero hace que ocurra sólo cuando se pulsa una tecla. al principio, la pantalla está vacía, y cuando pulsamos una tecla se dibuja un cuadrado:
```
( hola-teclado.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
|80 @Controlador [ &vector $2 &boton $1 &tecla $1 ]
( programa principal )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( asignar vector del controlador )
;en-controlador .Controlador/vector DEO2
BRK
( ejecutar este código cada vez que se pulse o suelte una tecla )
@en-controlador ( -> )
( establecer coordenadas x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establecer la direccion del sprite )
;cuadrado .Pantalla/direc DEO2
( dibujar el sprite en el fondo )
( usando el color 1 para el contorno )
#01 .Pantalla/sprite DEO
BRK
( sprite )
@cuadrado ff81 8181 8181 81ff
```
bonito, ¿no?
ahora, ¿cómo podemos realizar diferentes acciones dependiendo de la tecla que se haya pulsado?
en primer lugar, tenemos que hacer que nuestro programa sepa qué tecla se ha pulsado para que pueda actuar en consecuencia.
para ello, veamos algunas instrucciones uxntales nuevas.
# instrucciones de comparación y lógica
## instrucciones de comparación
uxntal tiene cuatro instrucciones para comparar los dos primeros elementos de la pila:
* EQU: empuja 01 hacia abajo en la pila si los dos elementos superiores de la pila son iguales, o empuja 00 en caso contrario ( a b -- a==b )
* NEQ: empuja 01 hacia abajo en la pila si los dos elementos superiores de la pila no son iguales, o empuja 00 en caso contrario ( a b -- a!=b )
* GTH: empuja 01 hacia abajo en la pila si el primer elemento es mayor que el segundo, o empuja 00 en caso contrario ( a b -- a>b )
* LTH: empuja 01 hacia abajo en la pila si el primer elemento es menor que el segundo, o empuja 00 en caso contrario ( a b -- a>b )
podemos pensar en los resultados empujados por estas instrucciones como banderas booleanas: son 01 si la comparación fue verdadera, y son 00 si fue falsa.
el siguiente código leerá el valor de la tecla del controlador, y empujará a la pila una bandera correspondiente a que sea igual al carácter 'a':
```
.Controlador/tecla DEI ( lee la tecla y la empuja hacia abajo en la pila )
LIT 'a ( empuja el código ascii del carácter 'a' )
EQU ( compara ambos bytes y empuja 01 si son iguales, 00 si no )
```
EQU2, NEQ2, GTH2 y LTH2 funcionarán de la misma manera, pero comparando cortos en lugar de bytes.
## instrucciones lógicas
uxntal tiene tres instrucciones lógicas a nivel de bit.
pueden funcionar como operadores lógicos que utilizan como operandos las banderas dadas por las instrucciones de comparación que hemos comentado anteriormente:
* AND: realiza un AND a nivel de bits con los dos elementos superiores de la pila, y empuja el resultado ( a b -- a&b )
* ORA: realiza un OR a nivel de bits con los dos primeros elementos de la pila, y empuja el resultado ( a b -- a|b )
* EOR: realiza un OR exclusivo a nivel de bits con los dos primeros elementos de la pila, y empuja hacia abajo el resultado ( a b -- a^b )
AND2, ORA2, EOR2 funcionarán de la misma manera, pero con cortos en lugar de bytes.
### AND
lo siguiente empujará hacia abajo en la pila una bandera que indica si el byte tecla está entre 30 y 39 inclusive, usando 01 para representar 'verdadero', y 00 para representar 'falso0:
```
.Controlador/tecla DEI ( lee la tecla y la introduce en la pila )
#2f GTH ( ¿es mayor que 2f? empuja la bandera a la pila )
Controlador/tecla DEI ( lee la tecla y la introduce en la pila )
#3a LTH ( ¿es menor que 3a? empuja la bandera a la pila )
AND ( aplica un AND a las banderas de la pila, y empuja el resultado a la pila )
```
que la instrucción sea bitwise significa que aplica la operación AND a cada uno de los bits de los operandos.
si ambas banderas fueran "verdaderas":
```
0000 0001 ( verdadero )
AND 0000 0001 ( verdadero )
----------
0000 0001 ( verdadero )
```
si alguno (o ambos) de los indicadores fuera "falso":
```
0000 0001 ( verdadero )
AND 0000 0000 ( falso )
----------
0000 0000 ( falso )
```
como estos indicadores sólo utilizan el bit menos significativo (el bit más a la derecha) para codificar su valor, un AND a nivel de bits es equivalente a un AND lógico convencional.
### OR
el siguiente código empujará una bandera hacia abajo en la pila si el byte tecla es '1' o 'a':
```
.Controlador/tecla DEI ( lee la tecla y la empuja a la pila )
LIT '1 EQU ( ¿es '1'? empuja la bandera a la pila )
.Controlador/tecla DEI ( lee la tecla y empujar a la pila )
LIT 'a EQU ( ¿es 'a'? empuja la bandera a la pila )
ORA ( aplica un OR a las banderas en la pila, y empuja el resultado en la pila )
```
cuando alguna o ambas banderas son verdaderas, la bandera será verdadera:
```
0000 0001 ( verdadero )
OR 0000 0000 ( falso )
----------
0000 0001 ( verdadero )
```
sólo cuando ambas banderas sean falsas, la bandera resultante será falsa.
### EOR
un EOR exclusivo es una operación lógica que tiene un resultado de verdadero sólo cuando una u otra entrada es verdadera. si ambas entradas son verdaderas, o si ambas entradas son falsas, el resultado es falso.
basándose en este comportamiento, esta instrucción puede utilizarse para invertir el valor de una bandera utilizando un valor especial en el que el/los bit(s) que queremos invertir se pongan a 1. este tipo de valores se llaman máscaras.
por ejemplo, el siguiente código empujará una bandera correspondiente a que la te sea mayor o igual a 20, calculando primero si es menor que 20, y luego invirtiendo el resultado:
```
.Controlador/tecla DEI ( lee la tecla y la empuja a la pila )
#20 LTH ( ¿es menor que 20? empuja la bandera a la pila )
#01 EOR ( invierte el bit más a la derecha de la bandera y empuja el resultado a la pila )
```
cuando la bandera original es verdadera, lo que significa que el valor de la tecla es menor que 20, el EOR la invertirá y la hará falsa: el valor NO es mayor o igual que 20:
```
0000 0001 ( verdadero )
EOR 0000 0001 ( máscara )
----------
0000 0000 ( falso )
```
como podemos ver, debido a que los dos bits de entrada son 1, el bit de salida es 0.
cuando la bandera original es falsa, lo que significa que el valor NO es menor que 20, el EOR lo invertirá y lo hará verdadero: el valor es mayor o igual que 20:
```
0000 0000 ( falso )
EOR 0000 0001 ( máscara )
----------
0000 0001 ( verdadero )
```
observe que la máscara es la misma, y el resultado es el valor opuesto de la bandera.
# flujo de control: saltos condicionales
ok, ahora nuestros programas pueden identificar y almacenar en banderas si un valor (como la tecla de teclado leída) es un valor específico, o dentro de algún rango.
¿cómo podemos usar estas banderas para tener comportamientos condicionales en nuestros programas, donde se toman diferentes acciones dependiendo de los resultados?
¡introduzcamos otro conjunto de nuevas instrucciones para que uxn rompa su flujo lineal!
## instrucciones para saltos
* JMP: salto incondicional a la dirección de la pila ( direc -- )
* JCN: salto condicional: toma una dirección y un valor de la pila, y si el valor no es 00, salta a la dirección; en caso contrario continúa con la siguiente instrucción ( valor direc -- )
en modo byte, las direcciones que utilizan estas instrucciones son de un byte.
estas direcciones de un byte son relativas y con signo: indican cuántos bytes hay que saltar en la memoria principal desde la posición actual del contador de programa, ya sea hacia delante (positivo) o hacia atrás (negativo). el rango de estas direcciones relativas es de -128 a 127 inclusive.
en modo corto, las direcciones que toman estas instrucciones son absolutas (es decir, de dos bytes de longitud), pero el valor que toma JCN para decidir sigue siendo un byte.
## runas para direcciones
hay varias runas que se refieren a direcciones y etiquetas. uxnasm las lee y las convierte a los valores binarios correspondientes.
en los días anteriores ya hablamos de algunas de ellas; esta es una recapitulación de las mismas, y una introducción de las nuevas:
* dirección literal en la página cero: .etiqueta (un byte)
* dirección literal en memoria principal: ;label (un corto)
* Dirección literal relativa en la memoria principal: ,label (un byte)
* dirección literal en la memoria principal: :label (un byte)
para definir las etiquetas, utilizamos:
* definición de etiquetas: @etiqueta
* definición de la sub-etiqueta: &subetiqueta, donde esta sub-etiqueta será "hije" de la etiqueta previamente definida
y finalmente, para referirse a las etiquetas dentro de nuestro código uxntal, tenemos los siguientes casos:
* para una etiqueta principal: utilizar el nombre de la etiqueta
* para una subetiqueta: utilizar etiqueta/subetiqueta
* para una subetiqueta local: utilizar &subetiqueta
## salto condicional
¡unamos todo esto!
la siguiente subrutina en-controlador ilustra el uso de los saltos, dibujando nuestro sprite sólo cuando la tecla que se pulsó fue '1':
```
@en-controlador
.Controlador/tecla DEI ( lee la tecla )
LIT '1 EQU ( ¿es '1'? )
( salta a dibuja-sprite si es el caso )
,&dibuja-sprite JCN
,&fin JMP ( si no, salta al final )
&dibuja-sprite
( fijar coordenadas x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establece la dirección del sprite )
;cuadrado .Pantalla/direc DEO2
( dibujar el sprite en el fondo )
( usando el color 1 para el contorno )
#01 .Pantalla /sprite DEO
&fin
BRK
```
nótese el uso de sub-etiquetas "dentro" (después) de en-controlador.
también note como la expresión ,&subetiqueta corresponde a la dirección relativa (,) que se necesita para saltar a esa ubicación en el código nombrado con una sub-etiqueta local (&).
estas direcciones relativas, de un byte, son utilizadas por JCN o JMP.
## saltos condicionales
el siguiente código ilustra el uso de muchas condiciones: el color del sprite cambia en consecuencia si se pulsan las teclas 1, 2 o 3.
```
@en-controlador
( establecer coordenadas x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establecer direccion del sprite )
;cuadrado .Pantalla/direc DEO2
.Controlador/teclaDEI LIT '1 EQU ( ¿es la tecla '1'? )
,&color-1 JCN ( salta al color-1 si es el caso )
.Controlador/tecla DEI LIT '2 EQU ( ¿es la tecla '2'? )
,&color-2 JCN ( salta al color-2 si es el caso )
Controlador/tecla DEI LIT '3 EQU ( ¿es la tecla '3'? )
,&color-3 JCN ( salta al color-3 si es el caso )
( en cualquier otro caso, terminar )
BRK
&color-1
( dibujar el sprite en el fondo )
( usando el color 1 para el contorno )
#01 .Pantalla/sprite DEO
BRK
&color-2
( dibujar sprite en el fondo )
( usando el color 2 para el contorno )
#02 .Pantalla/sprite DEO
BRK
&color-3
( dibujar sprite en el fondo )
( usando el color 3 para el contorno )
#03 .Pantalla/sprite DEO
BRK
BRK
```
observe cómo las condiciones se escriben una tras otra: siempre que una bandera es falsa, JCN permite a uxn continuar con la siguiente instrucción en memoria.
también note que este código no está optimizado para el tamaño o la velocidad, sino para la legibilidad.
estaría en tí, por ejemplo, realizar una aritmética con el valor de la tecla que se pulsó para calcular el color a asignar al sprite - ¡podrías inspirarte en tu macro PRINT-DIGIT del día 1!
# manipulación de la pila
hasta ahora hemos estado usando la pila como un lugar para almacenar operandos de instrucciones y sus resultados, ¡pero aún no hemos usado todo el potencial de este entorno basado en la pila!
## instrucciones de pila
uxntal tiene seis instrucciones que actúan sobre los elementos de la pila más cercanos a la parte superior:
* POP: Eliminar el elemento superior de la pila ( a -- )
* DUP: Duplicar; empujar una copia del elemento superior ( a -- a a )
* SWP: Intercambiar; cambiar el orden de los dos primeros elementos de la pila ( a b -- b a )
* NIP: Elimina el segundo elemento superior de la pila ( a b -- b )
* OVR: "Over" o encima; empuja una copia del segundo elemento superior ( a b -- a b a )
* ROT: Rotar; reordenar los tres primeros elementos de la pila de forma que el tercero esté ahora en la parte superior ( a b c -- b c a )
en modo corto, POP2, DUP2, SWP2, NIP2, OVR2 y ROT2 realizan las mismas acciones pero utilizando cortos en lugar de bytes.
## ejemplos
vamos a utilizar estas instrucciones de muchas maneras diferentes durante los próximos días.
los siguientes son algunos ejemplos basados en fragmentos de código que ya hemos discutido.
ten en cuenta que el uso de estas instrucciones puede contribuir a que el código sea difícil de seguir o leer, por lo que siempre será una buena idea utilizarlas dentro de macros o tener comentarios en el código explicando lo que está sucediendo :)
### dígito ascii: duplicar e intercambiar
discutimos anteriormente este segmento de código, que empuja una bandera que responde si la tecla que se pulsa tiene un código ascii entre 30 y 39, ambos inclusive (es decir, calcula si un byte tiene un código ascii correspondiente a un dígito decimal)
```
.Controlador/tecla DEI ( lee la tecla y la empuja a la pila)
#2f GTH ( ¿es mayor que 2f? empuja la bandera a la pila )
Controlador/tecla DEI ( lee la tecla y la introduce en la pila )
#3a LTH ( ¿es menor que 3a? empuja la bandera a la pila )
AND ( aplica un AND a las banderas en la pila, y empuja el resultado en la pila )
```
en lugar de leer la tecla dos veces, podríamos hacerlo una vez, y luego usar la instrucción DUP para copiar el valor:
```
.Controlador/tecla DEI DUP ( leer y duplicar la tecla )
```
la pila después de estas instrucciones tendría dos copias del valor de la tecla:
```
tecla tecla <- arriba
```
entonces en nuestro código podemos seguir añadiendo la primera comparación:
```
#2f GTH ( ¿es mayor que 2f? empuja la bandera en la pila )
```
después de esto, la pila se vería como:
```
tecla bandera1 <- arriba
```
para realizar la segunda comparación, necesitamos tener la tecla en la parte superior, no la bandera.
¿cómo lo conseguimos? así es, utilizando un SWP:
```
SWP ( poner la tecla en la parte superior )
```
ahora la pila se ve así:
```
bandera1 tecla <- arriba
```
finalmente podemos proceder a la comparación y al AND
```
#3a LTH ( ¿es menor que 3a? empuja la bandera en la pila )
AND ( aplica un AND a las banderas en la pila, y empuja el resultado en la pila )
```
terminando con una pila que sólo tiene el resultado:
```
resultado <- arriba
```
el código completo se leería como:
```
.Controlador/tecla DEI DUP ( lee y duplica la tecla )
#2f GTH ( ¿es mayor que 2f? empuja la bandera a la pila )
SWP ( poner la tecla en la parte superior )
#3a LTH ( ¿es menor que 3a? empuja la bandera a la pila )
AND ( aplica un AND a las banderas en la pila, y empuja el resultado en la pila )
```
el primer código se ensambla en 13 bytes, y éste se ensambla en 12 bytes. quizá no haya demasiada diferencia en ese aspecto.
sin embargo, una ventaja más significativa es que esta nueva rutina ahora necesita su entrada empujada hacia abajo en la pila sólo al principio.
en el caso que acabamos de discutir la entrada es la tecla que se presiona, pero podríamos fácilmente tener como entrada cualquier otro valor de la pila.
esto implica que podríamos escribir la rutina como una macro:
```
ASCII-DIGIT { DUP #2f GTH SWP #3a LTH AND } ( byte -- bandera )
```
y utilizarla con el byte que queramos:
```
#30 ?ASCII-DIGIT ( empuja 01 hacia abajo en la pila )
#20 ?ASCII-DIGIT ( empuja 00 hacia abajo en la pila )
.Controlador/tecla DEI ?ASCII-DIGIT ( empuja la bandera correspondiente a la pila )
```
### duplicados para los condicionales
otro caso anterior en el que repetimos muchas lecturas de la tecla del teclado fue cuando usamos las condicionales múltiples.
podríamos reescribirlo usando varios DUPs y POPs:
```
@en-controlador
( establecer coordenadas x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establecer dirección del sprite )
;cuadrado .Pantalla/direc DEO2
.Controlador/tecla DEI ( leer tecla )
DUP LIT '1 EQU ( ¿es la tecla '1'? )
,&color-1 JCN ( salta al color-1 si es el caso )
DUP LIT '2 EQU ( ¿es la tecla '2'? )
,&color-2 JCN ( salta al color-2 si es el caso )
DUP LIT '3 EQU ( ¿es la tecla '3'? )
,&color-3 JCN ( salta al color-3 si es el caso )
( en cualquier otro caso, termina )
POP
BRK
&color-1
( dibujar el sprite en el fondo )
( usando el color 1 para el contorno )
#01 .Pantalla/sprite DEO
POP
BRK
&color-2
( dibujar sprite en el fondo )
( usando el color 2 para el contorno )
#02 .Pantalla/sprite DEO
POP
BRK
&color-3
( dibujar sprite en el fondo )
( usando el color 3 para el contorno )
#03 .Pantalla/sprite DEO
POP
BRK
BRK
```
¿puedes decir por qué necesitamos todos esos POPs?
pista: compara el estado final de la pila con y sin las instrucciones POP.
¡en los próximos días veremos más usos y ejemplos de manipulación de la pila!
# botón del controlador
la última cosa que discutiremos hoy es el uso del byte del botón del controlador en la computadora varvara.
como ya hemos mencionado, la principal diferencia aquí es que este byte mantiene el estado de 8 botones en cada uno de sus bits.
dependiendo de nuestra aplicación, podríamos necesitar permitir que algunos de estos botones sean presionados al mismo tiempo.
en ese caso, ¿cómo podríamos aislar cada uno de los bits para comprobar su estado individualmente?
conoce las máscaras AND a nivel de bits
## máscara AND
una máscara AND es un valor especial que utilizaremos para mantener o perder bits específicos de otro valor dado, como el byte del botón del controlador.
en nuestra máscara AND, pondremos como 1 los bits en las posiciones en las que queramos mantener el valor de los bits de entrada. las posiciones en las que los bits de la máscara sean 0 se convertirán en 0 en la entrada.
por ejemplo, digamos que queremos ver si el bit número 4, que corresponde al botón "arriba", está encendido o apagado, independientemente del estado de los otros botones.
nuestra máscara AND tendrá un 1 en el bit número 4 (de derecha a izquierda, y empezando por el 0), y 0 en el resto:
```
0001 000: 10
```
¿qué pasaría si se pulsa el botón A (tecla Ctrl), con su estado codificado en el bit 0, y nada más?
```
0000 0001 ( botón )
AND 0001 0000 ( máscara )
----------
0000 0000 ( resultado )
```
¿qué ocurre si se pulsa el botón de arriba?
```
0001 0000 ( botón )
AND 0001 0000 ( máscara )
----------
0001 0000 ( resultado )
```
¿y si se pulsan tanto Up como Ctrl?
```
0001 0001 ( botón )
AND 0001 0000 ( máscara )
----------
0001 0000 ( resultado )
```
así vemos cómo la máscara nos permite aislar efectivamente el bit que nos importa, independientemente del estado de los otros bits.
aplicar esta máscara sería tan sencillo como escribir:
```
#10 AND ( aplicar máscara 0001 000 )
```
## ejemplo: dibujar con flechas y Ctrl
=> ./img/screenshot_uxn-draw-with-keyboard.png captura de pantalla de un posible resultado de la ejecución del siguiente programa; muestra un rastro dibujado con cuadrados rellenos o delineados.
el siguiente programa uxntal permite dibujar utilizando las teclas de las flechas y la tecla Ctrl (botón A).
las flechas mueven la posición de un sprite, y al pulsar Ctrl mientras se mueve lo dibujará con los colores inversos en relleno y trazo.
observa el uso de las máscaras AND, los saltos condicionales y algunas operaciones de apilamiento.
```
( dibujar-con-teclado.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite ]
|80 @Controlador [ &vector $2 &boton $1 &tecla $1 ]
( programa principal )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( asignar vector del controlador )
;en-controlador .Controlador/vector DEO2
( establecer coordenadas iniciales x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establece la dirección del sprite )
;cuadrado .Pantalla/direc DEO2
BRK
@en-controlador ( -> )
.Controlador/boton DEI DUP ( leer y duplicar el byte del boton )
#01 AND ( aislar el bit 0, correspondiente a Ctrl )
,&relleno JCN ( si el bit no es 0, saltar al relleno, si no, continuar )
&contorno
#01 .Pantalla/sprite DEO ( dibujar contorno )
,&comprobar-filas JMP ( continuar con la comprobación de las filas )
&relleno
#04 .Pantalla/sprite DEO ( dibujar relleno )
&comprobar-filas
( usar el byte del botón de la pila )
DUP #10 AND ( aislar el bit 4, correspondiente a Arriba )
,&arriba JCN ( saltar si no es 0 )
DUP #20 AND ( aísla el bit 5, correspondiente a Abajo )
&down JCN ( salta si no es 0 )
DUP #40 AND ( aislar el bit 6, correspondiente a Izquierda )
,&left JCN ( salta si no es 0 )
DUP #80 AND ( aísla el bit 7, correspondiente a Derecha )
&right JCN ( salta si no es 0 )
POP BRK
&arriba
.Pantalla/y DEI2 #0008 SUB2 .Pantalla/y DEO2 ( disminuye y )
POP
BRK
&abajo
.Pantalla/y DEI2 #0008 ADD2 .Pantalla/y DEO2 ( incremento y )
POP
BRK
&izquierda
.Pantalla/x DEI2 #0008 SUB2 .Pantalla/x DEO2 ( disminuye x )
POP
BRK
&derecha
.Pantalla/x DEI2 #0008 ADD2 .Pantalla/x DEO2 ( incremento x )
POP
BRK
BRK
( sprite )
@cuadrado ff81 8181 8181 81ff
```
algunas posibilidades para que practiques:
* modificar el código para que también responda a que pulses más de una flecha al mismo tiempo.
* convertir los incrementos y decrementos de las coordenadas en macros que tomen la dirección del puerto como entrada, y realizar una operación equivalente. estas dos líneas deberían funcionar usando la misma macro:
```
.Pantalla/x INCREMENTO
.Pantalla/y INCREMENTO
```
recuerde que .Pantalla/x es una dirección literal en la página cero, es decir, empuja un byte correspondiente a la dirección de la sub-etiqueta Pantalla/x :)
# posibilidades de práctica
¡aquí tienes otras ideas para que practiques con lo que hemos tratado hoy!
* dibujar un controlador virtual que muestre cuáles de sus botones, mapeados a teclas del teclado, están siendo presionados
* crear una especie de máquina de escribir que dibuje diferentes símbolos y mueva el cursor de dibujo dependiendo de la tecla que se haya pulsado
* dibujar un personaje que cambie su estado según la tecla que se haya pulsado. ¿tal vez utilizar múltiples fichas para dibujarlo?
* crea un simple tablero de tres en raya para dos jugadores: una tecla dibuja una X, otra dibuja una O, y las flechas permiten elegir la casilla a dibujar.
¡ten en cuenta que para un movimiento interactivo suave puede ser mejor utilizar el vector de pantalla que se llama 60 veces por segundo!
¡lo cubriremos en profundidad en el próximo día del tutorial!
# instrucciones del día 3
estas son todas las instrucciones uxntales de las que hemos hablado hoy
## instrucciones de comparación
* EQU: empuja 01 hacia abajo en la pila si los dos primeros elementos de la pila son iguales, o empuja 00 en caso contrario ( a b -- a==b )
* NEQ: empuja 01 hacia abajo en la pila si los dos primeros elementos de la pila no son iguales, o empuja 00 en caso contrario ( a b -- a!=b )
* GTH: empuja 01 hacia abajo en la pila si el primer elemento es mayor que el segundo, o empuja 00 en caso contrario ( a b -- a>b )
* LTH: empuja 01 hacia abajo en la pila si el primer elemento es menor que el segundo, o empuja 00 en caso contrario ( a b -- a&lt;b )
## lógica a nivel de bits
* AND: realiza un AND a nivel de bits con los dos primeros elementos de la pila, y empuja hacia abajo el resultado ( a b -- a&b )
* ORA: realiza un OR a nivel de bits con los dos primeros elementos de la pila, y empuja el resultado ( a b -- a|b )
* EOR: realiza un OR exclusivo a nivel de bits con los dos primeros elementos de la pila, y empuja hacia abajo el resultado ( a b -- a^b )
## saltos
* JMP: salto incondicional a la dirección de la pila ( direc -- )
* JCN: salto condicional: toma una dirección y un valor de la pila, y si el valor no es 00, salta a la dirección; en caso contrario continúa con la siguiente instrucción ( valor direc -- )
## pila
* POP: Quitar el elemento superior de la pila ( a -- )
* DUP: Duplicar; empujar una copia del elemento superior ( a -- a a )
* SWP: Intercambio; cambia el orden de los dos primeros elementos de la pila ( a b -- b a )
* OVR: "Over" o encima; empuja una copia del segundo elemento superior ( a b -- a b a )
* ROT: Rotar; reordenar los tres primeros elementos de la pila de forma que el tercero esté ahora en la parte superior ( a b c -- b c a )
# día 4
en el tutorial uxn día 4 cubrimos el uso del vector de pantalla para crear animaciones, ya sean interactivas o no.
=> ./tutorial_de_uxn_día_4.gmi {tutorial de uxn día 4}
¡también exploramos las posibilidades de usar "variables" en uxntal que pueden ayudarnos a crear programas más elaborados!
¡antes de entrar en materia, les invito a seguir explorando y también a tomarse un descanso!
¡manténgase en sintonía!
# apoyo
si te ha gustado este tutorial y te ha resultado útil, considera compartirlo y darle tu apoyo :)
=> ./apoyo.gmi {apoyo}

View File

@ -0,0 +1,969 @@
# tutorial uxn: día 4, variables y bucle de animación
¡esta es la cuarta sección del tutorial uxn!
=> ./tutorial_de_uxn {tutorial de uxn}
aquí hablamos del bucle de animación del ordenador varvara, a través de su vector de dispositivo de pantalla.
también hablamos del uso de la memoria del programa como un espacio para datos usando "variables". esto nos permite guardar y recuperar datos durante el tiempo de ejecución de nuestros programas, y puede ahorrarnos complejas luchas en la pila :)
# el vector pantalla
discutimos el dispositivo de pantalla de varvara en el día 2, pero nos saltamos su puerto vectorial para centrarnos en cómo dibujar con él:
```
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
```
ahora que ya tenemos el concepto de vectores de dispositivos en el tutorial de uxn día 3, ¡vamos a entrar de lleno en cómo usar el de la pantalla!
=> ./tutorial_de_uxn_día_3.gmi {tutorial de uxn día 3}
## asignación
la siguiente línea de uxntal asignaría la dirección absoluta de la etiqueta en-cuadro al vector pantalla:
```
;en-cuadro .Pantalla/vector DEO2
```
uxn saltará a la ubicación de la etiqueta a un ritmo de 60 veces por segundo: podemos utilizar la subrutina bajo en-cuadro para cambiar el contenido de la pantalla, generando animación, y/o también podemos utilizarla para otros propósitos relacionados con la temporización.
## una línea que crece
el siguiente programa demuestra un uso básico pero potente del vector pantalla: en cada fotograma, dibuja un píxel en las coordenadas x,y de la pantalla dadas, y añade 1 al valor de la coordenada x:
```
( hola-linea.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
( init )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( establecer coordenadas iniciales x,y )
#0008 .Pantalla/x DEO2
#0008 .Pantalla/y DEO2
( establecer vector de pantalla )
;en-cuadro .Pantalla/vector DEO2
BRK
@en-cuadro ( -> )
( dibujar un pixel en el fondo con el color 1 )
#01 .Pantalla/pixel DEO
( incrementar Pantalla/x )
.Pantalla/x DEI2 INC2 .Pantalla/x DEO2
BRK
```
nota que el código es muy similar al que escribimos el día 2 para dibujar una línea.
en ese, incrementamos manualmente el valor de Pantalla/x para dibujar 6 píxeles.
aquí, el código para incrementar Pantalla/x es llamado dentro de la subrutina en-cuadro en su lugar, haciendo que ocurra 60 veces por segundo.
## posibilidades de crecimiento
estos son algunos cambios para que los pruebes y practiques:
* ¿cómo harías que la línea creciera en vertical? y en diagonal?
* ¿cómo harías que la línea creciera en sentido contrario?
* ¿Cómo harías que la línea fuera punteada?
* ¿Cómo harías que la línea dejara de crecer en una determinada posición? (¡recuerda los saltos condicionales!)
* ¿cómo dibujarías utilizando un sprite en lugar de un píxel?
# variables
¡el vector de pantalla varvara abre todo un mundo de posibilidades!
merece señalar que muchas de estas posibilidades requieren formas de almacenar y recuperar datos entre fotogramas.
en el ejemplo anterior, estamos usando los puertos de pantalla para las coordenadas x e y como una forma de almacenar las coordenadas del pixel.
pero ¿qué sucede cuando queremos dibujar diferentes objetos, cada uno con su propio conjunto de coordenadas y otras características que pueden cambiar con el tiempo?
¡podemos utilizar etiquetas en la memoria del programa para conseguirlo!
## variables con direcciones absolutas
en cierto modo, al almacenar los datos de nuestros sprites ya hemos hecho algo así.
hemos etiquetado una sección de memoria con contenidos que no son instrucciones para uxn, sino datos; por ejemplo:
```
@cuadrado ff81 8181 8181 81ff
```
sin embargo, no hemos utilizado los datos directamente; hemos enviado su dirección al puerto del dispositivo de pantalla correspondiente.
### etiquetas
podríamos utilizar un sistema similar para almacenar, por ejemplo, las coordenadas x e y en lugar de los datos del sprite:
```
@pixel-x 0008
@pixel-y 0008
```
o si no quisiéramos iniciarlas aquí, podríamos definirlas de la siguiente manera:
```
@pixel-x $2
@pixel-y $2
```
recuerda que $2 crea un pad relativo de dos bytes: esto hace que pixel-y sea una etiqueta para una dirección en memoria dos bytes después de pixel-x. y cualquier código posterior ocurrirá dos bytes después de pixel-y.
también podríamos usar etiquetas y sub-etiquetas, de manera muy similar a como definimos los dispositivos y sus puertos:
```
@pixel [ &x $2 &y $2 ]
```
### instrucciones: LDA y STA
¿cómo podríamos leer (cargar) y escribir (almacenar) el contenido de la memoria en esas etiquetas?
aquí están las dos instrucciones que nos ayudarían:
* LDA: carga y empuja hacia abajo en la pila el valor en la dirección absoluta dada ( dirección -- valor )
* STA: almacena en la dirección absoluta dada el valor dado ( dirección valor -- )
como ya hemos comentado, una dirección absoluta siempre tendrá una longitud de dos bytes.
en el modo corto, LDA2 cargará un corto desde la dirección dada, y STA2 almacenará un corto en la dirección dada.
### ejemplos
como ejemplo, el siguiente código leería los dos bytes de pixel/x, los incrementaría en uno, y los almacenaría de nuevo en pixel/x:
```
;pixel/x LDA2 ( cargar pixel/x en la pila )
INC2 ( incrementar )
;pixel/x STA2 ( almacenar el resultado en pixel/x )
BRK
@pixel [ &x $2 &y $2 ]
```
nótese el uso de BRK antes de la etiqueta del píxel para que uxn se detenga antes de leer los datos como instrucciones.
lo siguiente es una variación que también duplica el nuevo valor de pixel/x para enviarlo a Pantalla/x:
```
;pixel/x LDA2 ( cargar pixel/x en la pila )
INC2 ( incrementar )
DUP2 ( duplicar el resultado )
;pantalla/x DEO2 ( establecer como pantalla/x )
;pixel/x STA2 ( y guardar el resultado en pixel/x )
BRK
@pixel [ &x $2 &y $2 ]
```
nótese que podríamos haber conseguido el mismo resultado almacenando el resultado, y luego recargándolo y enviándolo como salida.
aquí podemos ver cómo un DUP2 puede facilitar esa operación, siempre y cuando mantengamos un modelo mental (¡o tangible!) de lo que ocurre en la pila.
### valores iniciales
una posible ventaja de utilizar direcciones absolutas es que podemos iniciar el contenido de nuestras variables en el momento de ensamblaje, por ejemplo:
```
@pixel [ &x 0008 &y 0008 ]
```
estos contenidos iniciales cambiarán cada vez que usemos una instrucción STA allí :)
## variables en la página cero
las variables con dirección absoluta funcionan bien para los casos en los que queremos poder acceder a su contenido desde cualquier parte de nuestro programa (es decir, "variables globales").
sin embargo, uxn tiene un mecanismo mejor para esos casos: ¡la página cero!
como recordará, la página cero consiste en las primeras 256 direcciones de la memoria del programa. normalmente, un programa comienza en la dirección 0100, que es la siguiente dirección después de la página cero.
podemos referirnos a cualquiera de las 256 direcciones de la página cero utilizando un solo byte, en lugar de los dos bytes que se necesitan para las direcciones absolutas.
algo importante a tener en cuenta es que el contenido de la página cero no está presente en las roms uxn.
esto significa que una salvedad de usar variables allí, es que para iniciarlas necesitamos hacerlo durante el tiempo de ejecución, almacenando valores de la pila en ellas.
### etiquetas en la página cero
las etiquetas para la página cero funcionarían igual que antes; sólo tenemos que especificar que están en la página cero con una almohadilla absoluta:
```
|0000 ( página cero )
@pixel [ &x $2 &y $2 ]
```
para referirnos a ellas, utilizaríamos la runa punto (.) para las direcciones literales de página cero, en lugar de la runa dos puntos (;) para las direcciones literales absolutas.
### instrucciones: LDZ, STZ
las instrucciones para cargar (leer) y almacenar (escribir) desde y hacia la página cero son:
* LDZ: carga y empuja hacia abajo en la pila el valor en la dirección de la página cero dada ( dirección -- valor )
* STZ: almacena en la dirección de la página cero el valor dado ( dirección del valor -- )
en estas instrucciones, la dirección siempre será de un byte.
en el modo corto, LDZ2 cargará un corto desde la dirección dada, y STZ2 almacenará un corto en la dirección dada.
### ejemplos
el siguiente ejemplo consiste en la misma línea que crece, pero ahora utilizando la página cero para almacenar las coordenadas x e y del píxel en lugar de los puertos x e y de la pantalla.
en este caso el programa es más largo, pero puede ser visto como una buena plantilla para tener otras líneas que se comporten de diferentes maneras:
```
( hola-linea.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
( página cero )
|0000
@pixel [ &x $2 &y $2 ]
( init )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( establecer coordenadas iniciales x,y )
#0008 .pixel/x STZ2
#0008 .pixel/y STZ2
( establecer vector de pantalla )
;en-cuadro .Pantalla/vector DEO2
BRK
@en-cuadro ( -> )
( cargar las coordenadas x,y de la página cero y enviarlas a la pantalla )
.pixel/x LDZ2 .Pantalla/x DEO2
.pixel/y LDZ2 .Pantalla/y DEO2
( dibujar un pixel en el fondo con color 1 )
#01 .Pantalla/pixel DEO
( incrementar el pixel/x )
.pixel/x LDZ2 INC2 .pixel/x STZ2
BRK
```
notemos el uso de la runa literal de dirección de página cero (.) para referirse a la etiqueta .pixel.
además, observe que en el caso de .pixel la dirección se refiere a la página cero, a la que se accede con LDZ/STZ, y en el caso de .Pantalla la dirección se refiere al espacio de direcciones entrada/salida (i/o), al que se accede con DEO/DEI.
### un poco de práctica en la pila
nota que las siguientes instrucciones también incrementarían .pixel/x, pero estableciendo su dirección sólo una vez:
```
.pixel/x DUP LDZ2 INC2 ROT STZ2
```
te recomiendo que sigas cómo cambia el contenido de la pila en cada uno de los siguientes pasos: ten en cuenta que algunas de las instrucciones están en modo corto :)
esta línea de código contiene la misma cantidad de bytes que la anterior.
una posible desventaja es que podría ser menos legible. pero una posible ventaja es que podría convertirse en una macro:
```
( incrementar un short desde la página cero )
%ZP-INC2 { DUP LDZ2 INC2 ROT STZ2 } ( zp-dirección -- )
```
## variables en direcciones relativas
otra posibilidad que tenemos en uxn y que podría ser más apropiada para las "variables locales", consiste en utilizar direcciones relativas.
de forma similar a las variables de la página cero, para direccionar estas variables sólo necesitamos un byte.
sin embargo, como estas direcciones se dan como offsets relativos y con signo, sólo se pueden alcanzar si están dentro de los 256 bytes que rodean a la instrucción que las carga o almacena.
instrucciones ###: LDR, STR
las instrucciones para trabajar de esta manera son:
* LDR: carga y empuja hacia abajo en la pila el valor en la dirección relativa dada ( dirección -- valor )
* STR: almacena en la dirección relativa dada el valor dado ( dirección valor -- )
similar a LDZ y STZ, en estas instrucciones la dirección siempre será de un byte.
en el modo corto, LDR2 cargará un corto desde la dirección dada, y STR2 almacenará un corto en la dirección dada.
### ejemplos
lo siguiente es la subrutina en-cuadro que dibuja la línea creciente, pero almacenando las coordenadas de los píxeles en una variable "local" a la que se accede mediante LDR y STR.
```
@en-cuadro ( -> )
( carga las coordenadas x,y desde la página cero y las envía a la pantalla )
,pixel/x LDR2 .Pantalla/x DEO2
,pixel/y LDR2 .Pantalla/y DEO2
( dibujar un pixel en el fondo con el color 1 )
#01 .Pantalla/pixel DEO
( incrementa pixel/x )
,pixel/x LDR2 INC2 ,pixel/x STR2
BRK
@pixel [ &x $2 &y $2 ]
```
nótese el uso de la runa coma (,) para indicar que es una dirección relativa; uxnasm calcula el offset requerido asumiendo que será utilizado en la siguiente instrucción.
en este caso realmente no podemos duplicar ese offset como hicimos anteriormente con la dirección de página cero, porque es específica de la posición en el código en que fue escrita.
si declaráramos estas variables como sub-etiquetas de en-cuadro, el código quedaría como sigue:
```
@en-cuadro ( -> )
( carga las coordenadas x,y de la página cero y las envía a la pantalla )
,&pixel-x LDR2 .Pantalla/x DEO2
,&pixel-y LDR2 .Pantalla/y DEO2
( dibujar un pixel en el fondo con el color 1 )
#01 .Pantalla/pixel DEO
( incrementa pixel/x )
,&pixel-x LDR2 INC2 ,&pixel-x STR2
BRK
( variables locales en-cuadro )
&pixel-x $2 &pixel-y $2
```
observe que en este caso, la runa de la coma (,) va acompañada de la runa de la sub-etiqueta (&).
el uso de este tipo de variables tendrá más sentido en el día 5 del tutorial :)
# cambio de posición del sprite
el uso de "variables" nos ayudará ahora a discutir tres formas diferentes de animar un sprite:
* cambio de posición autónomo
* cambio de posición interactivo (con el teclado)
* cambio autónomo de la tile dibujada
los revisaremos por separado para mantener los ejemplos relativamente simples y legibles.
tenga en cuenta que estos ejemplos también sirven para discutir más posibilidades de programación uxntal, y pueden llegar a ser un poco abrumadores.
te recomiendo que revises y experimentes con uno a la vez, pacientemente :)
## cambio de posición autónomo
ya discutimos como hacer que uxn cambie la posición de un pixel en la pantalla, dejando un rastro.
cambiar ese programa para dibujar un sprite de 8x8 en su lugar sería relativamente sencillo, y puede que ya lo hayas probado: tendríamos que usar Pantalla/sprite en lugar de Pantalla/pixel, con un byte apropiado para definir su color y orientación, y tendríamos que establecer la dirección de los datos de nuestro sprite en Pantalla/direc.
eso daría como resultado un sprite que se mueve y que además deja un rastro: ¡te invito a que lo pruebes primero!
### sin rastro
ok, eso puede ser útil en algunos casos, pero ¿cómo podemos evitar dejar el rastro?
una posible forma de conseguirlo sería siguiendo este orden de operaciones dentro de la subrutina en-cuadro:
* borrar el sprite previamente dibujado
* cambiar de posición
* dibujar nuevo sprite
esto nos permite borrar el sprite de su posición en el fotograma anterior, actualizar sus coordenadas a una nueva posición, y luego dibujarlo ahí.
### código de ejemplo
el siguiente programa ilustra los puntos anteriores, haciendo que nuestro cuadrado del día 2 se desplace de izquierda a derecha en el centro de nuestra pantalla.
¡combina varias cosas que hemos cubierto en los últimos días!
```
( hola-sprite-animado.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
( macros/constantes )
%HALF2 { #01 SFT2 } ( desplazar un bit a la derecha ) ( corto -- corto/2 )
%color-borrar { #40 } ( borrar 1bpp sprite del primer plano )
%color-2 { #4a } ( dibujar sprite de 1bpp con color 2 y transparencia )
( página cero )
|0000
@sprite [ &pos-x $2 &pos-y $2 ]
( init )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( fijar la Pantalla/y a la mitad de la pantalla, menos 4 )
.Pantalla/alto DEI2 HALF2 #0004 SUB2 .Pantalla/y DEO2
( fijar la dirección del sprite )
;cuadrado .Pantalla/direc DEO2
( establecer vector de pantalla )
;en-cuadro .Pantalla/vector DEO2
BRK
@en-cuadro ( -> )
( 1: borrar sprite )
( borrar sprite del primer plano )
color-borrar .Pantalla/sprite DEO
( 2: cambiar posición )
( incrementar sprite/pos-x )
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
( 3 : dibujar sprite )
( carga la coordenada x de la página cero y la envía a la pantalla )
.sprite/pos-x LDZ2 .Pantalla/x DEO2
( dibujar sprite en el primer plano con color 2 y transparencia )
color-2 .Pantalla/sprite DEO
BRK
( datos del sprite )
@cuadrado ff81 8181 8181 81ff
```
nítido, ¿no? :)
como esto es sólo un ejemplo para ilustrar un punto, hay algunas cosas que podrían ser optimizadas para hacer nuestro programa más pequeño, y hay algunas cosas que podrían ser útiles pero fueron omitidas. por ejemplo, no hay un valor inicial para la coordenada x, o la coordenada y no se utiliza.
### posibilidades adicionales
con respecto a la optimización, y como un ejemplo, la sección 2 y la primera parte de la sección 3 de en-cuadro podrían haber sido escritas de la siguiente manera:
```
( 2: cambio de posición )
( incrementar sprite/pos-x )
.sprite/pos-x LDZ2 INC2
DUP2 ( duplicar resultado )
.sprite/pos-x STZ2 ( almacenar la primera copia del resultado )
( 3 : dibujar sprite )
( usar la coordenada x de la pila y enviarla a la pantalla )
.Pantalla/x DEO2
```
como siempre, depende de nosotros cómo queremos navegar entre un código más corto y la legibilidad :)
aquí hay algunas preguntas para que reflexiones y pruebes:
* ¿cómo harías que el sprite se moviera más rápido?
* ¿y cómo harías que se moviera más lento?
## cambio de posición interactivo
cuando usamos el vector controlador, estamos actuando en base a un cambio en el/los botón/es o tecla/s que fueron presionados o liberados. esto puede ser muy útil para algunas aplicaciones.
pero, ¿cómo podemos tratar de hacer una acción continua cuando una tecla se mantiene presionada?
en algunos sistemas operativos, si mantenemos una tecla pulsada, ésta dispara el vector controlador varias veces, ¡pero no necesariamente al mismo ritmo que el vector pantalla!
¡esta repetición puede no permitir un movimiento suave como el que podemos conseguir si comprobamos el estado del controlador dentro de la subrutina en-cuadro!
### cuadrado horizontalmente interactivo
el siguiente programa nos permite controlar la posición horizontal de nuestro cuadrado mediante las teclas de dirección.
=> ./img/screencap_uxn-moving-square.gif animado que muestra un cuadrado moviéndose horizontalmente en la pantalla, aparentemente controlado por un humano.
¡nótese las similitudes entre el programa anterior, y lo que cubrimos en el tutorial de uxn del día 3!
=> TUTORIAL UXN DÍA 3
```
( hola-sprite-enmovimiento.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
|80 @Controlador [ &vector $2 &boton $1 &tecla $1 ]
( macros/constantes )
%HALF2 { #01 SFT2 } ( desplazar un bit a la derecha ) ( corto -- corto/2 )
%color-borrar { #40 } ( borrar 1bpp sprite del primer plano )
%color-2 { #4a } ( dibujar sprite de 1bpp con color 2 y transparencia )
( página cero )
|0000
@sprite [ &pos-x $2 &pos-y $2 ]
( init )
|0100
( establecer colores del sistema )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( fijar la Pantalla/y a la mitad de la pantalla, menos 4 )
.Pantalla/alto DEI2 HALF2 #0004 SUB2 .Pantalla/y DEO2
( fijar la dirección del sprite )
;cuadrado .Pantalla/direc DEO2
( establecer vector de pantalla )
;en-cuadro .Pantalla/vector DEO2
BRK
@en-cuadro ( -> )
( 1: borrar sprite )
( borrar sprite del primer plano)
color-borrar .Pantalla/sprite DEO
( 2: cambiar de posición con las flechas )
&verificar-flechas
.Controlador/boton DEI
#40 AND ( aislar el bit 6, correspondiente a la izquierda )
,&izquierda JCN ( saltar si no es 0 )
.Controlador/boton DEI
#80 AND ( aislar el bit 7, correspondiente a la derecha )
,&derecha JCN ( saltar si no es 0 )
( si no se ha pulsado ninguna de esas teclas, dibujar sin cambios )
,&dibujar JMP
&izquierda
( disminuir sprite/pos-x )
.sprite/pos-x LDZ2 #0001 SUB2 .sprite/pos-x STZ2
,&dibujar JMP
&derecha
( incrementar sprite/pos-x )
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
( 3 : dibujar sprite )
&dibujar
( carga la coordenada x de la página cero y la envía a la pantalla )
.sprite/pos-x LDZ2 .Pantalla/x DEO2
( dibujar sprite en primero plano con el color 2 y transparencia )
color-2 .Pantalla/sprite DEO
BRK
( datos del sprite )
@cuadrado ff81 8181 8181 81ff
```
¡te invito a que adaptes el código para que puedas controlar el sprite en las cuatro direcciones cardinales!
## moviéndose dentro de los límites
como habrás notado, estos dos programas anteriores permiten que nuestro sprite se salga de la pantalla.
si quisiéramos evitar eso, una forma de hacerlo sería añadiendo (más) condicionales.
### límites condicionales
por ejemplo, en lugar de tener un incremento incondicional en la coordenada x:
```
( incremento sprite/pos-x )
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
```
podríamos comprobar primero si ha alcanzado una cantidad específica, como el ancho de la pantalla, y no incrementar si es el caso:
```
.sprite/pos-x LDZ2 ( carga x )
.Pantalla/ancho DEI2 #0008 SUB2 ( obtener el ancho de la pantalla menos 8 )
EQU2 ( ¿es x igual a la anchura de la pantalla - 8? )
&continuar JCN
&incremento
( incrementar sprite/pos-x )
.sprite/pos-x LDZ2 INC2 .sprite/pos-x STZ2
&continuar
```
### módulo
otra posibilidad podría ser aplicar una operación de módulo a nuestras coordenadas cambiadas para que siempre se mantengan dentro de los límites, volviendo a la izquierda cuando se cruce con la derecha, y viceversa.
un posible conjunto de macros de módulo podría ser:
```
%MOD { DUP2 DIV MUL SUB } ( a b -- a%b )
%MOD2 { OVR2 OVR2 DIV2 MUL2 SUB2 } ( a b -- a%b )
```
(hay un conjunto más optimizado pero lo discutiremos más adelante :)
podemos aplicar esas macros después de incrementar o decrementar. por ejemplo:
```
( incrementar sprite/pos-x )
.sprite/pos-x LDZ2 INC2
.Pantalla/ancho DEI2 MOD2 ( aplicar modulo de ancho de pantalla )
.sprite/pos-x STZ2 ( almacenar el resultado )
```
# animación de sprite con fotogramas
otra estrategia de animación consistiría en cambiar el sprite que se dibuja en una posición determinada.
podrías tener una secuencia de sprites/marcos y animarlos ejecutándolos en secuencia
## los fotogramas
a efectos prácticos te recomendaría tener un número de fotogramas correspondiente a una potencia de dos, como 2, 4, 8, 16, 32, etc.
por ejemplo, lo siguiente es una secuencia de ocho sprites de 1bpp que corresponden a una línea diagonal que se mueve desde abajo a la derecha hasta arriba a la izquierda:
```
@animación
&fotograma0 00 00 00 00 01 03
&fotograma1 00 00 00 01 03 06 0c
&fotograma2 00 00 01 03 06 0c 18 30
&fotograma3 01 03 06 0c 18 30 60 c0
&fotograma4 03 06 0c 18 30 60 c0 80
&fotograma5 0c 18 30 60 c0 80 00 00
&fotograma6 30 60 c0 80 00 00 00
&fotograma7 c0 80 00 00 00 00 00
```
nótese que cada fotograma consta de 8 bytes. eso implica que hay un desplazamiento de 8 bytes entre las direcciones correspondientes a cada subetiqueta.
por ejemplo, la dirección de &fotograma1 sería 8 bytes más que la dirección de &fotograma0.
los fotogramas que utilizas también podrían estar compuestos por sprites de 2bpp. en ese caso, el desplazamiento entre fotogramas sería de 16 en decimal (10 en hexadecimal) bytes.
## conteo de fotogramas
para tener una animación compuesta por esos fotogramas necesitamos cambiar la dirección de Pantalla/direc a intervalos específicos para que apunte a un sprite diferente cada vez.
¿cómo podemos saber la dirección del sprite que debemos utilizar en cada fotograma?
una forma de conseguirlo es teniendo una "variable global" en la página cero que cuente los fotogramas del programa. además, tendríamos que tener ese conteo acotado en un rango correspondiente a la cantidad de fotogramas de nuestra animación.
ya sabemos cómo hacer la primera parte, y más o menos sabemos cómo hacer la segunda
### cargar, incrementar y almacenar la cuenta de fotogramas
en la página cero declaramos la etiqueta para nuestro cuentafotogramas. utilizaremos la abreviación "cuentaftg" para ayudar a la legibilidad:
```
( página cero )
|0000
@cuentaftg $1
```
y en la subrutina en-cuadro lo incrementamos:
```
( incrementar cuenta de fotograma )
.cuentaftg LDZ INC .cuentaftg STZ
```
ten en cuenta que estamos usando un solo byte para contar, por lo que pasará de 0 a 255 en poco más de 4 segundos, y luego se reiniciará cuando sobrepase su cuenta.
para algunas aplicaciones podría ser mejor tener un cuentafotograma en un corto, que contaría de 0 a 65535 y se sobrepasaría en un poco más de 18 minutos.
### módulo rápido
para que ese recuento de fotogramas se limite a un rango correspondiente a nuestro número de fotogramas, podemos utilizar una operación de módulo.
cuando tenemos un número de fotogramas que corresponde a una potencia de dos, como se recomienda más arriba, podemos utilizar una "máscara AND" para realizar esta operación de módulo más rápidamente que si utilizáramos las macros MOD sugeridas anteriormente.
por ejemplo, si tenemos 8 fotogramas numerados del 0 al 7, podemos observar que esos números sólo requieren tres bits para ser representados.
para construir nuestra máscara AND, ponemos como 1 esos tres bits, y 0 los demás:
```
0000 0111: 07
```
esta máscara AND "dejará pasar" los tres bits menos significativos de otro byte, y desactivará los demás.
en uxntal este proceso se vería de la siguiente manera:
```
.cuentaftg LDZ ( cargar cuentafotograma )
#07 AND ( aplicar máscara AND, correspondiente al módulo 8 )
```
el resultado de la operación será un conteo que va repetidamente de 0 a 7.
podríamos definir esta operación de módulo rápido como una macro para hacer el código más legible:
```
%8MOD { #07 AND } ( byte -- byte%8 )
```
si esto no te ha quedado muy claro, te recomiendo que vuelvas a mirar el tutorial de uxn del día 3, en particular la discusión de las operaciones lógicas.
=> TUTORIAL UXN DÍA 3
## aritmética de punteros
¿cómo podemos usar esa cuenta para seleccionar el sprite para el cuadro de animación que queremos mostrar?
podríamos usar varios saltos condicionales, o podríamos usar una forma más divertida que se puede llamar aritmética de punteros :)
observa que la subetiqueta para el primer fotograma (fotograma0) de nuestra animación tiene la misma dirección que la etiqueta para toda la animación. y, como ya hemos mencionado, el siguiente fotograma (fotograma1) comienza 8 bytes después.
la subetiqueta de cada fotograma siguiente está 8 bytes después de la anterior.
o, otra forma de verlo:
* el fotograma 0 es 0 bytes después de la etiqueta de animación
* El fotograma 1 es 8 bytes después de la etiqueta de animación
* El fotograma 2 es de 16 bytes después de la etiqueta de animación
* El fotograma 3 es de 24 bytes después de la etiqueta de animación
* y así sucesivamente
generalizando, ¡el fotogramaN esta (N veces 8) bytes después de la etiqueta de animación!
esto significa que si obtenemos la dirección absoluta de la etiqueta de animación, y le añadimos (N veces 8) bytes, obtendremos la dirección absoluta del fotogramaN :)
esta cantidad de bytes que separa cada subetiqueta se llama offset.
### calculando el offset
después de aplicar el módulo 8 a nuestro cuentafotogramas podemos multiplicarlo por 8 para obtener el offset respecto a la etiqueta de la animación:
```
.cuentaftg LDZ ( cargar cuentafotograma )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el desplazamiento )
```
### de byte a corto
nota que hasta ahora hemos estado trabajando con bytes, y todo ha ido bien.
sin embargo, ¡las direcciones absolutas son cortos!
esto significa que tenemos que convertir nuestro offset en un short para poder añadirlo a la dirección de los datos de la animación.
una forma de hacerlo es con esta macro que añade un 00 antes del elemento superior de la pila:
```
%A-CORTO { #00 SWP } ( byte -- corto )
```
nuestro código quedaría de la siguiente manera
```
.cuentaftg LDZ ( cargar cuentafotograma )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el desplazamiento )
A-CORTO ( convertir a corto )
```
otra forma, menos clara pero bastante divertida (y algo más corta en memoria de programa), consistiría en pulsar el 00 antes de que ocurra cualquier otra cosa:
```
#00 ( empujar el byte alto del offset )
.cuentaftg LDZ ( cargar cuentafotograma )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el offset )
```
### añadiendo el offset
añadir este offset a la dirección de nuestra animación es comparativamente sencillo:
```
.cuentaftg LDZ ( cargar cuentafotogramas )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el desplazamiento )
A-CORTO ( convertir a corto )
;animacion ( obtener la dirección de la animación )
ADD2 ( añadir el desplazamiento a la dirección )
```
y entonces podríamos enviar eso al puerto Pantalla/direc:
```
.Pantalla/direc DEO2 ( establecer la dirección calculada )
```
## el programa completo
el programa que hace todo esto tendría el siguiente aspecto.
nota que utiliza una secuencia similar a la de los programas anteriores:
* incrementar el cuentafotograma
* borrar el sprite
* calcular la dirección del sprite
* dibujar sprite
la sección "borrar el sprite" no es realmente necesaria en este caso debido a los colores que se utilizan, pero lo sería cuando se utilizan colores con transparencia en ellos :)
=> ./img/screencap_uxn-animation.gif animación de una franja diagonal dentro de un cuadrado pixelado. la diagonal se mueve desde abajo a la derecha hasta arriba a la izquierda
```
( hola-animacion.tal )
( dispositivos )
|00 @Sistema [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Pantalla [ &vector $2 &ancho $2 &alto $2 &pad $2 &x $2 &y $2 &direc $2 &pixel $1 &sprite $1 ]
( macros/constantes )
%HALF2 { #01 SFT2 } ( desplazar un bit a la derecha ) ( corto -- corto/2 )
%8MOD { #07 AND } ( byte -- byte%8 )
%A-CORTO { #00 SWP } ( byte -- corto )
%color-borrar { #40 } ( borrar sprite de 1bpp del primer plano )
%color-2-3 { #4e } ( dibujar el sprite de 1bpp con el color 2 y 3 )
( página cero )
|0000
@cuentaftg $1
( init )
|0100
( set system colors )
#2ce9 .Sistema/r DEO2
#01c0 .Sistema/g DEO2
#2ce5 .Sistema/b DEO2
( fijar Pantalla/x y y a la mitad de la pantalla menos 4 )
.Pantalla/ancho DEI2 HALF2 #0004 SUB2 .Pantalla/x DEO2
.Pantalla/alto DEI2 HALF2 #0004 SUB2 .Pantalla/y DEO2
( establecer la dirección del sprite )
;animación .Pantalla/direc DEO2
( establecer vector de pantalla )
;en-cuadro .Pantalla/vector DEO2
BRK
@en-cuadro ( -> )
( 0: incrementar el número de fotogramas )
.cuentaftg LDZ INC .cuentaftg STZ
( 1: borrar sprite )
( borrar sprite del primer plano )
color-clear .Pantalla/sprite DEO
( 2: actualizar la dirección del sprite )
.cuentaftg LDZ ( cargar cuentafotograma )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el desplazamiento )
TO-SHORT ( convertir a corto )
;animation ( obtener la dirección de la animación )
ADD2 ( añadir el offset a la dirección )
.Pantalla/direc DEO2 ( establecer la dirección calculada )
( dibujar sprite en el primer plano con el color 2 y 3 )
color-2-3 .Pantalla/sprite DEO
BRK
( datos del sprite )
@animacion
&fotograma0 00 00 00 00 01 03
&fotograma1 00 00 00 01 03 06 0c
&fotograma2 00 00 01 03 06 0c 18 30
&fotograma3 01 03 06 0c 18 30 60 c0
&fotograma4 03 06 0c 18 30 60 c0 80
&fotograma5 0c 18 30 60 c0 80 00 00
&fotograma6 30 60 c0 80 00 00 00
&fotograma7 c0 80 00 00 00 00 00
```
no era tan complicado, ¿verdad? :) este ejemplo incluye muchos conceptos que merecen ser estudiados, ¡así que te invito a leerlo con atención!
para algunas posibilidades de diversión, te invito a dibujar el tile varias veces en diferentes lugares y posiblemente con diferentes modos de rotación! eso puede generar animaciones más interesantes!
o, mejor aún, ¡diseña y utiliza tus propios sprites!
## ¡más despacio!
hasta ahora, todo lo que hemos estado haciendo ha sucedido a 60 cuadros por segundo, ¡eso puede ser demasiado rápido para algunas aplicaciones!
afortunadamente, podemos usar algo de aritmética simple con nuestro cuentafotograma para desacelerar sus efectos.
por ejemplo, si queremos actualizar nuestros fotogramas a la mitad de esa velocidad (30 fotogramas por segundo), podemos dividir entre dos el valor del cuentafotograma antes de aplicar el módulo.
como recordarás, esta división se puede hacer con SFT en el caso de potencias de dos, o con DIV para cualquier otro caso.
```
%MITAD { #01 SFT } ( byte -- byte/2 )
%CUARTO { #02 SFT } ( byte -- byte/4 )
%OCTAVO { #03 SFT } ( byte -- byte/8 )
```
podemos utilizar estas macros para dividir la frecuencia en nuestro código:
```
( 2: actualizar la dirección del sprite )
.cuentaftg LDZ ( cargar cuentafotograma )
CUARTO ( dividir entre 4 la frecuencia )
8MOD ( aplicar el módulo 8 para obtener la secuencia entre 0 y 7 )
#08 MUL ( multiplicar por 8 para obtener el desplazamiento )
A-CORTO ( convertir a corto )
;animacion ( obtener la dirección de la animación )
ADD2 ( añadir el offset a la dirección )
.Pantalla/direc DEO2 ( establecer la dirección calculada )
```
=> ./img/screencap_uxn-animation-quarterspeed.gif animación de una franja diagonal dentro de un cuadrado pixelado. la diagonal se mueve desde abajo a la derecha hasta arriba a la izquierda. se mueve más lentamente que la anterior.
ah, ¡mucho mejor!
## potencias de dos no
ten en cuenta que si quieres dividir la frecuencia a números que no son potencias de 2, podrías empezar a ver algunos glitches aproximadamente cada 4 segundos: esto se debe a que el cuentafotograma se sobrepasa y no da una buena secuencia de resultados para esos divisores.
esto también puede ocurrir si tienes una animación que consta de un número de fotogramas que no es una potencia de 2, y utilizas una operación MOD normal para calcular el desplazamiento al fotograma correspondiente.
la solución más sencilla para estos problemas sería utilizar un número de fotogramas de tamaño reducido que sólo causara esos fallos de sobreflujo aproximadamente cada 18 minutos.
tendrías que adaptar el programa para que funcione con ese tamaño de cuentafotograma - ¡siento y pienso que es un buen ejercicio!
# instrucciones del día 4
¡estas son todas las instrucciones de uxntal que hemos discutido hoy!
* LDA: carga y empuja hacia abajo en la pila el valor en la dirección absoluta dada ( dirección -- valor )
* STA: almacena en la dirección absoluta el valor dado ( dirección valor -- )
* LDZ: carga y empuja hacia abajo en la pila el valor en la dirección de página cero dada ( dirección -- valor )
* STZ: almacena en la dirección de página cero el valor dado ( dirección del valor -- )
* LDR: carga y empuja hacia abajo en la pila el valor en la dirección relativa dada ( dirección -- valor )
* STR: almacena en la dirección relativa dada el valor dado ( dirección del valor -- )
las direcciones de LDA y STA son siempre cortos, mientras que las direcciones de las demás instrucciones son siempre un byte.
en modo corto, estas instrucciones cargan o almacenan cortos desde o hacia la memoria.
# día 5
en el tutorial de uxn día 5 introducimos el dispositivo de ratón varvara para explorar más interacciones posibles, y cubrimos los elementos restantes de uxntal y uxn: la pila de retorno, el modo de retorno y el modo de mantenimiento.
=> TUTORIAL UXN DÍA 5
¡también discutimos posibles estructuras para crear bucles y programas más complejos utilizando estos recursos!
¡primero te invito a tomar un descanso!
después, ¡sigue explorando y comparte tus descubrimientos!
# apoyo
si te ha gustado este tutorial y te ha resultado útil, considera compartirlo y darle tu apoyo :)
=> ENLACE DE APOYO