[fixed]Problem with 'testUtils.cpp' under CodeBlocks

[AReichl]

It's the first time i compiled the tests (both VS2010 and CodeBlocks/MinGW).
Some Results:
VS2010 (Debug,Release): 63 tests of 69 passed.
CB+MinGW-4.8.1 (Release): 61 tests of 69 passed.
CB+MinGW-4.8.1 (Debug):
.....
vector3d<f64> tests passed
ERROR: vector3d 316.0000000000000000, 90.0000000000000000, 0.0000000000000000 == vector3d 315.0000000000000000, 90.0000000000000000, 0.0000000000000000
ASSERT in D:\Develop\Lib\Irrlicht\trunk\tests\testVector3d.cpp:102: compare(with)

I will try to find out more about this "problem".

[AReichl]

found it:

It appears with 'vector3d<s32>'. I didn't find any usage of it in the Irrlicht engine, so this problem can be ignored. It's only the test that fails.

In 'vector3d.h' change

angle.X = (T)( atan2( (f64)z1, (f64)Y ) * RADTODEG64 - 90.0 );

to

tmp = ( atan2( (f64)z1, (f64)Y ) * RADTODEG64 - 90.0 );
angle.X = (T)tmp;

as it is done for 'angle.Y' some lines up (remove the "const" for tmp there!).

This probably is some kind of "compiler-voodoo".

[CuteAlien]

Thanks - although I also can't explain why there is a difference right now. I've checked it into svn trunk.

[AReichl]

I found some more (similar?) effects, e.g. in 'matrixOps.cpp' with 'getRotationDegrees(const vector3d<T>& scale_) const' (from 'matrix4.h'). Also some ASSERTS, but only logging, not stopping the program. I will have a look.

I am a little "frightened" by this. On one side it's nice that it is done with templates, on the other side it's not that easy to cover all types and circumstances with templates (e.g. different rounding errors for different types and so on). As long as everything works with FLOAT and DOUBLE it's not a problem (as i mentioned, i didn't find any usage with INTs).

Question: If Irrlicht uses templates, would it be possible to "switch" to double internally (as in Ogre)? If not, then why use templates in the first place? Other engines don't even have templates, they just have functions for FLOAT. This is NOT a rant, ONLY a question!

[AReichl]

still wrong!

NOT

tmp = (T)(atan2((f64)z1, (f64)Y) * RADTODEG64 - 90.0);

but

tmp = (atan2((f64)z1, (f64)Y) * RADTODEG64 - 90.0);

WITHOUT cast here!

The cast comes in the next step.

[CuteAlien]

Ok, checked in next version - hope this time it works. Sorry that I won't test - just don't have the time for that right now.

Also I don't know what OGRE does. Irrlicht was just coded that way by whoever wrote those classes (mostly Niko I guess). I have no problem adding patches if they improve the engine and don't force me to think long if they improve stuff or not. But anything that takes time - like re-thinking the architecture of the core classes - hasn't enough priority for me to get involved.

[AReichl]

Ooooook - didn't mean it as it sounded. Templates are ok, even if the engine internally only uses FLOAT. The advantage is, that the user can use other types in his program to solve special problems in place.

I will have a look at the other tests that failed and report it here in this thread (seems to be a good place for that and we don't have to open another one).

By the way - Ogre has a define, that can be set to FLOAT or DOUBLE and then the whole engine can be recompiled with this new type (didn't work for me and there are no precompiled binaries around and DOUBLE is a bad idea anyway [there are no DOUBLES on console, so it won't be portable], hehe). I ONLY asked out of curiosity.

[CuteAlien]

No problem, it's just an area where I don't know more about it than you. I also just use the core classes - they have been written for the most part long before I joined the engine.

[AReichl]

> I found some more (similar?) effects, e.g. in 'matrixOps.cpp' with 'getRotationDegrees(const vector3d<T>& scale_) const' (from
> 'matrix4.h'). Also some ASSERTS, but only logging, not stopping the program. I will have a look.

That's a tricky one. The Z-value, which is calculated inside the function, is a little different in debug and release mode. And it's different, because the input values for the atan2 are also a little different and so on. No trick here to compensate, until i would go "down" further.

But i found something else - there is a compiler switch to compensate exactly these problems: -ffloat-store
http://stackoverflow.com/questions/7517 ... mpiler-bug

I tried it and now with gcc/MinGW we also have "63 tests of 69 passed" as with VS2010 (before it was 61 of 69).

I don't know which compiler did it "right" before, but with -ffloat-store the results are at least comparable.

I also don't know if we should add this switch to the engine (seems to work as it is). It's probably only important for testing.