# (beginner) Collision detection with boundary and part of an item

• Hello all,

I trying to build the classic brick "breaking game":http://en.wikipedia.org/wiki/Brick_Breaker". For those of you who don't know what this is - you have a paddle that you use to deflect a ball bouncing around. The aim is to break all the bricks in the scene. As you can see it involves collision detection with the wall and the brick.

Here is a picture for your reference
!http://i48.tinypic.com/1199ylu.jpg(Picture)!

I looked at collision detection in Qt. I figured out that you can find the item with which something collides and you can do something when a collision happens (QGraphicsItem::collidingitems, QGraphicsItem::collidesWithItem and QGraphicsItem::collideswithPath)

I have two questions -

1. How do I detect collision with the boundaries (collision 1)?

Should I have a hidden QGraphicsItem at the boundaries? Should I place a QPainterPath at the boundaries and use collideswithPath? Or should it be a line? What is the best approach? I can of course check if the distance between the center of the ball and the wall is less than its radius, but just wanted to know if this could be done with Qt's collision detection methods.

1. The velocity of the ball after it collides with the brick depends on where it collided (collision 2 and collision 3) . My understanding is that we can only check if the ball collided with the brick or not and not where it collided. Ball.collideswithItem(Brick) returns true whether its collision 2 or collision 3. How do we distinguish between collision 2 and collision 3?

Thanks!

• Generally I would discourage using Qts collision detection in games. Imagine a thin paddle and a fast ball. With Qts primitive collision detection, the ball might go right through the paddle, because the ball moves from one side to the other side of the paddle in one frame interval. However, usually you want your game to run in real time, not CPU time, so you will make your physics independent of the graphics framerate. Otherwise someone with a slow PC might experience this tunneling effect strongly while it runs fine on your high-end PC. Simply because his PC doesn't calculate as many intermediate physics steps as your PC, and thus doesn't ever catch the collision between the ball and the paddle.

You should do it with linear algebra. The ball has a vector which represents the movement between two physics steps. Calculate the closest intersection of that vector with any collidable object edges (e.g. the four sides of a rectangle). This can be solved analytically, as it's just an intersection of two lines with bounded parameters. If such an intersection occurs, calculate the ball's exit vector via the surface normal and the incident vector (simply mirror and invert the incident vector at the surface normal). Then propagate forward in that new direction depending on how much time is left of the physics step interval. This way you cover all kinds of collisions, even with non-rectangular shapes.
If you want to excert forces on your objects, read up on runge-kutta integration methods (typically of order 4 for games), see "RK4 methods":http://en.wikipedia.org/wiki/Runge-Kutta_methods and "Integration basics for computer games":http://gafferongames.com/game-physics/integration-basics/.

• Hi DerManu.. thanks for your reply. My game is just an OpenCV Qt integration project for a computer vision demo. I dont care much about being able to run it on another PC, but I will keep your suggestion in mind in case I proceed with developing this into a full-fledged game.