Box2D: Understanding the conversion to pixels

It is my understanding that Box2D is optimized for an acceleration of 10m/s[sup]2[/sup]. You chose a scaling factor that works for the dimensions of your game. And should be sizably larger than 1 because that will cause objects resting on one another to have a visible jitter.

Personally I've found this conversion to be a pain in the butt as well as the Box2D collision handling API. I chose to use chipmunk instead. Though some argue that Box2D is smoother, I haven't found any real difference because it all depends on the number of sub iteration steps you choose. Of which there is no such animal as a conversion ratio to from meters to pixels. Pixels is the internal unit for Chipmunk.

But there is one valid reason to use Box2D instead of Chipmunk and that is continuous collision detection. If in a time step Box2D detects two objects went through each other if one body is defined as bullet, then Box2D will backtrack to the point prior to the objects passing through each other and redo the collision detection from that point.

The other thing I don't like about Box2D is the way bodies can snag on a path of segment shapes. There is a special type of joint to use to avoid this and I forget its name.

Here is a link I think may help.

I would still need to be thinking with two coordinate systems though wouldn't I? Or would I only need to think in one and by doing the conversion I would have the other coordinate system?

The author from the link you gave me says he programmed the demos using the box2d coordinate system then scaled the viewport to be the normal screen space. Looking up the function he uses for the scaling, it looks like it sets the top left to be the edge of the "world", which I guess would make the world coordinate system correspond to the normal screen space. Eh it's still confusing me....I'm going to take a look at the samples again, maybe there's something I overlooked in there that will help me understand this better.

I believe 1 unit = meter.

Just pick a ratio of meters to pixels, such as 50.

const float MtoP = 50f;

Then for every pixel coordinate you pass in to Box2D you divide by MtoP, while every pixel out you multiply by MtoP.

you divide by MtoP

Better to to multiply by the inverse constant for performance. So lets assume PtoM is 50.0F, then multiply by 0.02F into Box2D and 50.0F out of Box2D.

In case anyone else is having a hard time understanding, this video helped me out.

[media][/media]

Thank you for your help everyone.

I'm glad you are getting things to work out for you now. A bit of a subtlety of what you mention above is the top left is zero zero which means to me that increasing y is down. This could be the great source of your troubles as you will need to multiply Y out box2d by -50.0F and X out by 50.0F. I didn't go through the video but perhaps because they too are using SDL it may have been explained there.