Page 1 of 1

Redefineable cpFloat

PostPosted: Wed Oct 08, 2008 3:22 pm
by Michael Buckley
Chipmunk currently uses doubles as its default type for cpFloat, which I think is great, but those developing for the iPhone would probably prefer to use floats since the iPhone handles those much faster. The old documentation, from back when cpFloat was float, states that it should be safe to redefine cpFloat. is this still true?

If so, I believe that it would make things easier for developers working on projects that target both desktop and iPhone platforms to have cpFloat's typedef defined using a macro. Right now, for the experimental iPhone port that I have, we're keeping two copies of chipmunk.h. One with double and one with float. I have attached a diff to the current trunk (revision 72) which demonstrates how chipmunk.h could be modified to allow developers to change the type of cpFloat using a -D flag. This would allow us to keep one copy of the code for all platforms.

Re: Redefineable cpFloat

PostPosted: Wed Oct 08, 2008 3:59 pm
by slembcke
I guess that's not a bad idea.

It would also let you select which math functions (sqrt(), sin(), exp(), etc.) to use as I'm using the double precision ones everywhere in the code.

Re: Redefineable cpFloat

PostPosted: Sat Oct 11, 2008 4:33 pm
by Michael Buckley
I've attached a patch that changes the function based on the type. I'm not sure if this is the way you want to do it, but it's certainly a way to do it.

Basically, the patch defines a new function name for each of the function groups in math.h. sin becomes cpSin, fmod becomes cpFmod, etc. I originally wanted to make it so that the code wouldn't have to be touched and that the double version of each function would be replaced in the code as needed. Unfortunately, this lead to some problems when compiling math.h. If CP_FLOAT_TYPE was set to float, then sin would become sinf. However, math.h already defines sinf, causing a compiler error.

Users also can't simply pass -DCP_FLOAT_TYPE=float any more. They have to pass in CP_FLOAT_TYPE=CP_FLOAT, CP_DOUBLE or CP_LONG_DOUBLE. If they don't define it or pass in something that evaluates to 0 they get CP_DOUBLE. If they pass in something that evaluates to < 0 or > 3, they get an error.

The patch also fixes an include of cpBreakableConstraint in cpConstraint.h. However, if you want to fix that separately for modularity's sake, I can re-patch once that is fixed.