Breakout collision detection
Author
I''m making a generic breakout clone in order to learn some more about making games and i''ve stumbled across a problem with collision detection. Do i have to check if the ball''s position is within any of the blocks on screen at any one time? if so, with 10x10 (100) blocks would this not be slow to calculate at the start of the level and obviously get faster towards the end? or is there a non-brute-force method that i could use?
Goo
I'd make an array of blocks and give it a struct with something like (pseudocode)
Next, you should check if the Rectangle surrounding the ball is in contact with any VISIBLE block rects. So make sure it's something like
I hope that helped. I'm not in the mood to write any code so. Bear with the pseudo-code.
--SuperRoy
[Google!][Stick Soldiers 2 Screenshot][E-Mail Me!]
[End Transmission]
[edited by - SuperRoy on September 14, 2002 6:42:39 PM]
[edited by - SuperRoy on September 14, 2002 6:45:11 PM]
struct Block{ RECT rect; BOOL visible; OTHER picture;} Next, you should check if the Rectangle surrounding the ball is in contact with any VISIBLE block rects. So make sure it's something like
for ( y'know)if (Intersect(Ball,Block[i]) && Block[i].visible == TRUE) I hope that helped. I'm not in the mood to write any code so. Bear with the pseudo-code.
--SuperRoy
[Google!][Stick Soldiers 2 Screenshot][E-Mail Me!]
[End Transmission]
[edited by - SuperRoy on September 14, 2002 6:42:39 PM]
[edited by - SuperRoy on September 14, 2002 6:45:11 PM]
With a simple breakout game its not going to slow things down. 100 simple collision checks aren''t going to be that bad. Just loop through all the blocks and if you find one that collides with your ball, then you can break out of the loop and forget about the rest of the collision checks. If you really want to get fancy, you could keep an updated list of all the blocks that the ball could possibly collide with. For example, at the start of the game its impossible to collide with anything other than the first row of blocks (if the 10x10 blocks span the whole width of the screen). This means that you only have to do collision checks with these blocks (only 10 checks). But basically your not going to run into any slow downs with this simple of a collision detection even if you check all 100 every frame.
RegularKid''s idea goes in with mine. ''cept it''d probably be easier just to use mine than to check only one row because you might have one column that''s like 6 rows deep but another that''s only 3. if you catch my drift.
The thing that's nice with breakout clones is that everything is organized into a nice little grid. The logic is not to check every block and see if the ball is inside it, but to locate the tile the ball is in and see if there is a block there. Let's just assume that you blocks are 100x50 pixels and they fill the entire screen (assuming this is also a 1000x500 resolution... don't ask 
). If our ball position is 780x123, we can divide each component by the size in that direction and get the grid coordinate. (780/100) = 0, (123/50) = 2. So we are in tile (0,2). If there is a block at that location, then we hit it. You might be thinking that we have to iterate each block anyway to see which one is at position (0,2), but depending on how you store the blocks you can completely skip that. For example, if your blocks are stored in a static 2D array, then you can just plug those numbers in as indices and there ya go. You can use a flag to determine whether a block is at that position or not.
[edited by - Zipster on September 14, 2002 6:48:11 PM]
). If our ball position is 780x123, we can divide each component by the size in that direction and get the grid coordinate. (780/100) = 0, (123/50) = 2. So we are in tile (0,2). If there is a block at that location, then we hit it. You might be thinking that we have to iterate each block anyway to see which one is at position (0,2), but depending on how you store the blocks you can completely skip that. For example, if your blocks are stored in a static 2D array, then you can just plug those numbers in as indices and there ya go. You can use a flag to determine whether a block is at that position or not.[edited by - Zipster on September 14, 2002 6:48:11 PM]
Author
lol, super-roy's idea was my first thought, regular kid's would probably complicate things with levels that are arranged in shapes - ie there's a "layer" of bricks that can be victims of collision (!) in an irregular pattern... hard to determine which bricks these are, no?
Anyway, I guess it won't slow down too much, my only problem before i start coding is fps-independent movement, etc... anyone point me to an article, there was one here once, but i forget where exactly...
thanks,
goo
p.s - i saw an article at gamesutra on pixel-by-pixel collision detection (by the glorious TANSTAFAAL). Is this a possibility? especially as the ball is, unsurprisingly, a circle and my primitive collision detection algorithm would count the corners of the quad as hitting the blocks...
[edited by - dammit on September 14, 2002 6:55:58 PM]
Anyway, I guess it won't slow down too much, my only problem before i start coding is fps-independent movement, etc... anyone point me to an article, there was one here once, but i forget where exactly...
thanks,
goo
p.s - i saw an article at gamesutra on pixel-by-pixel collision detection (by the glorious TANSTAFAAL). Is this a possibility? especially as the ball is, unsurprisingly, a circle and my primitive collision detection algorithm would count the corners of the quad as hitting the blocks...
[edited by - dammit on September 14, 2002 6:55:58 PM]
Basically, make your movement deltas based on the time between frames. So if your ball moves, or should move, at 2 units per second, and the time between the last frame and the current frame was 0.02 seconds, then you should move the ball 0.04 units (0.02 seconds * 2 u/s), which actually results in no visual change in movement. However, you still want to store that floating point number, otherwise if you store the integer it will keep rounding down and your ball stays put.
The other way is to wait for a second to ellapse and then update your ball's position, but using that method, your ball won't interpolate, and only jump 2 units every time, using the previous example.
[edited by - Zipster on September 14, 2002 7:00:30 PM]
The other way is to wait for a second to ellapse and then update your ball's position, but using that method, your ball won't interpolate, and only jump 2 units every time, using the previous example.
[edited by - Zipster on September 14, 2002 7:00:30 PM]
An add to Zipster post:
since your ball will be bigger than one pixel you should check the 4 ''corners'' of the ball sprite, because each of these corners could be in 4 diferents cells at a given time. or maybe hit 2 bricks at the same time.
since your ball will be bigger than one pixel you should check the 4 ''corners'' of the ball sprite, because each of these corners could be in 4 diferents cells at a given time. or maybe hit 2 bricks at the same time.
Yeah I was just assuming 1 pixel to keep things ultra simplified, but in general you won''t have a one pixel ball
But if you have a larger-then-single-pixel ball then you will need to use the bouding box to find out the tile the ball is in, and in this case, it could in more than one. You then just have to chose the best one based on where the ball came from.
But if you have a larger-then-single-pixel ball then you will need to use the bouding box to find out the tile the ball is in, and in this case, it could in more than one. You then just have to chose the best one based on where the ball came from.
I say go for pixel perfect collision detection.
After all, it''s a BALL ladys and gentelmen. Not a rectangle. It would look rediculous.
Ofcourse, do rectangle collision before, and if that succeeds do a pixel perfect one. That way you''ll keep the speed impact at a minimum.
zilch_
After all, it''s a BALL ladys and gentelmen. Not a rectangle. It would look rediculous.
Ofcourse, do rectangle collision before, and if that succeeds do a pixel perfect one. That way you''ll keep the speed impact at a minimum.
zilch_
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
