Collision Detection Question

[Lauren Tyler]

OK, I'm starting to understand that way bBasic works (finally,) but I have some questions about collision detection.

 

First of all, I'm guessing that walls and such are defined as sprites within bBasic, but how do I program it to detect if my player sprite is touching the wall and keep him from going through it.

 

And secondly, do I have to manually program my game so that if the player reaches an edge of the screen, they'll come out on the other side, or is that automatic?

[jbs30000]

OK, I'm starting to understand that way bBasic works (finally,) but I have some questions about collision detection.

 

First of all, I'm guessing that walls and such are defined as sprites within bBasic, but how do I program it to detect if my player sprite is touching the wall and keep him from going through it.

 

And secondly, do I have to manually program my game so that if the player reaches an edge of the screen, they'll come out on the other side, or is that automatic?

There are two sprites, 8 pixels wide, and as high as you want them to be (not sure what the limit is), two missles, 1 pixel high and 1 to 8 pixels wide, and a ball, again 1 pixel high, 1 to 8 pixels wide.

 

For your other questions, this site http://www.randomterrain.com/atari-2600-me...c-commands.html should have all your answers. Specifically for the collision http://www.randomterrain.com/atari-2600-me....html#collision

 

Hope that helps.

[+batari]

First of all, I'm guessing that walls and such are defined as sprites within bBasic

Walls are usually made with the playfield.

And secondly, do I have to manually program my game so that if the player reaches an edge of the screen, they'll come out on the other side, or is that automatic?

Yep. The left edge is 0, the right edge is 159, the top is about 0 and the bottom is about 88 (actual top and bottom depend on sprite height, playfield height and a few other things) but it's still not hard.

[Lauren Tyler]

Thanks for the info. Now if I just had some graph paper. XD

[kenfused]

Thanks for the info. Now if I just had some graph paper. XD

If you have a printer print your own. Try here: http://incompetech.com/graphpaper/ or just punch "graph paper" into google to get lots of links

[+Random Terrain]

Thanks for the info. Now if I just had some graph paper. XD

If you're doing old style walls, this toy might be helpful:

 

http://www.randomterrain.com/atari-2600-me...ml#playfieldtoy

 

It won't be much help with the newer stuff though.

[SeaGtGruff]

OK, I'm starting to understand that way bBasic works (finally,) but I have some questions about collision detection.

 

First of all, I'm guessing that walls and such are defined as sprites within bBasic, but how do I program it to detect if my player sprite is touching the wall and keep him from going through it.

That depends on how you want it to behave. If you want the player to stop as soon as it touches the wall, without ever actually "colliding" or overlapping pixels with it, then you need to convert between player coordinates and playfield coordinates, so you can prevent the player from moving into a position where it will overlap the playfield. That can be tricky to program, especially if your player has a funky shape.

 

The easier approach is to let the player collide with the playfield, but bounce it back as soon as that happens. Examples of doing this have been posted in this forum.

 

And secondly, do I have to manually program my game so that if the player reaches an edge of the screen, they'll come out on the other side, or is that automatic?

That might be semi-automatic with left-right movements, because as a player moves off the right side of the screen, it wraps around to the left side. But to do it well, you need to check the x coordinate and adjust it as needed when the player is moving off the left or right sides of the screen.

 

Vertical motion must be programmed manually, there is no "automatic wraparound."

 

Also, you need to consider such things as where the boundaries of the game's screen are. For example, bB doesn't use the PF0 register, so if you're drawing the walls of your screens with PF1 and PF2, that means the left and right edges of the screen are essentially moved inward, therefore you can't use the "automatic wraparound" feature at all.

 

Or, if you want the player to "slide" into view a pixel at a time, then you need to actually modify the player shape as it's sliding onto the screen, otherwise the player will seem to just appear all at once at the edge of the screen.

 

Michael