sejo
/
compudanzas
2
3
Fork 3
Code Issues Pull Requests Projects Releases Wiki Activity
compudanzas/src/uxn_tutorial_day_6.gmo

2053 lines
56 KiB
Plaintext
Raw Blame History

# uxn tutorial: day 6, towards pong
this is the sixth section of the {uxn tutorial}! here we talk about how we can integrate everything that we have covered in order to create more complex subroutines and programs for the varvara computer.
we base our discussion in a recreation of the classic pong game.
besides using previous strategies and snippets of code, we cover strategies for drawing and controlling multi-tile sprites, and for checking collisions.
# general logic
even though pong might look simple and easy to program, once we analyze it we might find there are several aspects to account for. fortunately, most of them can be divided as different subroutines that we are able to discuss separately.
we will tackle the following elements in order:
* drawing the background
* drawing and movement of the paddles
* drawing and bouncing of the ball
# drawing the background: repeating a tile
in the previous section of the tutorial we discussed a way of creating a loop in order to repeat a 1bpp tile multiple times in a row.
here we will generalize that procedure into a draw-tiles subroutine that draws a rectangle filled with a given tile. it will receive the x,y coordinates of the top left corner of the rectangle, its width and height in pixels, and the address of the tile:
```
@draw-tiles ( x* y* width* height* addr* -- )
```
a reminder that we are using the convention of adding an asterisk (*) after the name of a value to indicate it's a short.
we will detail how to get to two versions of this subroutine, one that relies on heavy stack wrangling, and other one that uses variables. this in order to compare both approaches and give us clues of the procedures that we will develop afterwards today.
however, if you are more interested in the programming for the game, feel free to jump to the next section with the discussion of the paddles :)
## setting up
let's start with the following program as a template. it includes the data for a 1bpp sprite consisting of diagonal lines.
```
( hello-pong.tal )
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &auto $1 &pad $1 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|80 @Controller [ &vector $2 &button $1 &key $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
( macros )
%RTN { JMP2r }
( main program )
|0100
@setup
( set system colors )
#2ce9 .System/r DEO2
#01c0 .System/g DEO2
#2ce5 .System/b DEO2
BRK
@tile-background 1122 4488 1122 4488
```
## repeating a tile in a row
what's a procedure we could follow to repeat the drawing of a tile starting from x, and ending at a limit corresponding to x+width?
one way would be something like:
* draw tile in x
* add 8 (the size of the tile) to x
* is x less than the limit? if it is, repeat procedure, otherwise end
### concrete version
before abstracting it away, i recommed we write it with concrete numbers.
let's say our initial x is 0008, our width is 0100, and the tile we are drawing is tile-background.
the limit, x+width, would be 0108.
the first step, drawing the tile in x would be:
```
;tile-background .Screen/addr DEO2 ( set tile address )
#0008 .Screen/x DEO2 ( set initial x )
#03 .Screen/sprite DEO ( draw 1bpp sprite with color 3 and 0 )
```
adding 8 to x, we know already:
```
.Screen/x DEI2 #0008 ADD2 ( add 8 to x )
.Screen/x DEO2 ( store new x )
```
checking if x is less than the limit, jumping if it is, would be something like:
```
.Screen/x DEI2
#0108 ( the limit )
LTH2 ,&loop JCN ( jump if x is less than the limit )
```
integrating all of it, we would be able to get:
```
;tile-background .Screen/addr DEO2 ( set tile address )
#0008 .Screen/x DEO2 ( set initial x )
&loop-x
#03 .Screen/sprite DEO ( draw 1bpp sprite with color 3 and 0 )
.Screen/x DEI2 #0008 ADD2 DUP2 ( add 8 to x )
.Screen/x DEO2 ( store new x )
#0108 LTH2 ,&loop-x JCN ( jump if x is less than the limit )
```
note the use of DUP2 in order to avoid re-reading the value of x.
### abstracting
now, let's say we want to have the previous code work with any given initial x and width, present in the stack before starting.
we can even think of it as a subroutine by itself with the following signature:
```
@draw-tiles-in-a-row ( x* width* -- )
```
let's assume for the moment that the address of the sprite was already set, in order to focus in x and width.
when starting the subroutine, the width is at the top of the stack, followed by initial x.
we can use these two values to calculate the limit, that we can stash in the return stack.
one way of achieving that, noting the state of the working stack after each instruction, could be:
```
( initial state: ws: x* width* )
OVR2 ( ws: x* width* x* )
ADD2 ( ws: x* limit* )
STH2 ( ws: x* / rs: limit* )
```
another one:
```
( initial state: ws: x* width* )
ADD2k ( ws: x* width* limit* )
STH2 ( ws: x* width* / rs: limit* )
POP2 ( ws: x* / rs: limit* )
```
remember that we are showing the top of the stacks at their right.
after these steps, the initial x is at the top of the stack, so we can send it directly to the screen.
the last change that we would need is to replace our hardcoded limit with a STH2kr instruction (copy limit from the return stack into the working stack), and end our routine with a POP2r (remove limit from return stack).
our subroutine would then look as follows:
```
@draw-tiles-in-a-row ( x* width* -- )
( calculate and save limit )
OVR2 ( ws: x* width* x* )
ADD2 ( ws: x* limit* )
STH2 ( ws: x* / rs: limit* )
.Screen/x DEO2 ( set initial x )
&loop-x
#03 .Screen/sprite DEO ( draw sprite with color 3 and 0 )
.Screen/x DEI2 #0008 ADD2 DUP2 ( add 8 to x )
.Screen/x DEO2 ( store new x )
STH2kr ( copy limit from rs into ws )
LTH2 ,&loop-x JCN ( jump if x is less than the limit )
POP2r ( pop limit from rs )
RTN
```
### complete program
the following shows our program in context, completely filling the first row of our screen with our tile:
=> ./img/screenshot_uxn-background-row.png screenshot showing the first row of the varvara screen filled with diagonal lines
```
( hello-pong.tal )
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &auto $1 &pad $1 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|80 @Controller [ &vector $2 &button $1 &key $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
( macros )
%RTN { JMP2r }
( main program )
|0100
@setup
( set system colors )
#2ce9 .System/r DEO2
#01c0 .System/g DEO2
#2ce5 .System/b DEO2
;tile-background .Screen/addr DEO2 ( set tile address )
#0000 ( initial x )
.Screen/width DEI2 ( get screen width )
;draw-tiles-in-a-row JSR2
BRK
@draw-tiles-in-a-row ( x* width* -- )
OVR2 ( ws: x* limit* x* )
ADD2 ( ws: x* limit* )
STH2 ( ws: x* / rs: limit* )
.Screen/x DEO2 ( set initial x )
&loop-x
#03 .Screen/sprite DEO ( draw sprite with color 3 and 0 )
.Screen/x DEI2 #0008 ADD2 DUP2 ( add 8 to x )
.Screen/x DEO2 ( store new x )
STH2kr ( copy limit from rs into ws )
LTH2 ,&loop-x JCN ( jump if x is less than the limit )
POP2r ( pop limit from rs )
RTN
@tile-background 1122 4488 1122 4488
```
## repeating a row
similar to what we just did: what's a procedure we could follow to repeat vertically a row starting from y, and ending at a limit corresponding to y+height?
following the same strategy, we could do
* draw row in y
* add 8 (the size of the tile) to y
* is y less than the limit? if it is, repeat procedure, otherwise end
### concrete version
let's use the same numbers as before, assuming that our initial y is 0008, our height is 0100, and therefore our limit would be 0108.
in the case of x, let's start at 0000 and have a width corresponding to the screen width.
as the address wouldn't change in the process, we can set it up at the top and forget about it.
the following code is based on the previous x loop, but it now draws a row in a given y coordinate, adds 8 to it and then checks if it's less than the limit:
```
;tile-background .Screen/addr DEO2 ( set tile address )
#0008 .Screen/y ( set initial y )
&loop-y
( prepare and draw row )
#0000 ( initial x )
.Screen/width DEI2 ( get screen width )
;draw-tiles-in-a-row JSR2
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y )
.Screen/y DEO2 ( store new y )
#0108 ( put limit in top of the stack )
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
```
### abstract version
now, before jumping right into emulating the solution for drawing the row, let's note that in this case it is not that easy.
why? because the idea for our draw-tiles subroutine is that it should be able to receive the initial x and the width of the rectangle, and right now these values are hardcoded inside the loop.
this should be the signature for our subroutine:
```
@draw-tiles ( x* y* width* height* addr* -- )
```
we can approach this problem either with some "stack wrangling", or with "variables".
also note that we will do that because we are trying to get to a generalized subroutine.
if we just wanted to cover all the screen with a sprite, we have all the required code already: we would only need to adapt the vertical limit of the loop to correspond to the height of the screen, and that would be it!
we could then just jump to the section regarding the paddles. however, what follows can be interesting as a way of looking at possible approach to write more complex uxntal code :)
### using stack wrangling
in principle we could just manipulate the items given in the stack, stashing them when appropriate, in order to adapt our subroutine to its signature.
first of all, the tile address is the value at the top of the stack. we can just consume it and forget about it:
```
( initial ws: x* y* width* height* addr* )
.Screen/addr DEO2 ( ws: x* y* width* height* )
```
thinking about the vertical loop, we need to calculate its limit adding height to y, and we need to set the initial y.
we could do the following:
```
ROT2 ( ws: x* width* height* y* )
DUP2 ( ws: x* width* height* y* y* )
( set initial y: )
.Screen/y DEO2 ( ws: x* width* height* y* )
( calculate and stash vertical limit )
ADD2 ( ws: x* width* limit-y* )
STH2 ( ws: x* width* / rs: limit-y* )
```
now, we might be able to stash also the width and 'x', as we need them afterwards in their original order (first x, then width )
```
STH2 ( ws: x* / rs: limit-y* width* )
STH2 ( ws: / rs: limit-y* width* x* )
```
in theory, the first part of our subroutine could look like:
```
@draw-tiles ( x* y* width* height* addr* -- )
( set tile address )
.Screen/addr DEO2 ( ws: x* y* width* height* )
ROT2 ( ws: x* width* height* y* )
DUP2 ( ws: x* width* height* y* y* )
( set initial y )
.Screen/y DEO2 ( set initial y, ws: x* width* height* y* )
( calculate and stash limit-y )
ADD2 ( ws: x* width* limit-y* )
STH2 ( ws: x* width* / rs: limit-y* )
( stash width and x )
STH2 STH2 ( ws: / rs: limit-y* width* x* )
&loop-y
( prepare and draw row )
( retrieve x )
STH2r ( ws: x* / rs: limit-y* width* )
( retrieve width )
STH2r ( ws: x* width* / rs: limit-y* )
;draw-tiles-in-a-row JSR2
```
the problem is that inside the loop, both STH2r instructions retrieve and consume the values for x and width from the return stack. therefore, in the next iteration we wouldn't be able to use them again, as they would be lost.
we can think we could replace these instructions with STH2kr:
```
&loop-y
( prepare and draw row )
( retrieve x )
STH2kr ( ws: x* / rs: limit-y* width* x* )
```
but then we can't retrieve the width because the x is still at the top of the return stack!
oh, many difficulties, but for the sake of the stack wrangling example, let's continue solving this (?)
how can we put the width at the top of the return stack? maybe with a swap applied to the return stack:
```
SWP2r ( ws: x* / rs: limit-y* x* width* )
```
then we can then retrieve the width and use it:
```
STH2kr ( ws: x* width* / rs: limit-y* x* width* )
;draw-tiles-in-a-row JSR2 ( ws: / rs: limit-y* x* width* )
```
what's next? add 8 to y, and check if it's less than the limit. the first part goes without problems:
```
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y; ws: y* y* / rs: limit-y* x* width* )
.Screen/y DEO2 ( store new y; ws: y* / rs: limit-y* x* width* )
```
in order to get the limit into the working stack for the comparison, we have to rotate the return stack:
```
ROT2r ( ws: y* / rs: x* width* limit-y* )
STH2kr ( ws: y* limit-y* / rs: x* width* limit-y* )
```
but ah, before doing the comparison and jumping, we should rearrange the return stack so that it corresponds to the ordering we had at the beginning of the loop:
```
SWP2r ( ws: y* limit-y* / rs: x* limit-y* width* )
ROT2r ( ws: y* limit-y* / rs: limit-y* width* x* )
```
now we can do the comparison and jump:
```
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
```
afterwards we should clear the return stack:
```
POP2r POP2r POP2r
```
after all this, our subroutine would look like the following:
```
@draw-tiles ( x* y* width* height* addr* -- )
( set tile address )
.Screen/addr DEO2 ( ws: x* y* width* height* )
ROT2 ( ws: x* width* height* y* )
DUP2 ( ws: x* width* height* y* y* )
( set initial y )
.Screen/y DEO2 ( set initial y, ws: x* width* height* y* )
( calculate and stash limit-y )
ADD2 ( ws: x* width* limit-y* )
STH2 ( ws: x* width* / rs: limit-y* )
( stash width and x )
STH2 STH2 ( ws: / rs: limit-y* width* x* )
&loop-y
( prepare and draw row )
( retrieve x )
STH2kr ( ws: x* / rs: limit-y* width* x* )
( retrieve width )
SWP2r ( ws: x* / rs: limit-y* x* width* )
STH2kr ( ws: x* width* / rs: limit-y* x* width* )
;draw-tiles-in-a-row JSR2 ( ws: / rs: limit-y* x* width* )
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y )
.Screen/y DEO2 ( store new y )
( retrieve limit-y )
ROT2r ( ws: y* / rs: x* width* limit-y* )
STH2kr ( ws: y* limit-y* / rs: x* width* limit-y* )
( rearrange return stack )
SWP2r ( ws: y* limit-y* / rs: x* limit-y* width* )
ROT2r ( ws: y* limit-y* / rs: limit-y* width* x* )
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
POP2r POP2r POP2r ( clear return stack )
RTN
```
we can then call it like the following in order to get a 256x256 square filled with tiles:
```
#0008 #0008 ( x and y )
#0100 #0100 ( width and height )
;tile-background
;draw-tiles JSR2
```
=> ./img/screenshot_uxn-background-square.png screenshot showing a big square in the varvara screen composed of diagonal lines
### using variables
let's compare the previous approach with the use of relative variables.
we will go "all in" in a relatively wasteful way, without optimizing for procedures that could benefit from stack manipulation.
we'll declare the following labels for our variables, after the RTN that ends the subroutine:
```
( variables )
&height $2 &width $2 &y $2 &x $2 &limit-y $2
```
now, we start the subroutine in the same way as before, setting the address for our sprite:
```
( initial ws: x* y* width* height* addr* )
.Screen/addr DEO2 ( ws: x* y* width* height* )
```
then, we just store the next values in relative addresses:
```
,&height STR2
,&width STR2
,&y STR2
,&x STR2
```
note that we go in reverse order.
after these operations the stacks are empty.
we can then set the initial y and calculate the vertical limit, using the values stored in the variables:
```
( set initial y )
,&y LDR2 DUP2 ( ws: y* y* )
.Screen/y DEO2 ( ws: y* )
( calculate limit-y )
,&height LDR2 ( ws: y* height* )
ADD2 ( ws: limit-y* )
,&limit-y STR2 ( ws: )
```
our loop now would look as follows:
```
&loop-y
( retrieve x and width )
,&x LDR2
,&width LDR2
( draw row )
;draw-tiles-in-a-row JSR2
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y )
.Screen/y DEO2 ( store new y )
( retrieve vertical limit )
,&limit-y LDR2
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
```
and that's it!
compare this with the "concrete" version we developed above, it's very similar in its structure!
the complete subroutine would look like the following:
```
@draw-tiles ( x* y* width* height* addr* -- )
( set tile address )
.Screen/addr DEO2 ( ws: x* y* width* height* )
( store values )
,&height STR2
,&width STR2
,&y STR2
,&x STR2
( set initial y )
,&y LDR2 DUP2 ( ws: y* y* )
.Screen/y DEO2 ( ws: y* )
( calculate vertical limit )
,&height LDR2 ( ws: y* height* )
ADD2 ( ws: limit-y* )
,&limit-y STR2 ( ws: )
&loop-y
( retrieve x and width )
,&x LDR2
,&width LDR2
( draw row )
;draw-tiles-in-a-row JSR2
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y )
.Screen/y DEO2 ( store new y )
( retrieve vertical limit )
,&limit-y LDR2
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
RTN
( variables )
&height $2 &width $2 &y $2 &x $2 &limit-y $2
```
as i said before, we can find here some opportunities for optimization.
maybe the vertical limit can be stashed in the return stack like in the draw-tiles-in-a-row loop, or maybe the variable for the height and for the initial y are not needed.
i'll let you figure them out :)
note that this subroutine as-is, requires 24 bytes of program memory more than the stack wrangling version.
in our case that's not much of a problem, but it's a good way of evaluating our priorities: super readable but probably inefficient code (like this last subroutine), super optimized but probably unreadable code (write-only code, they say), or something in the middle.
## draw-background
now that we have these nice subroutines, we can just wrap them in another one that will cover the whole background with our chosen tile.
for example:
```
@draw-background ( -- )
#0000 #0000 ( initial x and y )
.Screen/width DEI2
.Screen/height DEI2
;tile-background
;draw-tiles JSR2
RTN
```
that we can simply call from our initialization subroutine:
```
;draw-background JSR2
```
=> ./img/screenshot_uxn-background-full.png screenshot showing the varvara screen covered in diagonal lines.
nice! i recommend you take a little break; this was heavy!
# the paddles
we can think of the two paddles of the game as two rectangles, each one with its own x and y coordinates, and both with the same width and height.
the x coordinate for each paddle can be constant, and the y coordinate should be a variable for sure.
in this part we will see how to draw the paddles based on these parameters, and also recap how to change their y coordinates with the controller.
## drawing the multi-tile paddles
in theory, we could use our previous draw-tiles subroutine to draw the rectangles corresponding to our paddles, with a given tile.
in practice, that might be a little bit inconvenient, because the sprite byte that determines the layer and color of our tile was left hardcoded inside our subroutine: if we reuse it, we'll end up drawing with the same color and in the same layer as the background texture!
i leave it as an exercise for you to modify the subroutine so that the sprite byte is received as an argument in the stack :)
in any case, i want to use the paddles as an example of drawing a sprite composed of multiple tiles.
### the data
i used nasu to draw a paddle consisting of 2x3 tiles in 2bpp mode. i will number them from left to right and top to bottom in the following way:
```
0 1
2 3
4 5
```
=> https://100r.co/site/nasu.html 100R - nasu
the resulting data is the following:
```
@paddle
&tile0 [ 3f 7f e7 c3 c3 c3 c3 c3 00 00 18 3c 3c 3c 3c 3c ]
&tile1 [ fc fe ff ff ff ff ff ff 00 00 00 00 00 00 06 06 ]
&tile2 [ c3 c3 c3 c3 e7 ff ff ff 3c 3c 3c 3c 18 00 00 00 ]
&tile3 [ ff ff ff ff ff ff ff ff 06 06 06 06 06 06 06 06 ]
&tile4 [ ff ff ff ff ff ff 7f 3f 00 00 00 00 00 00 00 00 ]
&tile5 [ ff ff ff ff ff ff fe fc 06 06 06 06 06 1e 3c 00 ]
```
one can get these numbers by reading the hexadecimal notation in nasu at the top right, first the left column and then the right column, or by using a tool like hexdump with the corresponding chr file:
```
$ hexdump -C pong.chr
```
i drew the sprite using the blending mode 85 as indicated by nasu, but i will change it to c5 to draw it in the foreground.
### paddle drawing subroutine
let's build a subroutine that draws the 6 tiles of the paddle in the corresponding order.
we could have the subroutine receiving as argument the x and y position of its top left corner:
```
@draw-paddle ( x* y* -- )
```
but let's add the color byte as well:
```
@draw-paddle ( x* y* color -- )
```
on one hand this would allow us to change colors when e.g. hitting the ball, but more importantly this will allow us to clear the paddle before moving it, as we have done in previous days.
in principle the subroutine should be straightforward: we have to set the x and y coordinates of each of the tiles, relative to the given x and y coordinates, and draw them with the given color.
there are many ways to do it, depending on taste.
we could for example draw the tiles in the following order, with the following operations:
* draw tile 0, then add 8 to x
* draw tile 1, then add 8 to y
* draw tile 3, then subtract 8 to x
* draw tile 2, then add 8 to y
* draw tile 4, then add 8 to x
* draw tile 5
or we could do it more traditionally:
* draw tile 0, then add 8 to x
* draw tile 1, then subtract 8 to x, and add 8 to y
* draw tile 2, then add 8 to x
* draw tile 3, then subtract 8 to x, and add 8 to y
* draw tile 4, then add 8 to x
* draw tile 5
instead of subtracting we could recover x from the return stack, or from a relative variable.
a possible advantage of going in order is that we can increment the address of the sprite by 10 (16 in decimal) to get to the address of the next tile. for this, and/or for the changes in coordinates, we can take advantage of the screen auto byte.
however, in this case i'll go for the first approach, and i'll manually set the address for each tile.
additionally, i'll save the color in the return stack:
```
@draw-paddle ( x* y* color -- )
( save color )
STH
( set initial y and x )
.Screen/y DEO2
.Screen/x DEO2
( draw tile 0 )
;paddle/tile0 .Screen/addr DEO2
( copy color from return stack: )
STHkr .Screen/sprite DEO
( add 8 to x: )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 1 )
;paddle/tile1 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to y: )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 3 )
;paddle/tile3 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( sub 8 to x: )
.Screen/x DEI2 #0008 SUB2 .Screen/x DEO2
( draw tile 2 )
;paddle/tile2 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to y: )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 4 )
;paddle/tile4 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to x: )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 5 )
;paddle/tile5 .Screen/addr DEO2
( get and don't keep color from return stack: )
STHr .Screen/sprite DEO
RTN
```
that's it!
now we can call it in e.g. the following way and get our paddle drawn:
```
#0008 #0008 #c5 ;draw-paddle JSR2
```
=> ./img/screenshot_uxn-pong-paddle.png screenshot of the paddle drawn over the background
it would be up to discussion if there are more efficient ways of drawing it. for example, we could have a generalized draw-sprite that receives the initial address of a set of tiles, and the width and height in terms of number of tiles:
```
@draw-sprite ( x* y* width height addr* color )
```
it could work similar to the draw-tiles subroutine we created above.
creating that could be a good exercise for you to try! in this case i'll just stay with the manual approach.
the good thing of this process being in a subroutine is that we can "forget" about its inner working and just use it :)
## variables and constants for the paddles
let's reserve some space in the zero page for the x and y coordinates of each paddle.
```
( zero page )
|0000
@left [ &x $2 &y $2 ]
@right [ &x $2 &y $2 ]
```
we mentioned early that the x coordinate is constant; however, if we make it a variable then we can dinamically assign the x position of the paddles (especially the right one) depending on the size of the screen.
we can have a couple of macros to hold the dimensions of the paddles in order to use it later, and also its color:
```
%PADDLE-WIDTH { #0010 } ( 2 tiles )
%PADDLE-HEIGHT { #0018 } ( 3 tiles )
%PADDLE-COLOR { #c5 }
```
a margin to separate the paddles from the borders could be nice as well:
```
%MARGIN { #0010 }
```
finally, let's bring back our HALF2 macro:
```
%HALF2 { #01 SFT2 } ( short -- short/2 )
```
### initialize positions
we can then initialize the positions of the paddles.
for the left x, we can just assign a constant value:
```
MARGIN .left/x STZ2
```
for the right x, we can subtract the margin and the width of the paddle from the screen width:
```
.Screen/width DEI2
MARGIN SUB2 PADDLE-WIDTH SUB2
.right/x STZ2
```
for centering the y coordinates we can subtract the paddle height from the screen height, and then divide over two:
```
.Screen/height DEI2 PADDLE-HEIGHT SUB2 HALF2
DUP2
.left/y STZ2
.right/y STZ2
```
### draw paddles
in order to draw each paddle, we can do the following procedure inside our on-frame screen vector:
```
( draw paddles )
.left/x LDZ2 .left/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
```
### the program so far
omitting the definition of the subroutines, and as a way of having a checkpoint, right now our program would look like the following:
=> ./img/screenshot_uxn-pong-paddles.png screenshot of the two paddles, vertically centered and with the same margin relative to the sides
```
( hello-pong.tal )
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &auto $1 &pad $1 &x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|80 @Controller [ &vector $2 &button $1 &key $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
( macros )
%RTN { JMP2r }
%HALF2 { #01 SFT2 } ( short -- short/2 )
( constants )
%PADDLE-WIDTH { #0010 } ( 2 tiles )
%PADDLE-HEIGHT { #0018 } ( 3 tiles )
%PADDLE-COLOR { #c5 }
%MARGIN { #0010 }
( zero page )
|0000
@left [ &x $2 &y $2 ]
@right [ &x $2 &y $2 ]
( main program )
|0100
@setup
( set system colors )
#2ce9 .System/r DEO2
#01c0 .System/g DEO2
#2ce5 .System/b DEO2
( set screen vector )
;on-frame .Screen/vector DEO2
( draw background )
;draw-background JSR2
( initialize paddles )
MARGIN .left/x STZ2
.Screen/width DEI2
MARGIN SUB2 PADDLE-WIDTH SUB2
.right/x STZ2
.Screen/height DEI2 PADDLE-HEIGHT SUB2
HALF2 DUP2
.left/y STZ2
.right/y STZ2
BRK
@on-frame ( -> )
( draw paddles )
.left/x LDZ2 .left/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
BRK
```
## paddle movement
for the paddle movement we can go back to previous examples of moving a sprite. the process we have followed is:
* clear sprite from current position
* update position
* draw sprite in new position
### clear or draw sprite
we have already the process for drawing our paddles:
```
( draw paddles )
.left/x LDZ2 .left/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
```
in order to clear them, we can do the same but using a sprite byte corresponding to clear the tile in the foreground:
```
( clear paddles )
.left/x LDZ2 .left/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
```
where CLEAR-COLOR in this case would be:
```
%CLEAR-COLOR { #40 } ( clear sprite from the foreground )
```
this is a good reminder to review the tables for the sprite bytes in {uxn tutorial day 2}!
### update position
to update the position of our paddles, we can resort to the hello-moving-sprite.tal example from {uxn tutorial day 4}.
we can use up and down arrows to change the position of the left paddle, and ctrl and alt (A and B) buttons to change the position of the right paddle.
we can have a macro to define the paddle speed, i.e. how much we'll add or subtract when moving each frame:
```
%PADDLE-SPEED { #0001 }
```
all of this can go inside its own subroutine for readability purposes:
```
@update-paddles ( -- )
&left
( left paddle: up and down buttons )
.Controller/button DEI
DUP #10 AND ( check bit for up )
,&left-up JCN
DUP #20 AND ( check bit for down )
,&left-down JCN
,&right JMP ( jump if neither of them were pressed )
&left-up
.left/y LDZ2 PADDLE-SPEED SUB2 .left/y STZ2
,&right JMP
&left-down
.left/y LDZ2 PADDLE-SPEED ADD2 .left/y STZ2
,&right JMP
&right
( right paddle: ctrl/A and alt/B buttons )
DUP #01 AND ( check bit for A )
,&right-up JCN
DUP #02 AND ( check bit for B )
,&right-down JCN
,&end JMP ( jump if neither of them were pressed )
&right-up
.right/y LDZ2 PADDLE-SPEED SUB2 .right/y STZ2
,&end JMP
&right-down
.right/y LDZ2 PADDLE-SPEED ADD2 .right/y STZ2
&end
POP ( pop duplicate value of button )
RTN
```
### complete procedure
integrating everything, our on-frame subroutine would look like the following.
now we are able to move our paddles!
```
@on-frame ( -> )
( clear paddles )
.left/x LDZ2 .left/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
( update paddles )
;update-paddles JSR2
( draw paddles )
.left/x LDZ2 .left/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
BRK
```
note that we are able to move the paddles beyond the limits of the screen.
i invite you to modify the update-paddles subroutine so that there's a limit in the paddles movement. in {uxn tutorial day 4} we discussed some possible strategies for achieving it :)
# the ball
now let's get the ball rolling!
here we'll work again with a multi-tile sprite drawn relative to x and y variables for its top left corner.
additionally, we'll use this section to talk about strategies for collision detection, with the walls and the paddles.
## drawing the ball
i used nasu to draw a ball composed of 2x2 2bpp tiles, ordered in the following way:
```
0 1
2 3
```
here's its data:
```
@ball-sprite
&tile0 [ 03 0f 1f 39 70 70 f9 ff 00 00 00 06 0f 0f 06 00 ]
&tile1 [ c0 f0 f8 fc fe fe ff ff 00 00 00 00 08 0c 06 06 ]
&tile2 [ ff ff 7f 7f 3f 1f 0f 03 00 00 00 00 18 0f 01 00 ]
&tile3 [ ff ff fe fe fc f8 f0 c0 06 06 0c 1c 38 f0 c0 00 ]
```
we can define a couple of macros to refer to its parameters:
```
%BALL-SIZE { #0010 } ( 2 tiles per side )
%BALL-COLOR { #c5 }
```
### subroutine for drawing the ball
as we'll be drawing a single ball, we can embed in its drawing subroutine the use of its own zero-page variables for the coordinates, instead of getting them as arguments in the stack.
in our zero page we can define them:
```
@ball [ &x $2 &y $2 ]
```
in our setup subroutine we can assign values to them, e.g. at the middle of the screen:
```
( inside setup )
( initialize ball )
.Screen/width DEI2 BALL-SIZE SUB2
HALF2
.ball/x STZ2
.Screen/height DEI2 BALL-SIZE SUB2
HALF2
.ball/y STZ2
```
and then we can use them in our subroutine.
let's have the subroutine receive the color as an argument, so that we can clear the ball like we do with the paddles:
```
@draw-ball ( color -- )
( set initial x and y )
.ball/x LDZ2 .Screen/x DEO2
.ball/y LDZ2 .Screen/y DEO2
( draw tile 0 )
;ball-sprite/tile0 .Screen/addr DEO2
( color byte was in the stack already )
DUP .Screen/sprite DEO
( move right )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 1 )
;ball-sprite/tile1 .Screen/addr DEO2
DUP .Screen/sprite DEO
( move down )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 3 )
;ball-sprite/tile3 .Screen/addr DEO2
DUP .Screen/sprite DEO
( move left )
.Screen/x DEI2 #0008 SUB2 .Screen/x DEO2
( draw tile 2 )
;ball-sprite/tile2 .Screen/addr DEO2
.Screen/sprite DEO
RTN
```
in order to draw it, we'd just need to do:
```
( draw ball )
BALL-COLOR ;draw-ball JSR2
```
=> ./img/screenshot_uxn-pong-paddles-and-ball.png screenshot of the screen showing the paddles in their horizontal position but at different heights, and the ball completely centered in the screen.
## ball movement
for the movement of the ball, we'll follow the same structure as before:
* clear the ball in the current position
* update its position
* draw the ball in the new position
it would look something like the following, and could sit along the equivalent procedures for the paddles inside the on-frame subroutine:
```
( inside on-frame )
( clear ball )
CLEAR-COLOR ;draw-ball JSR2
( update ball )
;update-ball JSR2
( draw ball )
BALL-COLOR ;draw-ball JSR2
```
now let's discuss how to build that update-ball subroutine :)
### accounting for the change of direction
besides our variables for keeping track of the position of the ball, we should be able to keep track of the per-axis direction it is moving.
one approach could be to have a flag for each x and y, that indicate if we should increment or decrement them.
another approach could be to have a speed variable for each x and y, that gets changed according to the direction we want the ball to go.
we will use this latter approach as it will help us discuss some perks of unsigned integer arithmetic!
we include these variables in our zero page, complementing the x and y we had already:
```
@ball [ &x $2 &y $2 &speed-x $2 &speed-y $2 ]
```
### different directions
if, for example, we initialize speed-x with 1:
```
#0001 .ball/speed-x STZ2
```
we can make the ball move to the right by doing:
```
( inside update-ball )
.ball/speed-x LDZ2 ( get speed-x )
.ball/x LDZ2 ( get x )
ADD2 ( add them together )
.ball/x STZ2 ( store new x )
```
in order to move to the left, we might think that we should replace ADD2 with SUB2. and yes, we could do that.
but, to leave our code as it is now: is there a value of speed-x that will make x get smaller when adding them together?
in other contexts, one might say, "-1"! but we haven't used negative signs here in uxn; we can't.
then, is there a positive value of speed-x that will make x get smaller when adding them together?
normally we could think there isn't, but here we are constrained by 8 or 16 bits. and what does that imply?
for example, if we have the number ffff (16 bits, all are ones), and we add 0001, what do we get?
```
1111 1111 1111 1111
+ 0000 0000 0000 0001
---------------------
1 0000 0000 0000 0000
```
it makes sense, but the 1 at the left sits outside the 16 bits; in other contexts it would be called the carry bit.
in uxn, the result of adding ffff and 0001 is 0000: we would say we are overflowing the 16 bits.
let's look at it the other way around: if we have 1, and we add ffff, we get 0, that is 1 less than 1.
if we have 0002, and we add ffff:
```
0000 0000 0000 0010
+ 1111 1111 1111 1111
--------------------
1 0000 0000 0000 0001
```
we get 0001, that is 1 less than 2.
in general, if we add ffff to a 16 bits number, we'll get a value that is 1 less than itself.
we can think then that ffff is like a "-1"!
to get other "negative numbers", let's observe the following: if we subtract 1 from ffff, we get fffe. what happens if we add it to 2?
```
0000 0000 0000 0010: 0002
+ 1111 1111 1111 1110: fffe
---------------------
1 0000 0000 0000 0000: 0000
```
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
```
#ffff .ball/speed-x STZ2
```
and then we use exactly the same code to update the position:
```
( inside update-ball )
.ball/speed-x LDZ2 ( get speed-x )
.ball/x LDZ2 ( get x )
ADD2 ( add them together )
.ball/x STZ2 ( store new x )
```
we will have decreased the position by 1!
it might make sense to set these values as macros:
```
%BALL-POSITIVE-SPEED { #0001 } ( +1 )
%BALL-NEGATIVE-SPEED { #ffff } ( -1 )
```
### implemeting the ball movement
based on what we just discussed, we can start our update-ball subroutine with the following:
```
@update-ball ( -- )
( get speed-x and x )
.ball/speed-x LDZ2 .ball/x LDZ2
ADD2 ( add them together )
.ball/x STZ2 ( store new x )
( get speed-y and y )
.ball/speed-y LDZ2 .ball/y LDZ2
ADD2 ( add them together )
.ball/y STZ2 ( store new y )
RTN
```
if we complement our initilization with the speeds, we'll be able to see the ball moving:
```
( inside setup )
( initialize ball )
.Screen/width DEI2 BALL-SIZE SUB2
HALF2 .ball/x STZ2
.Screen/height DEI2 BALL-SIZE SUB2
HALF2 .ball/y STZ2
( initialize ball speed )
BALL-POSITIVE-SPEED .ball/speed-x STZ2
BALL-POSITIVE-SPEED .ball/speed-y STZ2
```
## collisions with the walls
we have defined the general way of updating the position of the ball given its speed in x and y.
now let's see how to implement the classical "bounce"!
first, let's start with the walls at the top and bottom of the screen. let's consider that there is some margin between the actual border of the screen, and the walls:
```
%WALL-MARGIN { #0010 }
```
in order to perform these collision detections, we'd need to check the y coordinate of the ball only.
as always, there are many ways to achieve this. one could be:
* check if the ball is hitting either wall
* if it is, then invert the speed
another one:
* check if the ball is hitting the top wall
* if it is, then set a positive speed
* if not, check if the ball is hitting the bottom wall
* if it is, then set a negative speed
in other languages it is probably easier to write the first one, but here we'll stick with the second: for clarity and because of the way we'll have to do the checks.
in any case, it can be a good exercise for you to try to figure out how to "invert" the speed with a single arithmetic or logic operation!
hint: look again at the bitwise masks discussed on {uxn tutorial day 3} :)
### top wall
if the ball is hitting the top wall, it means its y coordinate is less than the y coordinate of the wall.
considering that there's a margin at the top, we can do this check as follows:
```
( inside update-ball )
&check-top-wall
.ball/y LDZ2
WALL-MARGIN
LTH2 ( is ball-y less than the margin? )
,&set-positive-speed JCN
,&check-bottom-wall JMP
&set-positive-speed
BALL-POSITIVE-SPEED .ball/speed-y STZ2
,&continue JMP
&check-bottom-wall
```
### bottom wall
here the procedure would be similar, but considering the size of the ball.
we'd like to know if the y coordinate, plus the size of the ball, is greater than the y coordinate of the bottom wall.
the y coordinate of the bottom wall would be the height of the screen, less the wall margin:
```
(inside update ball )
&check-bottom-wall
.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? )
,&set-negative-speed JCN
,&continue JMP
&set-negative-speed
BALL-NEGATIVE-SPEED .ball/speed-y STZ2
&continue
```
### update-ball code so far
our update-ball subroutine looks like the following right now:
```
@update-ball ( -- )
( get speed-x and x )
.ball/speed-x LDZ2 .ball/x LDZ2 ( get x )
ADD2 ( add them together )
.ball/x STZ2 ( store new x )
( get speed-y and y )
.ball/speed-y LDZ2 .ball/y LDZ2 ( get y )
ADD2 ( add them together )
.ball/y STZ2 ( store new y )
( check collisions with walls )
&check-top-wall
.ball/y LDZ2
WALL-MARGIN
LTH2 ( is ball-y less than the margin? )
,&set-positive-speed JCN
,&check-bottom-wall JMP
&set-positive-speed
BALL-POSITIVE-SPEED .ball/speed-y STZ2
,&continue JMP
&check-bottom-wall
.ball/y LDZ2 BALL-SIZE ADD2 ( y + ball size )
.Screen/height DEI2 WALL-MARGIN SUB2 ( height - margin )
GTH2
,&set-negative-speed JCN
,&continue JMP
&set-negative-speed
BALL-NEGATIVE-SPEED .ball/speed-y STZ2
&continue
RTN
```
you can test it using different initial speed-y inside setup. the ball should be bouncing at the top and bottom now! :)
## collisions with the paddles
let's work with what we just did, and adapt it for bouncing with the paddles!
### left paddle
first of all, we can identify if the x coordinate of the ball would be hitting the left paddle.
for this, we can check if x is less than the sum of the margin and paddle width.
```
( inside update-ball )
&check-left-paddle
.ball/x LDZ2
MARGIN PADDLE-WIDTH ADD2
LTH2 ( is ball-x less than the margin + paddle-width? )
,&x-in-left JCN
,&check-right-paddle JMP
&x-in-left
( ... )
&check-right-paddle
```
once we know that's true, we can see if the ball is within vertical reach of the paddle; the y coordinate of the ball has to be within a certain range relative to the y coordinate of the ball.
specifically, if we want the ball to be able to bounce when any part of the ball hits any part of the paddle, the y coordinate of the ball has to be:
* greater than the paddle y coordinate minus the ball height AND
* less than the paddle y coordinate plus the paddle height
if those two conditions are met, then we can set a positive speed for x:
```
( inside update-ball )
&x-in-left
.ball/y LDZ2 DUP2
.left/y LDZ2 BALL-SIZE SUB2 GTH2 ( first flag ) STH
.left/y LDZ2 PADDLE-HEIGHT ADD2 LTH2 ( second flag )
STHr ( retrieve first flag )
AND ( AND the two flags together )
,&bounce-left JCN
```
where bounce-left would be:
```
&bounce-left
BALL-POSITIVE-SPEED .ball/speed-x STZ2
,&finish JMP
```
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:
```
( inside update-ball )
&x-in-left
.ball/y LDZ2 DUP2
.left/y LDZ2 BALL-SIZE SUB2 GTH2 ( first flag ) STH
.left/y LDZ2 PADDLE-HEIGHT ADD2 LTH2 ( second flag )
STHr ( retrieve first flag )
AND ( AND the two flags together )
,&bounce-left JCN
.ball/x LDZ2 #0000 NEQ2 ( has it reached the wall ? )
,&finish JCN
&reset-left
( here you can add a point to the left paddle )
;reset JSR2
,&finish JMP
&bounce-left
BALL-POSITIVE-SPEED .ball/speed-x STZ2
,&finish JMP
&check-right-paddle
```
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.
if we checked for the x coordinate being less than ffff, then every possible value would turn on the comparison flag!
this can be another good exercise for you: how would you check if the ball has crossed the left wall regardless of its speed?
### right paddle
for the right paddle we will do the same as above, but changing the comparisons relative to the x coordinate of the ball: we will use the screen width as a reference for the right wall, and from there we'll subtract the margin and widths.
```
&check-right-paddle
.ball/x LDZ2 BALL-SIZE ADD2 ( ball-x + ball-size )
.Screen/width DEI2 MARGIN SUB2 PADDLE-WIDTH SUB2
GTH2 ( is ball's right coordinate greater than the screen width - margin - paddle-width? )
,&x-in-right JCN
,&finish JMP
&x-in-right
.ball/y LDZ2 DUP2
.right/y LDZ2 BALL-SIZE SUB2 GTH2 ( first flag ) STH
.right/y LDZ2 PADDLE-HEIGHT ADD2 LTH2 ( second flag )
STHr ( retrieve first flag )
AND ( AND the two flags together )
,&bounce-right JCN
.ball/x LDZ2
.Screen/width DEI2 NEQ2 ( has it reached the wall ? )
,&finish JCN
&reset-right
( here you can add a point to the right paddle )
;reset JSR2
,&finish JMP
&bounce-right
BALL-NEGATIVE-SPEED .ball/speed-x STZ2
,&finish JMP
&finish
RTN
```
that should be it! you can find the complete update-ball subroutine below!
in order to be able to assemble and run the game, let's define the reset subroutine!
## reset
here we'll just define a reset subroutine that returns the ball to the middle of the screen without altering its speed:
```
@reset ( -- )
( initialize ball )
.Screen/width DEI2 BALL-SIZE SUB2
HALF2 .ball/x STZ2
.Screen/height DEI2 BALL-SIZE SUB2
HALF2 .ball/y STZ2
RTN
```
it would be interesting to have some mechanism to also change the speed: maybe based on the framecount, in the position of the paddles, or whatever else you choose.
# the complete program
here's all of the code we wrote today!
=> ./img/screencap_uxn-pong.gif animated gif showing pong in action: the paddles move, the ball bounces in the top and bottom walls and in the paddles, and the ball restarts from the middle when the ball hits any side.
## setup
```
( hello-pong.tal )
( devices )
|00 @System [ &vector $2 &pad $6 &r $2 &g $2 &b $2 ]
|20 @Screen [ &vector $2 &width $2 &height $2 &auto $1 &pad $1
&x $2 &y $2 &addr $2 &pixel $1 &sprite $1 ]
|80 @Controller [ &vector $2 &button $1 &key $1 ]
|90 @Mouse [ &vector $2 &x $2 &y $2 &state $1 &wheel $1 ]
( macros )
%RTN { JMP2r }
%HALF2 { #01 SFT2 } ( short -- short/2 )
%DOUBLE2 { #10 SFT2 }
( constants )
%PADDLE-WIDTH { #0010 } ( 2 tiles )
%PADDLE-HEIGHT { #0018 } ( 3 tiles )
%PADDLE-COLOR { #c5 }
%PADDLE-SPEED { #0001 }
%BALL-SIZE { #0010 } ( 2 tiles )
%BALL-COLOR { #c5 }
%BALL-POSITIVE-SPEED { #0001 }
%BALL-NEGATIVE-SPEED { #ffff }
%CLEAR-COLOR { #40 }
%MARGIN { #0010 } ( left and right )
%WALL-MARGIN { #0010 } ( top and bottom )
( zero page )
|0000
@left [ &x $2 &y $2 ]
@right [ &x $2 &y $2 ]
@ball [ &x $2 &y $2 &speed-x $2 &speed-y $2 ]
( setup )
|0100
@setup ( -> )
( set system colors )
#2ce9 .System/r DEO2
#01c0 .System/g DEO2
#2ce5 .System/b DEO2
( set screen vector )
;on-frame .Screen/vector DEO2
( draw background )
;draw-background JSR2
( initialize paddles )
MARGIN .left/x STZ2
.Screen/width DEI2
MARGIN SUB2 PADDLE-WIDTH SUB2
.right/x STZ2
.Screen/height DEI2 PADDLE-HEIGHT SUB2
HALF2 DUP2
.left/y STZ2
.right/y STZ2
( initialize ball )
;reset JSR2
( initialize ball speed )
BALL-NEGATIVE-SPEED .ball/speed-x STZ2
BALL-POSITIVE-SPEED .ball/speed-y STZ2
BRK
```
## on-frame
```
@on-frame ( -> )
( clear paddles )
.left/x LDZ2 .left/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 CLEAR-COLOR ;draw-paddle JSR2
( clear ball )
CLEAR-COLOR ;draw-ball JSR2
( update paddles )
;update-paddles JSR2
( update ball )
;update-ball JSR2
( draw paddles )
.left/x LDZ2 .left/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
.right/x LDZ2 .right/y LDZ2 PADDLE-COLOR ;draw-paddle JSR2
( draw ball )
BALL-COLOR ;draw-ball JSR2
BRK
```
## reset
```
@reset ( -- )
( initialize ball )
.Screen/width DEI2 BALL-SIZE SUB2
HALF2 .ball/x STZ2
.Screen/height DEI2 BALL-SIZE SUB2
HALF2 .ball/y STZ2
RTN
```
## ball-related
### update-ball
```
@update-ball ( -- )
( get speed-x and x )
.ball/speed-x LDZ2 .ball/x LDZ2 ( get x )
ADD2 ( add them together )
.ball/x STZ2 ( store new x )
( get speed-y and y )
.ball/speed-y LDZ2 .ball/y LDZ2 ( get y )
ADD2 ( add them together )
.ball/y STZ2 ( store new y )
( check collisions with walls )
&check-top-wall
.ball/y LDZ2
WALL-MARGIN
LTH2 ( is ball-y less than the margin? )
,&set-positive-speed JCN
,&check-bottom-wall JMP
&set-positive-speed
BALL-POSITIVE-SPEED .ball/speed-y STZ2
,&continue JMP
&check-bottom-wall
.ball/y LDZ2 BALL-SIZE ADD2 ( y + ball size )
.Screen/height DEI2 WALL-MARGIN SUB2 ( height - margin )
GTH2
,&set-negative-speed JCN
,&continue JMP
&set-negative-speed
BALL-NEGATIVE-SPEED .ball/speed-y STZ2
&continue
( check collisions with paddles )
&check-left-paddle
.ball/x LDZ2
MARGIN PADDLE-WIDTH ADD2
LTH2 ( is ball-x less than the margin + paddle-width? )
,&x-in-left JCN
,&check-right-paddle JMP
&x-in-left
.ball/y LDZ2 DUP2
.left/y LDZ2 BALL-SIZE SUB2 GTH2 ( first flag ) STH
.left/y LDZ2 PADDLE-HEIGHT ADD2 LTH2 ( second flag )
STHr ( retrieve first flag )
AND ( AND the two flags together )
,&bounce-left JCN
.ball/x LDZ2 #0000 NEQ2 ( has it reached the wall ? )
,&finish JCN
&reset-left
( here you can add a point to the left paddle )
;reset JSR2
,&finish JMP
&bounce-left
BALL-POSITIVE-SPEED .ball/speed-x STZ2
,&finish JMP
&check-right-paddle
.ball/x LDZ2 BALL-SIZE ADD2
.Screen/width DEI2 MARGIN SUB2 PADDLE-WIDTH SUB2
GTH2 ( is ball-x + ball-size greater than the screen width - margin - paddle-width? )
,&x-in-right JCN
,&finish JMP
&x-in-right
.ball/y LDZ2 DUP2
.right/y LDZ2 BALL-SIZE SUB2 GTH2 ( first flag ) STH
.right/y LDZ2 PADDLE-HEIGHT ADD2 LTH2 ( second flag )
STHr ( retrieve first flag )
AND ( AND the two flags together )
,&bounce-right JCN
.ball/x LDZ2
.Screen/width DEI2 NEQ2 ( has it reached the wall ? )
,&finish JCN
&reset-right
( here you can add a point to the right paddle )
;reset JSR2
,&finish JMP
&bounce-right
BALL-NEGATIVE-SPEED .ball/speed-x STZ2
,&finish JMP
&finish
RTN
```
### draw-ball
```
@draw-ball ( color -- )
( set initial x and y )
.ball/x LDZ2 .Screen/x DEO2
.ball/y LDZ2 .Screen/y DEO2
( draw tile 0 )
;ball-sprite/tile0 .Screen/addr DEO2
( color byte was in the stack already )
DUP .Screen/sprite DEO
( move right )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 1 )
;ball-sprite/tile1 .Screen/addr DEO2
DUP .Screen/sprite DEO
( move down )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 3 )
;ball-sprite/tile3 .Screen/addr DEO2
DUP .Screen/sprite DEO
( move left )
.Screen/x DEI2 #0008 SUB2 .Screen/x DEO2
( draw tile 2 )
;ball-sprite/tile2 .Screen/addr DEO2
.Screen/sprite DEO
RTN
```
## paddle-related
### update-paddles
```
@update-paddles ( -- )
&left
( left paddle: up 10 and down 20 buttons )
.Controller/button DEI
DUP #10 AND ( check bit for up )
,&left-up JCN
DUP #20 AND ( check bit for down )
,&left-down JCN
,&right JMP ( jump if neither of them were pressed )
&left-up
.left/y LDZ2 PADDLE-SPEED SUB2 .left/y STZ2
,&right JMP
&left-down
.left/y LDZ2 PADDLE-SPEED ADD2 .left/y STZ2
,&right JMP
&right
( right paddle: ctrl/A 01 and alt/B 02 buttons )
DUP #01 AND ( check bit for A )
,&right-up JCN
DUP #02 AND ( check bit for B )
,&right-down JCN
,&end JMP ( jump if neither of them were pressed )
&right-up
.right/y LDZ2 PADDLE-SPEED SUB2 .right/y STZ2
,&end JMP
&right-down
.right/y LDZ2 PADDLE-SPEED ADD2 .right/y STZ2
&end
POP ( pop duplicate value of button )
RTN
```
## draw-paddle
```
@draw-paddle ( x* y* color -- )
( save color )
STH
( set initial y and x )
.Screen/y DEO2
.Screen/x DEO2
( draw tile 0 )
;paddle-sprite/tile0 .Screen/addr DEO2
( copy color from return stack: )
STHkr .Screen/sprite DEO
( add 8 to x: )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 1 )
;paddle-sprite/tile1 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to y: )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 3 )
;paddle-sprite/tile3 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( sub 8 to x: )
.Screen/x DEI2 #0008 SUB2 .Screen/x DEO2
( draw tile 2 )
;paddle-sprite/tile2 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to y: )
.Screen/y DEI2 #0008 ADD2 .Screen/y DEO2
( draw tile 4 )
;paddle-sprite/tile4 .Screen/addr DEO2
STHkr .Screen/sprite DEO
( add 8 to x: )
.Screen/x DEI2 #0008 ADD2 .Screen/x DEO2
( draw tile 5 )
;paddle-sprite/tile5 .Screen/addr DEO2
( get and don't keep color from return stack: )
STHr .Screen/sprite DEO
RTN
```
## background-related
### draw-background
```
@draw-background ( -- )
#0000 WALL-MARGIN
.Screen/width DEI2
.Screen/height DEI2 WALL-MARGIN DOUBLE2 SUB2
;tile-background
;draw-tiles JSR2
RTN
```
### draw-tiles
```
@draw-tiles ( x* y* width* height* addr* -- )
( set tile address )
.Screen/addr DEO2 ( ws: x* y* width* height* )
( store values )
,&height STR2
,&width STR2
,&y STR2
,&x STR2
( set initial y )
,&y LDR2 DUP2 ( ws: y* y* )
.Screen/y DEO2 ( ws: y* )
( calculate vertical limit )
,&height LDR2 ( ws: y* height* )
ADD2 ( ws: limit-y* )
,&limit-y STR2 ( ws: )
&loop-y
( retrieve x and width )
,&x LDR2
,&width LDR2
( draw row )
;draw-tiles-in-a-row JSR2
.Screen/y DEI2 #0008 ADD2 DUP2 ( add 8 to y )
.Screen/y DEO2 ( store new y )
( retrieve vertical limit )
,&limit-y LDR2
LTH2 ,&loop-y JCN ( jump if x is less than the limit )
RTN
( variables )
&height $2 &width $2 &y $2 &x $2 &limit-y $2
```
### draw-tiles-in-a-row
```
@draw-tiles-in-a-row ( x* width* -- )
OVR2 ( ws: x* width* x* )
ADD2 ( ws: x* limit* )
STH2 ( ws: x* / rs: limit* )
.Screen/x DEO2 ( set initial x )
&loop-x
#03 .Screen/sprite DEO ( draw sprite with color 3 and 0 )
.Screen/x DEI2 #0008 ADD2 DUP2 ( add 8 to x )
.Screen/x DEO2 ( store new x )
STH2kr ( copy limit from rs into ws )
LTH2 ,&loop-x JCN ( jump if x is less than the limit )
POP2r ( pop limit from rs )
RTN
```
## data
```
@tile-background 1122 4488 1122 4488
@paddle-sprite
&tile0 [ 3f 7f e7 c3 c3 c3 c3 c3 00 00 18 3c 3c 3c 3c 3c ]
&tile1 [ fc fe ff ff ff ff ff ff 00 00 00 00 00 00 06 06 ]
&tile2 [ c3 c3 c3 c3 e7 ff ff ff 3c 3c 3c 3c 18 00 00 00 ]
&tile3 [ ff ff ff ff ff ff ff ff 06 06 06 06 06 06 06 06 ]
&tile4 [ ff ff ff ff ff ff 7f 3f 00 00 00 00 00 00 00 00 ]
&tile5 [ ff ff ff ff ff ff fe fc 06 06 06 06 06 1e 3c 00 ]
@ball-sprite
&tile0 [ 03 0f 1f 39 70 70 f9 ff 00 00 00 06 0f 0f 06 00 ]
&tile1 [ c0 f0 f8 fc fe fe ff ff 00 00 00 00 08 0c 06 06 ]
&tile2 [ ff ff 7f 7f 3f 1f 0f 03 00 00 00 00 18 0f 01 00 ]
&tile3 [ ff ff fe fe fc f8 f0 c0 06 06 0c 1c 38 f0 c0 00 ]
```
whew!
# more possibilities
here are some extra possibilities for you to practice and try to implement:
* count and draw some sort of score
* change color of the ball and/or the paddle when they are colliding
* change the direction or type of bounce depending on the part of the paddle that hits the ball
* start the game when a button is pressed
* "random" initial direction of the ball
* variable speed of the ball and/or paddles
* etc!
share what you create based on all this! :)
# coming soon: day 7
that's it for now!
the following day of the {uxn tutorial} will consist in discussing all the remaining devices in the varvara computer.
meanwhile, i invite you to keep exploring, to share your findings, and to also take a break!
stay tuned!
# support
if you found this tutorial to be helpful, consider sharing it and giving it your {support} :)
Reference in New Issue View Git Blame Copy Permalink