Newbie here. I need sample code for sprites?

[bluetriforce]

I am new to basic. Can you send me some sample code so I can learn how to code sprites and move the sprites with a joystick? I have alot to learn on batari basic. I have alot to learn about the 2600 playfield. I have also made this simple blue triangle using the pfhline command pictured below!!

 

 

Here is the sample code for this program listed below

 

10 set romsize 2k

20 COLUPF = 150

30 drawscreen

40 pfhline 4 6 9 on

50 goto 20

 

Thanks

[bluetriforce]

Sorry, I can't get this picture from my 2600 basic program so I am uploading the file

h.bas.bin

[+Random Terrain]

Have you looked at the code of programs that already exist? You might find a lot of useful things.

 

This isn't a sprite, but here is a simple thing I made one day that lets you move a block around the screen with a joystick:

 

 rem * Create alias for each variable.
 dim blockx = a
 dim blocky = b
 dim delay = d

 rem * Setup.
 COLUPF = 90 : delay = 0
 blockx = 16 : blocky = 5


 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 drawscreen

 rem * Begin delay.
 delay = delay + 1
 if delay < 3 then goto gameloop
 delay = 0
 rem * End delay.

 rem * Delete block and move it to new position.
 pfpixel blockx blocky off
 if joy0up && blocky > 1 then blocky = blocky - 1
 if joy0down && blocky < 10 then blocky = blocky + 1
 if joy0left && blockx > 1 then blockx = blockx - 1
 if joy0right && blockx < 31 then blockx = blockx + 1
 if joy0fire then score = score + 1
 pfpixel blockx blocky on

 goto gameloop

Edited September 8, 2005 by Random Terrain

[SeaGtGruff]

I am new to basic.  Can you send me some sample code so I can learn how to code sprites and move the sprites with a joystick?

927223[/snapback]

 

Try this out:

 

rem ***************************
rem * A simple sprite example *
rem ***************************
COLUBK = $08 : rem * Set screen background to gray
x = 50 : rem * x will be the sprite's column position *
y = 50 : rem * y will be the sprite's line position *
rem * Now we define the sprite's picture - a smiley face
rem * Note that we draw the sprite UPSIDE DOWN!
player0:
%00111100
%01000010
%10011001
%10100101
%10000001
%10100101
%10000001
%01000010
%00111100
end
loop
COLUP0 = $44 : rem * Set the player0 color to red
player0x = x : rem * Position smiley at column x
player0y = y : rem * Position smiley at line y
score = 0 : rem * Let's show the x,y location as the score
for t = 1 to x : rem * t is just a temporary variable
score = score + 1000 : rem * First 3 digits will be x
next
for t = 1 to y
score = score + 1 : rem * Last 3 digits will be y
next
drawscreen : rem * draw the screen
if joy0left then x = x - 1 : rem * Move the smiley left
if joy0right then x = x + 1 : rem * Move the smiley right
if joy0up then y = y - 1 : rem * Move the smiley up
if joy0down then y = y + 1 : rem * Move the smiley down
rem * We won't worry about x and y going off the screen.
rem * The smiley will "jump" at certain x values, but you
rem * can see what the "safe" x and y values are by
rem * watching the score.
rem * Also, the screen will likely flicker because of the
rem * for-next loops used to calculate the score!
goto loop

 

I hope it helps!

 

Michael Rideout

sprite.bas.bin

[SeaGtGruff]

Try this out:

927323[/snapback]

 

Sorry, the indents may not have come out when I pasted the code. Everything should be indented 1 space, except the line that says "loop".

 

To be sure you got it, I'm attaching the zipped source.

 

Michael Rideout

sprite.zip

[+Random Terrain]

Hey, I didn't think anyone would be up, so I converted my crappy little program above to move a sprite instead of a Playfield 'Pixel'. It stops you from going past the edges, just like my first program does.

 

 rem * Create alias for each variable.
 dim spritex = a
 dim spritey = b

 rem * Setup.
 COLUPF = 90
 player0x = 80 : player0y = 44
 
 rem * Create sprite 0.
 player0:
 %11111111
 %10100101
 %10100101
 %10111101
 %10111101
 %10100101
 %10100101
 %11111111
end


 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 COLUP0 = 28
 drawscreen

 rem * Move sprite 0.
 if joy0up && player0y > 10 then player0y = player0y - 1
 if joy0down && player0y < 89 then player0y = player0y + 1
 if joy0left && player0x > 15 then player0x = player0x - 1
 if joy0right && player0x < 167 then player0x = player0x + 1
 if joy0fire then score = score + 1

 goto gameloop

Edited September 8, 2005 by Random Terrain

[+Random Terrain]

Here's a better example than my last one. You control a sprite and there is also a ball bouncing around that you can bang into:

 

 rem * Here's a crappy little program I (Random Terrain) made as an example of
 rem * sprite movement with the joystick. You control a sprite and there is also 
 rem * a bouncing ball that you can bang into.
 rem * Don't worry, you are blocked from going past the edge of the screen.

gamestart
 rem * Create alias for each variable.
 dim spritex = a
 dim spritey = b
 dim directionx = c
 dim directiony = d
 dim directionx2 = e
 dim directiony2 = f

 rem * Setup.
 COLUPF = 204 : score = 0
 player0x = 93 : player0y = 54
 bally = 30 : ballheight = 1
 r = rand : if r > 30 && r < 155 then ballx = r else ballx = 30
 directionx = 1 : directiony = 1
 directionx2 = 255 : directiony2 = 255

 rem * Define player0 shape.
 player0:
 %11111111
 %10100101
 %10100101
 %10111101
 %10111101
 %10100101
 %10100101
 %11111111
