Just foolin' around, folks.

[+atari2600land]

...and I made this little block-breaking demo. I figured it would be a heckuva lot easier to program if the "ball" was made of four different parts. The top of the ball is missile1, the bottom of the ball is the ball, the left side of the ball is player1 and the right side of the ball is player0. If someone could help me with the blocks actually disappearing once the ball touches them, we might be able to make an actual game here.

brickout052807.bas.bin

brickout052807.bas

Edited May 29, 2007 by atari2600land

[Nukey Shay]

First of all, the screen needs to be read from ram memory. Bb already has you put at a disadvantage there...where a good share of ram has already been eaten up by the interpreter. IMO it would be easier just to hack the breakout game itself (custom walls are easily done, but the 4-part ball would be a problem).

 

Speaking of the ball, why use 4 sprites? Just 1 of the players would do for a sprite that size (or increasing sprite width of the ball sprite could do it).

[potatohead]

bB has the RAM playfield. The very first thing I did was make a crude breakout game with the early alpha release. It all worked just fine --I just never finished it because it was a test to validate bB more than a game effort.

 

There is plenty in bB now to make a very interesting breakout game, IMHO.

 

Make your ball one sprite. No need to make it a four sided thing. I'm sure you were thinking about using that element to control bricks and ball bounce, but you don't need it. Some if - then statements and a small amount of logic thinking through the ball states at different times will get you through.

 

When a collision is detected between the ball and the playfield, you compare the ball position to that of the bricks and erase the closest brick.

 

ballx / 4 = brickx (do some math to figure out which brick to erase)

 

At the same time, you flip the motion of the ball, which gets you the bounce.

 

Be sure and constrain the position of the ball such that it never touches the playfield edges, or you get false collisions.

 

It's easiest if you have a motion component you can change, so that bouncing the ball ends up being changing the sign of either the x or y motion vector.

 

ballx = ballx + ballxmotion

 

where ballxmotion = a positive or negative number, depending on how it's gonna bounce.

 

You will have if statements for the playfield edges that set the motion to known values. eg:

 

if ballx < left_playfield_side_limit then ballxmotion = positive_value

if ballx > right_playfield_side_limit then ballxmotion = negative_value

 

The key to the bricks is that hitting one simply changes the sign of the ballymotion! Hit a brick, just end up going the other direction in the y, leave x alone --or not, if you want to have some fun with your game.

 

And there is paddle support now! This is perhaps the biggest reason I never did much early on. Breakout is just no fun with no paddle...

Edited May 29, 2007 by potatohead

[+batari]

There is plenty in bB now to make a very interesting breakout game, IMHO.

Using pfcolors and pfheights you could make something close to the original.

[+atari2600land]

bB has the RAM playfield. The very first thing I did was make a crude breakout game with the early alpha release. It all worked just fine --I just never finished it because it was a test to validate bB more than a game effort.

 

There is plenty in bB now to make a very interesting breakout game, IMHO.

You could make a better Breakout than I ever could.

 

Make your ball one sprite. No need to make it a four sided thing. I'm sure you were thinking about using that element to control bricks and ball bounce, but you don't need it. Some if - then statements and a small amount of logic thinking through the ball states at different times will get you through.

I don't think I have the bB know-how to do this. Right now, I have four motions, up/left, up/right, down/left and down/right, each to their own variable (a{1}, a{2}, a{3}, and a{4}) If, for example, the ball hits the playfield border and it's going up/left, then I change it to go up/right, and once it hits the top, I change it to go down/right, etc.

 

When a collision is detected between the ball and the playfield, you compare the ball position to that of the bricks and erase the closest brick.

 

ballx / 4 = brickx (do some math to figure out which brick to erase)

 

Is there a certain command to erase a brick, or do I use pfread? I don't even know how to use pfread yet.

 

Be sure and constrain the position of the ball such that it never touches the playfield edges, or you get false collisions.

right now, the code that covers that is:

 if collision(player1,playfield) && b<24 then k{0}=0 : k{2}=1 
if collision(player0,playfield) && c>125 then k{0}=0 : k{2}=1
if collision(missile1,playfield) && f<17 then k{0}=0 : k{2}=1

 

And there is paddle support now! This is perhaps the biggest reason I never did much early on. Breakout is just no fun with no paddle...

I should experiment with the paddle. Anyone have some example code?

Edited May 29, 2007 by atari2600land