Codetopia

I am trying to fix bugs, (you leave in your code and even intentionally :D )
I made an extra check when the ball center is below the brick to make sure I does not register side hits when they are more logical to be frontal. But it does not seem to fix the bug. I also increased the side deflection to minimum of 40.(Which in logical thinking should fix the problem by its self)

    float brickBottom = brickSprite.Location.Y + brickSprite.TextureData.Height;
                    // what from which direction did ball hit?
                    if (ballCenter.X < brickLeft && ballCenter.Y < brickBottom)
                    {
                        // struck brick from left
                        dx = -Math.Max(Math.Abs(dx), 40);
                    }
                    else if (ballCenter.X > brickRight && ballCenter.Y < brickBottom)
                    {
                        // struck brick from right
                        dx = Math.Max(Math.Abs(dx), 40);
                    }
                    else
                    {
                        dy = -dy;
                    }

Can you highlight exactly what is the problem with your code? Why does it not deflect properly?
If it is not hit from the left or the right it should just deflect back and change Y speed. But when this problem occurs  the ball does  not change y speed, therefore it must use the logic for side hits. But in my side logic the ball should bounce in the other direction with 40 speed which is quite a lot, meaning it should not continue in its near to 10 Y speed. But this does not happen either.

Do not post code, just give hints. I do not want solution just help.

Thank you.

Hahhaa :) What a stupid mistake on my part.

float brickBottom = brickSprite.Location.Y + brickSprite.TextureData.Height;

becomes:

float brickBottom = brickSprite.Location.Y + brickSprite.TextureRect.Height;

Anyway, it seems that is better but still not sure if it is working properly. Sometimes it seems that I am getting more kills than I should. Anyway, I give up for now. :)

Bump

Ugh. Sorry for the delay. The forum didn't alert me to the new post.

I know what you're saying about the killing more bricks than you should. And it is related to the deflection code, as you state. If my memory serves me correctly, when the ball is moving almost straight up, it may pass by (and collide with) several bricks.

Since the horizontal movement is so small, the deflection logic is either:
1. not moving the ball enough to the side to avoid more collisions, or
2. it's reversing the horizontal direction with every update (tiny left, tiny right, tiny left, ...) which keeps the ball from deflecting properly.

Like you've seen, it's hard to reproduce consistently. My guesses as to the root cause are based on the somewhat rare and short-lived observations that I've made when the problem occurs. Both of those guesses are easily testable with a modification to the game init and input logic.

In the modified version, we wouldn't let the ball just bounce around the screen. Use the controller to tweak initialization variables for the ball and launch it from the bottom of the screen. Repeat to find a good test case, then use those variables for a hard-coded run which you can debug.

-- joe

---

There are 10 kinds of people in this world -- Those that can count in binary, and those that can't.

Thank you for the reply. I am lazy now but maybe at some point I might get back to the problem. It seems that reproducing game events sometimes is pretty hard. Another aspect of game development that differes than application prgoramming. I am surpised how many problems might arise with such simple things on first look. :) I should start hardcoding my games to reproduce the bugs rather than spending hours of playing the game :D

This is a more intermediate / advanced topic, but there's a way to track down these "hard to reproduce" errors if you don't mind taking the time to add the extra code (done properly, it's a fairly large undertaking).

I'm just throwing it out there to spark your own brainstorming on this topic.

Video Analogy

You can record changed in the state of your game objects, user inputs, and other important data in a file at regular intervals (most likely on every call to Update). This file can then be "played back" within your game engine. "Play" the stream back through your game engine (witin the debugger), and break into the source when / where the problem occurs.

Snapshot

Save a snapshot of all the gamestate data for your game to a file (a single Update, rather than a stream of Update calls). Later, you can reload that state into your engine and resume processing with the debugger attached.

----

The first approach is more suitable to the brickbreaker scenario where a snapshot after-the-fact wouldn't really help. But for most logic bugs, once the game is in a "funky" state, it stays that way. For those cases, the second approach would work just fine, and supporting single-frame game state requires less complicated logic than a stream of game state frames.

It may sound crazy at first glance, but there are parallels in debugging tools -- most notably Microsoft's PIX, which allows you to playback and debug captured GPU states.

-- joe

---

There are 10 kinds of people in this world -- Those that can count in binary, and those that can't.