end


 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 COLUP0 = 28
 drawscreen

 rem * Move player0 if joystick is used and don't allow border crossing.
 if joy0up && player0y > 10 then player0y = player0y - 1
 if joy0down && player0y < 89 then player0y = player0y + 1
 if joy0left && player0x > 15 then player0x = player0x - 1
 if joy0right && player0x < 167 then player0x = player0x + 1

 rem * Move ball and don't allow border crossing and detect collision with player0.
 if bally < 3 then directiony =  1 : directiony2 = 255
 if bally > 87 then directiony = 255 : directiony2 = 1
 if ballx < 16 then directionx = 1 : directionx2 = 255
 if ballx > 174 then directionx = 255 : directionx2 = 1 
 if collision(ball,player0) then directionx = directionx2 : directiony = directiony2 : score = score + 10

 ballx = ballx + directionx : bally = bally + directiony

 if switchreset then goto gamestart

 goto gameloop

Edited September 8, 2005 by Random Terrain

[+Random Terrain]

Here's the same thing as the last, except the code is a little shorter:

 

 rem * Here's a crappy little program I (Random Terrain) made as an example of
 rem * sprite movement with the joystick. You control a sprite and there is also 
 rem * a bouncing ball that you can bang into.
 rem * Don't worry, you are blocked from going past the edge of the screen.

gamestart
 rem * Create alias for each variable.
 dim spritex = a
 dim spritey = b
 dim directionx = c
 dim directiony = d

 rem * Setup.
 COLUPF = 204 : score = 0
 player0x = 93 : player0y = 54
 bally = 30 : ballheight = 1
 r = rand : if r > 30 && r < 155 then ballx = r else ballx = 30
 directionx = 1 : directiony = 1

 rem * Define player0 shape.
 player0:
 %11111111
 %10100101
 %10100101
 %10111101
 %10111101
 %10100101
 %10100101
 %11111111
end

 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 COLUP0 = 28
 drawscreen

 rem * Move player0 if joystick is used and don't allow border crossing.
 if joy0up && player0y > 10 then player0y = player0y - 1
 if joy0down && player0y < 89 then player0y = player0y + 1
 if joy0left && player0x > 15 then player0x = player0x - 1
 if joy0right && player0x < 167 then player0x = player0x + 1

 rem * Move ball and don't allow border crossing and detect colision with player0.
 if bally < 3 then directiony =  1
 if bally > 87 then directiony = 255
 if ballx < 16 then directionx = 1
 if ballx > 174 then directionx = 255
 if collision(player0,ball) then directionx = directionx^254 : directiony = directiony^254 : score = score + 10

 ballx = ballx + directionx : bally = bally + directiony

 if switchreset then goto gamestart

 goto gameloop

[SeaGtGruff]

Hey, I didn't think anyone would be up, so I converted my crappy little program above to move a sprite instead of a Playfield 'Pixel'. It stops you from going past the edges, just like my first program does.

927333[/snapback]

 

Thanks for posting that example with "safe" values in it. I didn't mention what the safe values are, because they depend on the size of the player, and I was already late for bed, so I didn't want to try to explain it right then. In fact, it's rather tricky to explain without using pictures.

 

Keep in mind that the 2600's viewable screen is 160 color clocks wide (ignoring the 67 color clocks which occur during the horizontal blanking interval), which we can number as 0 through 159.

 

A player's "x" position specifies which color clock its leading edge (leftmost pixels) will start in. However, in batari BASIC the leftmost safe "x" position is 15; that is, "player0x = 15" puts player 0's leading edge in color clock 0. So if the left edge of the screen is at position 15 (0 plus 15), that means the right edge of the screen is at position 174 (159 plus 15). However, "player0x = 174" puts the player's leading edge at color clock 159, so the rest of the player wraps around to the left side of the screen. To keep that from happening, we must back off as many color clocks as the player is wide, less 1. For example, if the player is 8 color clocks wide (or an 8-pixel-wide player displayed at single-width resolution), then we have to back off 7 color clocks (8 minus 1), which gives us a largest safe "x" position of 167 (174 minus 7). And if we're using a double-wide player, or a quadruple-wide player, then we have to back off an extra 8 color clocks, or an extra 24 color clocks, since a double-wide player is 8 color clocks wider than normal, and a quadruple-wide player is 24 color clocks wider than normal.

 

Furthermore, this assumes that all 8 pixels of the player shape are being used. If we're using fewer than 8 pixels (e.g., a "stick man" figure that's only 7 pixels wide), then we can add to the largest safe "x" position accordingly.

 

As for the "y" values, the standard NTSC 2600 screen has 192 scan lines (ignoring the 70 scan lines which occur during the vertical blanking interval), which we can number as 0 through 191. But batari BASIC uses the last 16 scan lines for the score area, leaving us with lines 0 through 175. And batari BASIC uses a 2-line vertical resolution, so we get 0 through 87 for the "double-line" numbers.

 

A player's "y" position specifies which double-line it *ends* in. "player0y = 89" is as far down as you can go before the player's bottom edge starts to disappear behind the score area. But the last double-line is actually double-line number 87, so that means we're adding 2 to the double-line number to get the player's "y" position (87 plus 2 is 89). Thus, if we want to put the bottom edge of the player at double-line 0, we would use "player0y = 2" (0 plus 2 is 2). However, this would be for a player that's only 1 double-line tall. For any other player height, we must move down by whatever the difference is. For example, if the player were 10 double-lines tall, then the smallest "y" value would be 11 (1 less than 10 is 9, and 9 plus 2 is 11), otherwise the top of the player would start to disappear beyond the top edge of the game's screen area.

 

Michael Rideout