Box2D Forums

Well, I tested with the images showing and also without, to see the performance hit... And basically, the line drawing takes nearly no time compared to the actual Box2D code (as I'm not doing any fancy drawing...)

thx for your support.

Setting up the project from scratch using recent svn 134, it works using the MSVC 2005 Compiler. On a 400MHz Qualcomm with coprocessor(fpu) PDA, using warmstart ON, positioncorrection ON, 60Hz, 10 Iterations gives about 30-40 % faster executing code using the fixed point compared to the floating point library.
Examples
Broadphase fixed 11 vs float 6 fps,
Domino 20 vs 13 fps,
Pyramide (2 rows down) 8 vs 5 fps

I have the impression, that the influence of positioncorrection in the floating point library is remarkable higher on speed than in the fixed point library. Turned off pos.corr., in fixed point lib the pyramide starts with 11 and goes down to 5 fps, in the floating library starts with 8 and goes down to 1 fps (top row is "down") .

... roughly compared

one issue i forgot
The middle left polygons in testbed/compound shapes are going far away (only on pda), i have no idea why...
It is the polygon sd2 around line ~100

Looking at the position correction loop in b2Island it seems that it exits when the contact solver and all of the joints are "OK". So if the fixed point takes longer to become OK or never becomes OK (then it would always run through all the iterations) this would explain what you are seeing.

Nimodo: could you set the iteration count to 3 with position correction on and see what performance gains you get? I am just curious.

Edit: Rereading your last post I notice that the CPU you are using HAS an FPU. Given that, the performance gains should be only marginal. I'm still curious, however, the effects of early exit from the position correction loop.

I see no big difference in using 3 iterations instead of 10 in above examples,its more or less the same fps and the same differences as aboive between fixed point and floating point lib

I did some testing looking at the number of iterations required for position correction in various tests in the testbed, fixed vs. floating point, and didn't find a significant difference. The only test that shows any real difference is the pyramid test, but in that case the difference is the number of steps required to get to all blue. Each step requires the same number of cycles and is down around 1 after a few seconds. I looked around for some other metric to figure if the floating point code is in some way more efficient than the fixed point code and I could not find any such metric.

The fact that setting the iteration count to 3 doesn't change the performance ratio further indicates that any differences between floating and fixed point are more in the time required to execute the code and not the amount of code being execute.

That said, I do see various places where iteration counts are set to 20 or some other fixed value and I will test some of these and see if they show differences between fixed and floating point. I also see some differences in what code gets executed when TOI is enabled which I might track down.

Do you know the difference in execution time of a floating point mulitply (with the co-processor) and the fixed point processor on the Qualcomm chip?

I did some profiling of the numerical operations (i.e. floating point/Fixed) to see if the fixed point code executes more operations than the floating point code and found quite the opposite. Here are a couple of graphs showing the number of operations per step when executing the pyramid in the testbed. The Fixed point case keeps going and the floating point one drops (all blue around timestep 305), but up until the point where the floating point turns all blue fewer multiply operations are executed.



There are differences in the computational outputs of the fixed point code that requires more step before the pyramid goes to blue, but the complexity of each step is no greater.

Update 8/25: I guess it's just me coming up to speed, but it wasn't obvious (to me) that the Fixed class only has 16 bits of resolution to the left of the decimal point. When it does the math of 480 * 480, that's an overflow. Anyway, I changed to floating point on the Wii and it works for me.

Original message:
Hi,

I'm using Box2d on the Wii with BearFace's compiled library (http://wiibrew.org/wiki/List_of_development_tools). He compiled it with TARGET_FLOAT32_IS_FIXED.

With this setup, there is a bug in the fixed point class on the Wii. When I create a static box of 20 by 480, I get an assert in b2PolygonShape.cpp at this line:
b2Assert(edge.LengthSquared() > B2_FLT_EPSILON * B2_FLT_EPSILON);

When it calculates the LengthSquared of the (0 by 480) edge, the answer comes out negative. When I recompile box2d to use floating (instead of fixed) the assert goes away.

Any thoughts? Is this a Wii specific behavior?

--PaceMaker