I am seeing some very strange behavior that I was hoping someone could shed some light on.

I am working on a project, and right now I have a circle that the user has a degree of control over that moves around the screen, with gravity effects etc. There are a series of lines that the circle will collide with a bounce off. I am using a Swept-circle implementation for the circle-line collision detection, for those who know what that is, and everything seems to work perfectly when I debug via android.

However, when a debugger is NOT attached (I disconnect the USB cable, or just run the app directly through the device) the circle immediately starts sticking to the lines. I have tried this on both an Iconia Tab and an Incredible smart phone with the exact same behavior. Also the frame rate is pegged at the screen refresh on both devices so I can't see how a time interval change could cause any issue.

Is there any difference in the way the apps run while a debugger is attached that I could start investigating?

Naturally, I can't debug WHY the circle is sticking to the lines without the debugger attached, and when the debugger is attached the problem is not there.

VERY frustrating. Any insight would be greatly appreciated.

Well, I managed to find a solution to the problem, though I am still curious about the cause. I changed all of the floats to doubles in the collision code and everything is working as expected. It seemed the lack of precision of the floats was causing improper calculations and embedding the circle in the lines.

So are floats handled differently when a debugger is attached (maybe AS doubles)? Curious to know so I can look for this type of behavior in the future.

Hi kanageddaamen,

I can't really say what the debugger has to do with it but I have had some mysterious things like that happen when I left one of the equals signs out of an equality test. For some reason, something like (a = b) would not cause any trouble until I changed some other part of the program and then it would suddenly quit. I'm thinking that the precision of your calculations changed by replacing the floats with doubles, and your comparisons did too. Would they stick to the line because they could not get close enough to it or went past and could not come back?

Just thinking out loud. It would be interesting to know why the debugger would have any bearing on the program operation.

Phyll

The problem was as follows:

As part of the collision detection algorithm, it calculates the time the moving sphere would collide with the line, then move the sphere a very short distance from the collision point and recurses. The lack of the precision of the floats caused the time value to sometimes be too high, hence placing the circle embedded in the line. On the next iteration, the circle was colliding with line at time 0 and the recursion depth check I have to prevent a stack overflow just stopped the circle from moving.

Oddly, this only happened when no debugger was attached. With the debugger attached, it never "overcalculated" the time step for the collision, which makes me curious if somehow the debugger uses higher precision types for floats. That is the only answer that I can think of.

Hi kanageddaamen,

I agree, that it really doesn't seem to make any sense. Seems like a question for the framework guys over at Google.

I think you should get the "stumper of the day" award for this one. Keeps things interesting.

Thanks,

Phyll