This extreme weirdness deserves a post of its own over a simple edit.
I am encountering what appear to be logical impossibilities- in my experience, computers don't take too kindly to logical impossibilities.
While everything works happy dandy in debug mode, the freezes that occur under "start without debugging" apparently occur somewhere in the decision that chooses whether or not to go with a deep contact resolution or a shallow contact generation path. Instead of choosing either of these options, it does nothing and freezes.
Essentially,
Code: Select all
if it is colliding
{
if it is shallow
{
Add contact and go on your merry way.
}
else
{
It is deeply colliding, deseparate.
}
}
else
{
It's not colliding.
}
becomes...
Code: Select all
if it is colliding
{
Succeed at some calculations to determine shallow/deep penetration state.
Analyze the calculation results: WAAAAARGH I DON'T WANT TO TAKE EITHER PATH
}
The only evaluation done at what appears to be the time of the freeze is a very simple Vector3 equality check. Nothing special. Note that no freeze occurs at the time of the calculations- it makes it through it unscathed. Only when the values are checked does it explode. Since it's not throwing any exceptions, it doesn't appear to be a NaN or null issue.
So, it seems the point of the freeze has been found, or at least narrowed down- but has it really??
During my attempts at debugging the non-debug mode execution, I noticed something peculiar and disturbing.
A piece of debug code references a static boolean value named CHECK which starts as false. testCount() is a simple helper method that, currently, just throws a generic exception to crash the program before the freeze (it technically throws an exception if the method has been called over a given threshold; in the following, that threshold is zero). CHECK and testCount() are not referenced in any other locations.
Code: Select all
if (updateIterations > 1)
{
CHECK = true;
if (CHECK)
Toolbox.testCount();
}
This doesn't seem too useful, but it gets nice and strange pretty quick. Notably, the exception is never thrown, and the program freezes in what seems like an infinite loop. This lack of an exception would be fine if updateIterations < 2 at all times, but it is not. In fact, if I change the code to:
Code: Select all
if (updateIterations > 1)
{
CHECK = true;
}
if (CHECK)
Toolbox.testCount();
the exception gets thrown. This proves that the updateIterations has to be greater than 1 at some point, but it begs the question- why didn't the previous code throw an exception?
Not only that, but earlier, the same setup- all other code equal- produced two different, separate results. I can't explain how or why this is this case, other than some sort of memory corruption.
This throws the entire debug process I used to determine the freeze's location into question. I have no idea what is going on.
I'm currently waiting for my post to be approved on the XNA boards (taking quite a while), but until then I'm just going to keep trying to add features/randomly stumble upon a fix to the horrible catastrophic error.