What is the deal with #QNAN0?

#1 That is normally the result of a division of somevalue / infinity or a value that is that large that it ends as something similar, one that in any case has a result that is too small to be represented as float.

#2 OK, I guess that answers my question. Thank you Marc! :)

#3 Here is a tip for tracking floating point errors in Windows:

_matherr.

This is a callback that you can add to your code and the c-runtine lib will call when a floating point error occurs. When i'm running into these errors i typically throw one in an put an assert( false ) in it. You'll then get a breakpoint when some code does a div by zero, overflow, or other floating point no-no.

IMO we should stick one in Torque HEAD for debug builds as it will help to alert us to normally undetected issues in collision and physics.

#4 Good suggestion. Ben? ;)

What is worrying me is that getTransform () returns such an abnormal value.

#5 @Stefan - It has to return that value if the math generates it.

First off ... which setTransform() and what return value? SceneObject::setTransform()? Did you step thru it and look to see that all inputs are valid? Once a NAN gets into the system it usually lingers and propagates down thru all your math... so the realy bug could have occured much earlier.

#6 Ah, okay.

Seems to be an isolated case of having 0, 0, 0 passed to the vector* script methods.

#7 Tom,

That is a great suggestion. I am working on a game with a non-standard, spherical world and, as a result, have run into a couple of these problems.

Pardon my ignorance, but do you have an idea of how we could properly add that function so that it is always available in debug builds? My thought is to make that change on my local version, but I'm not sure where to put it. Would you expose it somewhere in platform and then define it somewhere in platformWin32?

Thanks
Todd

#8 @William - I'd put it into engine\math\mMathFn.cc...

#if defined(TORQUE_OS_WIN32) && defined(TORQUE_DEBUG)
int _matherr( struct _exception* except )
{
   AssertFatal( false, "_matherr!" );
   return 1;
}
#endif

NOTE: There might be some issues with this when dynamically linking with the VC++ CRT. Someone should check this out and test it.

#9 Thanks Tom.

I just added this and it works like a charm. This would have saved me a couple of hours the last time I hit one of these errors.

(I would test the dynamically linking issue with CRT, but I don't know how...sorry.)

Todd

#10 One more thing...

I am compiling the engine with the Multi-threaded Debug DLL (/MDd) setting. I'm not sure, but after doing a quick scan of the C Run Time Libriaries doc, I may have done the test you mentioned without realizing it!

Todd

#11 @William - Are you sure it's detecting the errors? Put a mLog( -2 ) in there to be sure.

#12 William,

Under your Project's properties General tab, there are two fields named Use of ATL and Minimize CRT use in ATL.

#13 @Tom - I'm sure. Your suggestion is almost the exact test that I tried when I integrated your code.

@Stefan - I have those fields set to "Not using ATL" and "No". I think that this is correct because the engine doesn't use the ATL libraries....I thought.

Thanks again guys.
I am really happy to have this type of debugging help in place.

#14 Quick followup....

Putting this in has already ferreted out a bug. Its not a big deal, but given that I have only been running with it for 2 days, it definately makes the case for putting it in head.

www.garagegames.com/mg/forums/result.thread.php?qt=57981#432234


Todd

#15 It's a quick fix to get it working if you're in panic. I use it for our debug builds presently as I had to move on, and it works fine. Your mileage may vary :)

#16 No panic at all. I'm really happy with this modification. These types of bugs are harder to find then they are to correct.

Todd

#17 @William - Good find... keep reporting them as you find them!