You are over-complicating things. This is just a breakout game, not a physics demo afterall I dare say the collision works as well or better than any other breakout game I’ve tried lately (and I’ve tried dozens of them).
[quote]well that’s not complete:
At any givent moment, the ball is able to hit 3 bricks.
[/quote]
I was just playing the game again and thinking about what you wrote… how do you figure that the ball can ever be in a position to hit 3 bricks?
The ball is round, the “corner” between two diagonal bricks is square… a ball can only ever make contact with two bricks simultaneously, and my game deals with that just fine. It’s not physically possible for the ball to hit the “corner” brick, and it’s not possible (or shouldn’t be) in my game either.
Perhaps I misunderstand what you are trying to say?
[quote]If the ball is moving faster than 2.0 px/frame then the ball can hit multiple bricks in one frame. In a corner case the ball could first hit a brick to the left (which causes x *= -1) and in the next px movement hit a brick above it.
You would therefore potentially need to map the movement of the ball, especially if the ball can somehow move faster than brickheight/width + ball height/width. In which case the ball could move over a brick.
[/quote]
Yes, if the ball was moving more than 15 pixels at a time (which my game does not allow) it could skip over bricks, but other than that I don’t think I follow you.
Just for kicks I made the ball move 12 pixels at a time and lowered the frame rate to twice a second. I couldn’t see a single instance where the ball/brick collision did not work as one would expect. When I bumped it up to 20 pixels it occasionally skipped a brick and took out the one on the other side of it, but that’s not really an issue since the game doesn’t allow balls to travel that fast normally.
Fantastic game! Especially like the sound - fits perfectly with the graphics, if you know what I mean. The cartooney atmosphere with the zany concept and the old occasional bleep and woop. Excellent.
You might want to take a look at xboing (available under all UNIX-like OSs, not sure about Windows). They solved the vertical-mouse-position thing by turning the mouse cursor into a small black dot, one pixel in size. It didn’t interfere with the game but still let people know where the mouse was.
Also, xboing has an excellent launching system - there is a semicircle above the bat when it’s holding the ball with a pointer in it that moves back and forth. When you launch the ball it goes in the direction of the pointer - that bit of extra control is very handy.
I definitely agree with more control over the direction of the ball by hitting it differently with the bat too.
Nice job!
I said that the ball could theoretically move such that it hits 3 bricks, when dx, dy have been added to x, y. However since the movement would collide with the bricks to either side BEFORE hitting the diagonal brick this case will never occur. As said this is just theretically - not something to ever account for - just food for the mind
Btw: Looove the background - reminds me of my graphics - WHY can’t programmers do graphics - it is mindbogglingly weird …
Ah, sorry, misunderstood you.
In my code I move the X first, check for a collision, then move the Y and check for a coliision again. I think this eliminates the problem you describe (ie: it can’t skip over a brick by going over a corner of it). As long as the ball can never move more than 16 pixels in X or Y then it should always collide properly with the bricks. I think.
[quote]Btw: Looove the background - reminds me of my graphics - WHY can’t programmers do graphics - it is mindbogglingly weird …
[/quote]
your guess is as good as mine… :
For those who are still following this game, I’ve uploaded an update. Better splash screen, vertical mouse indicators on the left and right sides of the screen, less cheesy background image, slightly dfferent sprites for the powerups, a few bug fixes.
Just a few more levels to add and I’ll stick a fork in it.