Forums

Full Version: Macros Are Evil
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
So I've spent some time today try to figure out why cars are still flying off in random directions when hitting curbs sometimes.

It turns out it is a bug in Bullet, to be more specific in the SIMD_DEGS_PER_RAD macro.

Code:
#define SIMD_PI           btScalar(3.1415926535897932384626433832795029)
#define SIMD_2_PI         btScalar(2.0) * SIMD_PI
#define SIMD_HALF_PI      (SIMD_PI * btScalar(0.5))
#define SIMD_RADS_PER_DEG (SIMD_2_PI / btScalar(360.0))
#define SIMD_DEGS_PER_RAD  (btScalar(360.0) / SIMD_2_PI)

The first one to spot it gets a virtual cookie. Big Grin

PS:
What is affected by this bug? Tire forces (cars flying off randomly and stuff) and AI steering calculations.
Hmm.
I'd say they use 2 Pi / 360.0 instead of Pi / 180.f
And yeah, they use 3 times double to float: once in btScalar(2.0) then in btScalar(360.0) and in PI define itself
and that forces to use float division on those 3 floats with already conversion errors.
My guess is that the result is different from just float( 3.1415926535897932384626433832795029 / 180.0) or even /180.f
But yeah, btScalar can be a double if ussing double precision with Bullet, then it probably is okay. But for that one would have to include bullet sources in project, since all distribs have it off probably (just single float).
(08-28-2015, 10:31 AM)CrystalH Wrote: [ -> ]Hmm.
I'd say they use 2 Pi / 360.0 instead of Pi / 180.f
And yeah, they use 3 times double to float: once in btScalar(2.0) then in btScalar(360.0) and in PI define itself
and that forces to use float division on those 3 floats with already conversion errors.
My guess is that the result is different from just float( 3.1415926535897932384626433832795029 / 180.0) or even /180.f
But yeah, btScalar can be a double if ussing double precision with Bullet, then it probably is okay. But for that one would have to include bullet sources in project, since all distribs have it off probably (just single float).

Nope, precision is not the problem.
Ah heh okay I see now.
They didn't put () around the SIMD_2_PI define:
should be:
#define SIMD_2_PI (btScalar(2.0) * SIMD_PI)
without that the
SIMD_DEGS_PER_RAD (btScalar(360.0) / SIMD_2_PI)
becomes 360 / 2 * PI = 180 * PI instead of 360 / (2 * PI) = 180 / PI.

Well yeah but I won't say defines are evil, just need special care.
Same could be said about = and ==. E.g. you can write if (a = b) and loose a lot of time to get what's wrong if you don't know already.
Another one of my favourites is when you e.g.:
Code:
    int i=0;
    #define aa(a)  if (a) {  ++i;  }
    if (1)
      aa(i);
    else
      aa(i);
and then get an else without matching if, since you can't put ; after aa.
They are evil, because even seasoned developers happen to mess it up.