WIP: Traducción Día 6 y otros cambios breves
This commit is contained in:
parent
63740eac22
commit
804a750d8b
|
@ -43,6 +43,14 @@ también hablamos del uso de la memoria del programa como un espacio para datos
|
|||
|
||||
# día 5
|
||||
|
||||
aquí introducimos el dispositivo de ratón varvara para explorar más posibles interacciones, y cubrimos los elementos restantes de uxntal y uxn: la pila de retorno, el modo de retorno y el modo de retención.
|
||||
|
||||
también discutimos posibles estructuras para crear bucles y programas más complejos utilizando estos recursos.
|
||||
|
||||
{tutorial de uxn día 5}
|
||||
|
||||
# día 6
|
||||
|
||||
¡proximamente!
|
||||
|
||||
# índice tentativo
|
||||
|
|
|
@ -172,7 +172,7 @@ Controlador/tecla DEI ( lee la tecla y la introduce en 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.
|
||||
que la instrucción sea a nivel de bit (o "bitwise") significa que aplica la operación AND a cada uno de los bits de los operandos.
|
||||
|
||||
si ambas banderas fueran "verdaderas":
|
||||
|
||||
|
@ -569,7 +569,7 @@ dependiendo de nuestra aplicación, podríamos necesitar permitir que algunos de
|
|||
|
||||
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
|
||||
conoce las máscaras AND a nivel de bits.
|
||||
|
||||
## máscara AND
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -346,6 +346,7 @@ i used nasu to draw a paddle consisting of 2x3 tiles in 2bpp mode. i will number
|
|||
2 3
|
||||
4 5
|
||||
```
|
||||
|
||||
=> https://100r.co/site/nasu.html 100R - nasu
|
||||
|
||||
the resulting data is the following:
|
||||
|
@ -956,7 +957,7 @@ we get 0! fffe works effectively as "-2"!
|
|||
|
||||
we could continue in that way getting more and more "negative" numbers that works thanks to the constrained size of computer memory.
|
||||
|
||||
going back to our code, if we initialize our speed with
|
||||
going back to our code, if we initialize our speed with:
|
||||
|
||||
```
|
||||
#ffff .ball/speed-x STZ2
|
||||
|
@ -1079,7 +1080,7 @@ the y coordinate of the bottom wall would be the height of the screen, less the
|
|||
.ball/y LDZ2 BALL-SIZE ADD2 ( y + ball size )
|
||||
.Screen/height DEI2
|
||||
WALL-MARGIN SUB2 ( height - margin )
|
||||
GTH2 ( is the ball y greater than the wall y? )
|
||||
GTH2 ( is the ball-y greater than the wall-y? )
|
||||
,&set-negative-speed JCN
|
||||
,&continue JMP
|
||||
|
||||
|
@ -1090,7 +1091,6 @@ the y coordinate of the bottom wall would be the height of the screen, less the
|
|||
|
||||
### update-ball code so far
|
||||
|
||||
|
||||
our update-ball subroutine looks like the following right now:
|
||||
|
||||
```
|
||||
|
@ -1192,7 +1192,6 @@ and what happens if both conditions are not met at the same time?
|
|||
|
||||
we can let the ball keep moving, but checking that it hasn't crossed the left wall, by comparing with 0000.
|
||||
|
||||
|
||||
the whole x-in-left code would end up looking like:
|
||||
|
||||
```
|
||||
|
@ -1223,7 +1222,6 @@ the whole x-in-left code would end up looking like:
|
|||
|
||||
finish would be a label at the end of the subroutine, and reset is a subroutine that we will discuss later.
|
||||
|
||||
|
||||
this approach of comparing with 0000 is the easiest, but keep in mind that it might not work if you change the ball speed: it could happen that it crosses the wall but with an x coordinate that is never equal to 0.
|
||||
|
||||
we can't really check if the x coordinate is less than 0, because as we discussed above, that would actually be a number close to ffff.
|
||||
|
|
Loading…
Reference in New Issue