Game Development Community

Container::castRay(...) inconsistent across platforms...

by Stephane Conde · in Torque Game Engine · 10/22/2006 (8:57 pm) · 6 replies

I had noticed an issue with the ShapeReplicator resource whereby shapes were being placed differently on my Mac build than on my PC build. Upon further investigation, it seems like Container::castRay(...) is the culprit. Container::castRay(...) is returning 'true' much more often on the Mac than on the PC.

I have yet to figure out which one is 'correct', but wanted to first throw this out there in case anyone has any ideas as to why something like this might be happening... Just to re-iterate, Container:castRay(...) is returning different results on my Mac than on my PC for the exact same build and therefore the exact same coordinates.

Any help you could offer would be greatly appreciated!

Thanks,

Stephane
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner J "hplus" W
#1
10/22/2006 (9:51 pm)
It could be a floating point precision issue, or a floating point rounding issue, or a floating point exception/NaN issue. Getting the FP environment to be the same across various PC machines is hard enough; trying to do it with another ISA would be even harder.

Torque 3D Owner Stephane Conde
#2
10/23/2006 (1:36 am)
Hey, thanks JW for the input.

That was my first guess, but things just kept not adding up.

Now, this is still early on, but I believe I have actually found a bug in Microsoft Visual Studio compiler (big surprise!)

The problem wasn't actually occuring on the Mac as I had first believed and wasn't even occuring in the Container::castRay(...) function.

The problem was the following code:
else
{
   // No, so choose a new Rotation (in Radians).
   ShapeRotation.set(mDegToRad(RandomGen.randF(mFieldData.mShapeRotateMin.x, mFieldData.mShapeRotateMax.x)), mDegToRad(RandomGen.randF(mFieldData.mShapeRotateMin.y, mFieldData.mShapeRotateMax.y)), mDegToRad(RandomGen.randF(mFieldData.mShapeRotateMin.z, mFieldData.mShapeRotateMax.z)));
}

For some reason, the mDegToRad function call was returning numbers that were slightly off (about 0.1 off to be exact) on the PC. On the Mac, the numbers were spot on.

Changing the above code to the code below will fix the PC version and leave the Mac version unchanged:
else
{
   F32 rand1, rand2, rand3;
   rand1 = RandomGen.randF(mFieldData.mShapeRotateMin.x, mFieldData.mShapeRotateMax.x);
   rand2 = RandomGen.randF(mFieldData.mShapeRotateMin.y, mFieldData.mShapeRotateMax.y);
   rand3 = RandomGen.randF(mFieldData.mShapeRotateMin.z, mFieldData.mShapeRotateMax.z);
   // No, so choose a new Rotation (in Radians).
   ShapeRotation.set(mDegToRad(rand1), mDegToRad(rand2), mDegToRad(rand3));
}

Now... the big question is why on earth would the first code block cause the PC version to mis-calculate? I am using Visual Studio .NET 2003... is this a known issue with the compiler? Would compiler options cause this problem? Does it have to do with mDegToRad being an inline function?

Anyway, I'll make a post to the ShapeReplicator resource page as well...

Stephane

Torque Owner Stefan Lundmark
#3
10/23/2006 (1:39 am)
Stephane on a bugreporting spree :p I am curious about this as well.

Torque 3D Owner Stephane Conde
#4
10/23/2006 (2:23 am)
Ha! Yeah... I guess so.

Our team is very close to releasing our game... so lingering Mac bugs are really all that stand in our way. Unfortunately, this one was on the PC and will mess with all of our ShapeReplicators so we are going to need to re-submit the game to review sites/competition sites. Alas, the dumb rookie mistakes are going to be the end of us. Lesson learned: never release your game on one platform before all of your platforms have been tested thoroughly...

I will e-mail Garagegames about this one and see if they might know more about it than me... My limited knowledge of C++ stops well before compiler specific issues.

Cheers,

Stephane

P.S. I have confirmed this fix on two separate PCs... not a good sign...

Torque Owner Duncan Gray
#5
10/30/2006 (4:05 pm)
Just saw this interesting post. I used to do some microprossesor coding many years ago. It could be hardware related. The 1st version does not have any memory variables assigned for storing results forcing the cpu to use it's internal registers as storage.

Your fix supplies a 32 bit memory storage for each result, prior to the mDegToRad call which will reduce the burden on the cpu registers.

Perhaps test on AMD and Intel to compare.

Torque 3D Owner Stephane Conde
#6
11/01/2006 (11:41 pm)
Hmm... interesting theory Duncan. I wonder then if the issue would crop up with the original code on Intel Macs?

We had tested our game on dozens of PC machines of all shapes and sizes and the problem only presented itself when we started testing on Macs (which is why I initially thought the problem was Mac related). So we had tested on both Intel and AMD chipsets ranging from PIIIs and PIVs to AMD XP, Athlon and Opterons... all exhibiting the same symptoms.

It's kind of strange... Macs seem a whole lot less tolerant to a lot of issues. Many issues which had always existed in our game only presented themselves when we finally tested it on a Mac. Now don't get me wrong, I think this is a good thing... I just wish PCs were more picky about bad code... I guess the lesson learned is to be continually testing your game on all platforms.

Anyway, all (known) issues have been solved now...

Thanks again!

Stephane