First off, I'd like to say that it's cool that you are starting off simple. There are a lot of guys who shoot for writing a Quake Clone or Command and Conquer clone as a learning project. It's cool to see someone with a much more realistic target.

Well, you do have a logic error. You have the same basic error for both your X and Y axis logic, but let's look at your Y axis only right now. If you look at the Y case, your logic is only checking if the bottom of the ball is inside the brick.

It's really easier to write the logic for when they don't intersect. I would write it like so:

code:

if (!((BallX + BALLSIZE <= BlockX) | |      (BallX >= BlockX + BlockWidth) | |      (BallY + BALLSIZE <= BlockY) | |      (BallY >= BlockY + BlockHeight))){    // Now we have a hit...do whatever}

That's probably about the best you can do. You can precalculate the width and height additions (have the X and Y coordinates of the bottom right corners precalculated) to get a slight speed boost. One thing that's cool about this method is that short circuiting will cause this to potentially exit early. In other words, this is an OR statement with 4 tests, as soon as it hits one true, it breaks out.

Three warnings for you now:
1) This only really handles rectangles. If you want your ball to be a ball, I recommend looking into sprite collision in general. If you do create a sprite collision library, this code is usually the first check to see if the sprites collide. Then you have to look at the image data to determine collision.
2) If the ball moves really fast and your framerate sucks, you could have the ball basically move so fast (moves too great of a distance) it misses the block entirely.
3) In a break out game, you really might want to calculate where the ball would have actually hit the brick. In other words, you are checking to see when the ball is inside the brick, not where it WOULD have hit it given the ball could only move 1 pixel at a time. If you are detecting collision when it is inside the brick, redirection off of the brick might look weird, since it won't be starting at the exact point where the ball would have hit the surface of the brick.

Let me know if you have any questions, and good luck with your game.

------------------

-Kentamanos

I'm working on a breakout style game right now too. And, I too am struggling with the collision detection code.

I don't have everything worked out, but, I think I need to check BOTH for collision and the direction of the collision. Without the direction of the collision, you don't know how to modify the speed of the ball.

I convert the x,y coords of the ball into brick coords based on the direction of the ball. (i.e. moving left and up = top left corner of ball for collision, moving right and down = bottom right corner of ball for collision)

Good luck. I'm interested to see what you come up with.

marc@mcmmedia.com

I found the answer for my breakout game.

Compare the rectangle around your ball with every brick on the screen (or you can only check bricks close by). If the two don't overlap then no collision occured. If they do check the overlapping area to see if it's taller or wider. This tells you if a X or Y collision occured. It's not perfect but it is close enough to please most people.

My breakout game is just a learning experience anyways so it doesn't have to be perfect.

marc@mcmmedia.com

The best way I think it should be done is...

Use a RECT for each sprite (the block) and a POINT for the ball, then use the Win32 function PtInRect() to determine if the POINT you are checking (the ball) is located in the sprite's RECT.

Easy .... ;-| -= SiKcIv =- |-:

Ok, I'm gonna break this down into multiple posts to make them easier to read and find, also, because it's 4a.m. where i'm at, I am going to delay most of the coding examples until tommorow. So expect another post about 12-24 hours from now. This post is going to make sure eveyone has the same basic understanding and core logic concepts.

Note: these discussions assume you do not mind incorrect collision detection at corners, instead they really treat the ball as if it's a bouncy block (which isn't as bad as you might think).

First, if you only need to know if the ball hit a block, and not where it hit or where it should end up (say collision is death or something) Kentamanos's post is right on the money.
Please take a moment to understand though his statement about the ball moving too fast. In any game with movement(that uses this type of collision detection), to avoid objects flying through each other, no object should move fast enough that it might jump past the smallest object on your board. If multiple objects are moving, then the max velocity any object can move in "ONE GAME UPDATE" is:
MAX_VEL = 0.5 * LENGTH_OF_SMALLEST_OBJ;
at least for simplicity. Or in a somewhat move complex world it could be:
MAX_X_VEL = 0.5 * SMALLEST_X_DIMENSION;
MAX_Y_VEL = 0.5 * SMALLEST_Y_DIMENSION;
or if this posses a problem because there are really small objects which are forcing your main objects to move to slow...try:
MY_MAX_VEL = 0.5 * MY_SMALLEST_DIMENSION;
where each main class of object has its own max speed(probably implemented with either class constants or simple global constants).
Enough about max speed...

Time to explain the "ONE GAME UPDATE" concept.

A "GAME UPDATE" is distinct from a "FRAME UPDATE". Without a distinction, we would suffer like Kentamanos mentioned, from the fact that the game would suffer from missed collisions if the frame rate isn't high enough. And even though our MAX_VELOCITY ideas avoid that, they force the game to run REALLY SLOW if you are tied to the frame rate. So here are my definitions:

a "GAME UPDATE" - is the process of moving the objects and testing for collisions and such.

"GAME RATE" - would be how many times per second the above precess is run.

a "FRAME UPDATE" - is the process of rendering (bliting for 2d of course) the game information to the screen.

"FRAME RATE" - is how many times per second the screen is updated for the user.

typically in my simply programs the GAME RATE is two to three times faster than the FRAME RATE. Of course this varies for different machine specs.

One of the great things about coding your programs with this seperation is that it becomes a simple matter to taylor your game to slower machines and poor video cards, by lowering JUST the FRAME RATE...this allows the game to run at the exact same speed on different computers (as long as they can keep up with the requirements of the game logic), but high powered computers can get faster frame rates and, therefore, smoother animations.

Is there a reason that your GAME RATE should be faster than FRAME RATE? Right now my code runs the gamepulse() function 30 times a sec and framerate is free to go as high as possible. Is this going to cause problems?

Thanks,

Marcus
marc@mcmmedia.com

Hello!
I'm a new programmer, and I'm making a simple BreakOut game.
How can I check if the ball hited its target?
I have the ball width & height and the block width & height.
I have tryed to do this:

if (((BallY + BALLSIZE) >= BlockY) &&
((BallY + BALLSIZE) <= (BlockY+BlockHeight)) && ((BallX + BALLSIZE) >= BlockX) && ((BallX + BALLSIZE) <= (BlockX+BlockWidth)))

But it doesn't work well.
Anyone can help?

Honestly, a game rate that is faster than the screen refresh and/or frames per sec is all but worthless! What's the point of caluclating data if you are not going to display it! If you really want a fool proof way to detect and handle collisions in a simple game like breakout, consider the following:

Every frame, calculate the new position of the ball based on it's previous position and velocity etc etc. Then, mathmatically draw a line between the LAST position and the current position. Then, run a simple intersect test against the sides of all the possible blocks that it could have hit. _IF_ there is an intersection, we have a collision! Walk back to the time that the intersection occurred, when the ball would have hit the block (sometime between the current and last frame), change the velocity however you want to reflect the collision, then calculate the block's REAL position using the the new velocity, position at the collision, and the time delta between the collision time and now.

With that method there is not much overhead, no need to stupid extra calculations that never make it on the screen (and therefore as a side effect the frame rate will go up!) and no more reliance on a fast frame rate whatsoever.

I hope that helped. I never had thought of this type of problem before, but this whole thread has got me wanting to make a breakout-type game myself (with a few twists, of course!).

- Splat