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
