Collision Detection == OK, But where did the ball come from?

Started by
2 comments, last by LoneStranger 21 years, 6 months ago
I'm trying to implement a ball bouncing around a screen with some bricks. I can detect when the ball hits the bricks, and I have a rudementary system to determine which direction the ball needs to bounce. When a collision is detected, I check the distance to each of the edges, and the one with the smallest absolute difference is where the ball came from, and it should bounce back in in that direction. The problem is when the ball bounces too close to one of the edges, it doesn't bounce back the right way. For example, if the ball is coming from the top, and it intersects too close to the upper right corner, it may bounce off like it came from the right side, instead of the top. This looks especially wierd if I have too blocks next to each other, they can cause the ball to bounce back in the same direction it just came from. The ball data is (x,y), (dx,dy), height and width, displayed as a square. The block data is (x,y) and height and width. At every update, (x,y) is changed by (dx,dy). My question isn't so much how to fix this, but if there is a better method to determine the direction the ball should bounce. I understand angle in == angle out. I need to know how to figure out which side of the block the ball hit. I've searched over the web for it, and everyone seems to know about detecting collision. I don't need to know that, I'm comparing rectangles, that's easy. It's the bounce direction I have problems with. Thanks. £§ [edited by - LoneStranger on October 19, 2002 4:17:23 PM]
£§
Advertisement
A - normalized incoming vector
B - normalized outgoing vector
N - surface normal (of course normalized)

B = A - 2 * (A dotproduct N) * N
Yea, that''s all fine and dandy.

I found that at numerous sources, I understand it completely.

My problem is determining the side that it hits. If I can''t find that out, I can''t get N, can I?

£§
£§
You might need to update your collision detection to look for the actual point of collision instead of just seeing if the ball is colliding with a cubic volume.

The point of collision algorithm should tell you which rectangle it actually struck (I can understand where your algorithm might not know which side it struck if it strikes a corner)

So, if the ball collides with the cubic volume, THEN determine the point of collision (which will involve the ball's previous position and a movement vector as part of the algorithm). Sorry, I don't have a detailed algorithm to spit out for you, other than checking for the point at which the center of the ball is the "ball's radius" distance away from the plane of the side you are checking the collision against, and seeing if that point is actually inside the rectangle defining the side.


[edited by - Waverider on October 19, 2002 7:11:18 PM]
It's not what you're taught, it's what you learn.

This topic is closed to new replies.

Advertisement