Lesson 2: Player sprites and missilesTopics:Make a sprite appear in the center of the screenLoad a different sprite besides the defaultEdit sprites and expand the inline sprite libraryMoving sprites around the screen using Assembly or bBSprite Animation using Assembly or bBMake a sprite appear in the center of the screen
To make a sprite appear, simply set it’s X and Y coordinate variables to the desired positions.
To make a sprite vanish, you set it’s X and Y coordinate variables back to zero.
Since this is our first topic working with the ASDK we’re going to use this blank template to start our project and add our code to the initialisation and game loop sections:
Open it up for editing as shown below, find the initialisation section and add the purple code as shown:
Save it and then compile and launch it in the other window like this:
You should see the corner of the virtual world displayed in the playfield with two sprites in the center of the screen:
Here’s what’s going on with the purple code:
“LDA” is an Assembler command for loading the Accumulator
which is like an internal temp variable on the CPU; there are three of these registers (A,X and Y) and access to regular variables must go through them.
“LDA #45” tells the 6502 to put the number 45 into the Accumulator
(note that the # prefix means we are using the number 45 rather than the contents of memory location 45; this is important).
The next instruction “STA player0y” does just what you think, it puts that 45 into a player sprite Y variable, player0y
Then we load the accumulator with values for our sprites X axis variables spaced a bit apart so we can see them next to each other.
This isn’t very different in bB:player0y=45:player0x=45:player0x=70:player1x=80
Later in this chapter we will use bB to compose and import a complex Assembly
logic block for moving and animating our sprites, but first we will cover some more topics you will already find familiar.Load a different sprite besides the default
In bB you must also load a sprite definition, we didn’t do that above but if you scroll down the init section a bit you will see this is done much the same way:
Again, here’s what’s going on with the purple code:
“LDY #0” is an Assembler command for loading the processor’s Y register with the number 0 (#0); in this case we are using the Y register to pass an argument to our sprite loading subroutines; “JSR” is just GOSUB.
I’ve split the screen to show the inline sprite image library section; you can probably guess that arguments #0 and #8 load images 1 and 2 respectively.
You can change the Y argument values to load different images from the sprite library either in the initialisation section like we are doing now, or on the fly in our game loop for animation sequences which we will do later JEdit sprites and expand the inline sprite library
Go ahead and edit the WYSIWYG sprite definitions you see or add additional sprite definitions – there are about 10 in the inline library right now and there are room for 32 sprite images (it’s not a space issue just the constraints of the table size).Moving sprites around the screen using Assembly or bB
We can use the bB compiler to write complex Assembly
logic blocks for the ASDK both to help learn Assembly
and for reusing complicated routines without rewriting them! This works out very well in practice.
Here’s a bB routine to move the player sprites all the way across and halfway across the screen, respectively:
We just compile it and insert the generated Assembly
block into the Game loop section of the ASDK as shown:
Then we can save and compile our ASDK file and the code works fine!
Here’s what’s going on in the compiler generated code, it’s not too different than BASIC:
“LDA player1x” loads the player1x variable into the Accumulator,
“CMP #150” compares the contents of the Accumulator to the number 150.
“BNE .skipL014” means Branch if not equal to
or “goto .skipL014 if player1x <> 150”
“INC player1x” means increment the player1x variable directly or “player1x = player1x+1”
The rest is the same.
Now let’s add some sprite animation!Sprite animation using Assembly or bB
We already know that we can call loadplayer0 with an offset argument to load the selected image into the player0 sprite from the image library, but this function has no counterpart in the bB framework so what do we do if we want to model sprite animation with bB? We use a placeholder in place of this function and write the rest of our code:
Now we simply paste in the generated Assembly
block like we did before, but we edit our code as shown to replace the dummy code with the function call to load the sprite, passing our f variable argument:
(Note: Don’t forget to also init f to 24 in the init section since we want f to start at image 4)
Compile the code and you’ve got the smooth animation demo!
Here’s what’s going on:
“LDA f” loads the Accumulator
with the variable f
“CLC” clears the carry bit (we don’t want it when we add unless we’re doing 16-bit calcs)
“ADC #8” adds 8 to the contents of the Accumulator
“STA f” stores the new value back in variable f.
“LDA f” redundantly loads var f back into the Accumulator
(it’s still there)
“CMP #72” compares the Accumulator
to the #72
“bne .skipL026” jumps around the next two statements if var f <>72 (from our CMP statement).
Those next two statements reinitialise var f to 24.Chapter review
ed quite a bit of Assembly
already! Now review your source code and compare it to the pure Assembly
example used in the Abstract Assembly
Development Kit Thread.
source should look like this at the conclusion of this lesson:
And here is the Pure Assembly source from the ASDK thread
Note the Assembly
in both examples is nearly the same (the bB compiler is excellent)!
However you will also notice the pure Assembly example
is easier to follow with it’s friendly naming conventions; by contrast, the compiler cannot come up with descriptive and imaginative names but it does the next best thing by putting the bB code in comments (I always look at that).
It’s important to review both examples together; Assembly
output from a compiler is more cryptic and confusing to review without the bB source. For this reason you should never dissemble in Stella; if you want to look at how an interesting classic was programmed search AtariAge instead – other developers have probably already dissembled, analysed and produced a friendly or well commented source listing; that’s the kind of Assembly
you will absorb best. Looking ahead
Some really fun things are coming up next in lesson 3, particularly as we connect our examples together!Lesson 3 preview: Virtual Worlds and PlayfieldsTopics:Load a different virtual world (just like loading another playfield in bB).
Edit virtual worlds (like editing a playfield with bB).
Set pixels anywhere in the virtual world
Check pixel status and flip them
Pan the camera to any part of the virtual world
Scrolling around the virtual world using Assembly or bB.