1
First we select some kernel options. In this example, sharp-looking sprites are more important than missiles.
set kernel_options playercolors player1colors pfcolors set smartbranching on
We define some coordinate variables for our four noble sprites, as well as two additional variables to measure the framerate and the currentframe.
dim sprite1X = a dim sprite1Y = b dim sprite2X = d dim sprite2Y = e dim sprite3X = g dim sprite3Y = h dim sprite4X = j dim sprite4Y = k dim gameFrame = m dim fspeed = n
Next, initialize the game and give our sprites some starting positions.
playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ end COLUBK = $E0 sprite1X=30 sprite1Y=48 sprite2X=60 sprite2Y=48 sprite3X=90 sprite3Y=48 sprite4X=120 sprite4Y=48
Our gameloop is responsible for doing three main things.
- Count its own iteration (fspeed)
- Keep track of which frame all the sprites are in (gameFrame)
- Determine whether the current loop is an even or odd number
Inside the loop, fspeed tells the sprites to advance one frame every six gameloops. It also keeps track of which sprites player0 and player1 should draw. In this example, player0 draws sprites 1 & 4, and player1 draws sprites 2 & 3, and the subroutines that update them are balanced on either side of the drawscreen.
gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 if temp1 then updateSprite4 updateSprite2 temp1 = fspeed & 3 gosub Sprite2 goto DrawFrame updateSprite4 gosub Sprite4 DrawFrame drawscreen updateSprite3 gosub Sprite3 updateSprite1 gosub Sprite1 goto gameloop
The subroutines themselves don't do much in this sample, except to repostion the player sprites to the appropriate xy value, and instuct it to go to its animation routine.
Sprite1 player0x=sprite1X : player0y=sprite1Y : goto Sprite1Frames return Sprite2 player1x=sprite2X : player1y=sprite2Y : goto Sprite2Frames return Sprite3 player1x=sprite3X : player1y=sprite3Y : goto Sprite3Frames return Sprite4 player0x=sprite4X : player0y=sprite4Y : goto Sprite4Frames return
Finally, we animate the sprites by looking at the current value of gameFrame. Since gameFrame caps at 8, our sprites have a ceiling of 8 possible shapes in their animation. Of course, they don't have to have 8 different frames. And probably shouldn't, if you want to create the illusion that they are moving at different rates.
Sprite1Frames on gameFrame goto Shape1_1 Shape1_2 Shape1_3 Shape1_4 Shape1_4 Shape1_4 Shape1_3 Shape1_2 Sprite2Frames on gameFrame goto Shape2_1 Shape2_2 Shape2_3 Shape2_4 Shape2_1 Shape2_4 Shape2_3 Shape2_2 Sprite3Frames on gameFrame goto Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_1 Sprite4Frames on gameFrame goto Shape4_1 Shape4_2 Shape4_3 Shape4_4 Shape4_5 Shape4_6 Shape4_7 Shape4_8 rem After this, you can draw all your purty graphics...
That's it! The attached source has some additional comments in it. I'm pretty new to batari programming, so I'm sure there are many other and better ways to do these sort of things. But I thought that maybe this general method might be useful for a few folks out there.
Cheers,
Jarod
Attached Files
-
4_multicolor_sprite_flicker.bas.bin 4K
64 downloads
-
4_multicolor_sprite_flicker.bas 12.67K
48 downloads
Edited by jrok, Sat Oct 4, 2008 12:18 PM.
