#### Archived

This topic is now archived and is closed to further replies.

# Perfect collision for breakout-style game

This topic is 5887 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''m working hard on my new breakout style game (2D), and I''m trying to get perfect collisions. There are two problems: 1) When a ball hits a block, it has to bounce depending on where it hit the block. I can check if the bounding box of the block and the ball collide, that''s simple, but then figuring out what directions need to change for the ball is a bit trickier. Bottom line is this: given a ball''s x/y velocities and a collission occurs, you have to determine if the x-velocity gets negated, or the y-vel (I prefer not to have corner hits where both get negated, let it determine it it one way or the other, maybe even randomly on perfect corner hits) This is a little harder than I thought it would be. I pretty much have it down but its not very perfect, and it has a big flaw explained next: 2) Now this problem is the RELA problem that I have no idea how to fix except with a LOT of long and slow code. Sometimes the ball can speed up, and sometimes the framerate may get choppy, either way sometimes the position change of a ball over one frame might be enough to jump it over and entire block, or a corner of a block. Either way, it causes a collision that was supposed to occur somewhere in between frames to be missed. I was thinking of throwing out rays and checking for collisions with every block, but then I''d have to figure out which way the ray has to bounce on the collision (like problem 1), and then keep following the ray for the vector magnitutde it has, and check for more collisions, cause maybe it was a REALLY big lag and in a flawless model the ball was supposed to hit one block and then another. Hopefully you get my point. Now bear in mind the board is a 20x15 grid and the balls can get trippled, so say there can be up to 50 balls at an extreme, don''t want to deal wtih al the raycasting math i think it would be too slow. Whew, im tired, hope that made sense and people reply - Rob ByteMe95::~ByteMe95() My S(h)ite

##### Share on other sites
Hehe
I remember having this problem - unfortunately (as I often do) I didnt finish the game

I never fully solved the problem actually, but one very bad way is to move the ball incrementally, and check each position.
eg. To move the ball 18 units, move it 5+5+5+3, each time checking the position.

This still doesnt completely solve the problem, but like I said I never actually finished anyway
(I think I got disapointed at myself for the crap work in it

I will be very interested to see other game developer''s ideas on this one - because ray casting is the only decent idea that comes to mind for me.

##### Share on other sites
Assuming you have the perfect collision point at the surface of the bbox: if the bounce is detected when ball.y>box.miny && bally<box.maxy then you got a side hit (ball.x = -ball.x) otherwise you''re on the front or back of the tile (ball.y = -ball.y) of course your detection algorithm better deal at least with a line~box intersection if you intend to get the exact colission location.
Now it seems like you really need a raycasting if you deal with frame drop and stuff. But sure altought it may run realtime on moderns machines I believe there''s a more clever approach than the Brute Force one. If your tiles are fixed width and height you can consider your tile map as a ''screen'' (where tiles would stand as pixels) and then trace the line from old position to new position using an algorithm wich will ''hit'' all the ''pixels'' the line cross, I''m not sure if Bresenham can do that... you get the first tile hit using this technique then you refine using some stupid if () then () algorithm to find the exact collision point. That''s similar to the first step in raytracing an octree.

##### Share on other sites
anon: problem with that is that I dont always get the EXACT point of collision because of the jumpiness of the ball. Which leads us again to ray tracing. Of course the ball is 16x16 in pixels, so what ray do i trace? I figure i should trace the ray from the cetner of the ball and extend the box lines out by 8 pixels on each side when checking against them.
Your idea sounds interesting with treating the blocks as pixels, but once I find all the intersections, i gotta determine the exact point of contact again.
I thnk the ball should really be thought of as a 16x16 BLOCK, might be easier to envision

ByteMe95::~ByteMe95()
My S(h)ite

##### Share on other sites
As for the detection of a hit in between frames...

One quick way you could do this rather than moving incrementally one pixel at a time (yuck!) is create an axis-aligned bounding box of the vector of the ball''s movement from its last position to the next position, then comparing this AABB to the AABB''s of your blocks. AABB compares are very fast and should quickly reject most of the blocks. Then you could do your more careful collision checking. Honestly if all of your blocks are axis aligned boxes of some sort, you will probably be able to come up with some really quick collision detection for it.

I''m not sure if this was your question but I only had a minute while my program was linking.

##### Share on other sites
hmm, I have no idea how to make the ball''s vector axis aligned

I also have to check, as i said, 300 blocks (well i skip inactive/dead blocks) per ball, which i established as max 50. Will these axis aligned collisions run fine wtih all that?
Also, Once i do find a collision using that, I have to compensate for it, if you lok at problem 2 what is the ball is supposed to bounce of a collision and then is suupposed to collide with another block? Another round of collision detecting tests.

ByteMe95::~ByteMe95()
My S(h)ite

##### Share on other sites
Get starting and ending position of your ball.
Just get all the blocks inside this box, that should be pretty straightforward and if the game is fast enough, you will end up with only 1 to 9 blocks.

On those blocks, you can already skip all empty spots and you end up calculating two line-line collision per filled block depending on the ball's direction. Usually this will be 2 to 6 line-line collision per ball per frame and these aren't slow at all.

EDIT : Corrected a logic error

[edited by - Coincoin on August 29, 2002 6:07:36 PM]

##### Share on other sites

Well yes doing it in several pass is your best bet. Each pass should go straight. If it rebounds, you use the collision pos as a new starting pos for another collision pass. However, those cases are going to be very rare, especially if your game is fast, so it won''t significantly slow down the game.

##### Share on other sites
Isn't that basically the same way a billiards game would be handled? Parse for the first collision, move up to that point, affect all velocities in the earliest collision, then do another parse using the new velocities, and repeat, until the time elasped since the last frame is used up?

I can't think of any other way to do that. So coding for a perfect collision might set you up well for additional collision challenges in the future.

[edited by - Waverider on August 29, 2002 6:31:32 PM]

##### Share on other sites
coincoin: sounds interseting, I may try that.
A few questions: How would i know which blocks to check based on the balls starting and ending positions? I can see how I could get the cell of the starting and ending pos, say they come out to be 4,4 and 5,3 (ball going up and right), but then which blocks do i check? it wont always be a perfect 9 block squasre from the beginning to ending pos.

Also, from what I can understand and the way i do it now (for another part of the game, i also do line intersect tests between the ball and the blocks), for each block there are 4 intersect tests per ball since I have to check every wall of every block (4) to get the proper intersection, why did u say it would take 2 line-line collision tests per block?

thanks for all the help guys

ByteMe95::~ByteMe95()
My S(h)ite

1. 1
2. 2
3. 3
Rutin
16
4. 4
5. 5

• 14
• 9
• 9
• 9
• 10
• ### Forum Statistics

• Total Topics
632912
• Total Posts
3009183
• ### Who's Online (See full list)

There are no registered users currently online

×