Intro to Box2D in Flash, Visual Explination UPDATED

Getting started with Box2D in Flash is harder then it should be. The demos are great and if you spend some time with them and the Box2D forums you can get up and running pretty quick. It’s a shame there isn’t more tutorials yet. I hope this intro will help get people started a bit quicker. I will post more as I do more with it.

Units in the Box2D examples seem strange at first until you find out the secret. They are use the units from the C++ package which measured things in meters. They are making a meter = 30px in flash. If you just change the m_drawScale of the debug draw to 1 everything will be in pixels

Everything in Box2D is setup with a centered registration point. SetAsBox() through me off at first because I was expecting it to take the full width and height of the box as parameters but it actually takes half the width and height. See diagram below.

That’s it for now. Next up will be setting center of gravity, friction, restitution, etc.

14 Responses to “Intro to Box2D in Flash, Visual Explination UPDATED”

  1. victor Says:

    i like your Intro. If i could get a little more of this,it would make more sense.

  2. Brettf Says:

    Thanks. What do you want to know about? I am hoping to do joints next.

  3. Tyler Egeto Says:

    Nice, that half the width and height through me of at first too. The use of meters is strange though, that must be new to 2.0, at least on the Flash port.

  4. Brettf Says:

    Probably. The other bit that keeps making me screw up is the centered registration point for everything. Forcing me to think in new ways.

  5. ragaskar Says:

    From what I’ve seen, Position and SetAsBox all take units in pixels.

    The testbed and helloWorld Sprites are all scaled 30x, for some reason — is this what you’re thinking of?

    I can’t find confirmation about this (the AS3 Box2D port has pretty limited documentation, as you know), but searching around, I think here’s what might be the situation:

    *Box2D used meters until version 1.4.3, then switched to pixels (might it have switched back? not sure!)
    * Instead of rewriting the demo and testbed, the code was modified so it still worked (ie, everything was multiplied by 30). I think this is likely because you can see other places in the demo where old code has simply been commented out as the engine has been updated (for example, it’s clear that the debugDraw stuff used to be done ‘by hand’, until the engine was able to internalize it — that code is still in the testbed, just commented out). This would actually explain something that has been confusing me for awhile — why the demos scale everything by 30!

    If someone knows, please correct me if I’m wrong on this. Thanks!

    BTW, great info in these blog posts about Box2D! Thanks for taking the time to make them.

  6. Brettf Says:

    Looking through the b2Vec2 class of the Box2DFlash2.0 release nothing is getting set into pixels as far as i can tell. Which version are you using? In my example if you change some of the values you will see objects move by 30px.

    In the helloWorld and Test bed when setting the width and height of userData property its in pixels but everything else is in meters. This is because userData provides access to the actual Sprite or MC in the userData.

  7. ragaskar Says:

    I’m using the latest version.

    In the helloWorld update loop you have this happening:

    bb.m_userData.x = bb.GetPosition().x * 30;
    bb.m_userData.y = bb.GetPosition().y * 30;

    which suggests to me that the coords are getting multiplied by a factor of 30. When I did my own loop, I removed the *30 and otherwise kept the stanza the same, and got pixel based units.

  8. ragaskar Says:

    Shoot, i hit post before I was ready.

    In the TestBed, you have the following line:

    dbgDraw.m_drawScale = 30.0

    which again suggests that everything is getting scaled.

    You’ll see that the HelloWorld userData sprite width and height gets multiplied by 30 on lines 71 and 72 of

    Now, I’m willing to submit that this is because it makes it simpler to work with meter measurements that exist elsewhere in the engine, but my code hasn’t shown this to be true.

    I also just grep-ed the engine source files and found only two mentions of the number 30 — both in comments, neither in any statements, which again suggests that the Box2D flash version defaults to pixels, or at the least does not have any 30xPixel measurement. Still I’ll admit haven’t done enough digging to see that this is truly the case. I’d love to see a definitive answer on this, though, if there are measurements in Box2D that are taking unusual units, it’d probably save me a lot of frustration if I knew about them.

  9. ragaskar Says:

    Er, sorry, I have trouble being succinct:

    I think if you’re using code from the TestBed or HelloWorld as a base for your examples you are going to see 30-pixel units. I think this is a legacy situation and not something that is built into the engine. I have not seen this for the code I’ve written where all the 30x multipliers have been removed, although it just may be that I haven’t hit that instance yet. I have been very confused by the references to “meters” in the code comments (and the random multipliers in the HelloWorld example), but nothing I’ve seen seems to suggest that they are in anything but pixels.

  10. Brettf Says:

    Well Rajan I thank you for your input as you seem to be correct. This is good news as the whole meters thing was starting to bug me.

  11. Robin Debreuil Says:

    The engine is optimized for distances of .1 and 10 meters (the sweet spot to avoid floating point rounding issues). There are a few places where they strongly recommend not going to pixels, but I’m sure for just getting started/having fun it isn’t a problem : ). I assume this is the same in the flash version.

    (from the manual:)

    “Box2D works with floating point numbers, so some tolerances have to be used to make Box2D perform well. These tolerance have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well.”

    “Being a 2D physics engine it is tempting to use pixels as your units. Unfortunately this will lead to a poor simulation and possibly weird behavior. An object of length 200 pixels would be seen by Box2D as the size of a 45 story building. Imagine trying to simulate the movement of a high-rise building with an engine that is tuned to simulate ragdolls and barrels. It isn’t pretty.”

  12. Brettf Says:

    Yeah i read that a while ago as well. Pixel units haven’t been much of an issue yet. I am thinking I need to dome some form of conversion system because setting things up in meters was messing with my head.

  13. irongleet Says:

    That was an intro? :> I’d like to see more of a traditional one. I’m sure that info is useful to one who already knows how to at least get something simple up and running with box2d but it was useless to me, a box2d noob looking for an intro to box 2d.

  14. Box2DFlash?????–?????? | Code for fun — I share therefore I am Says:

    […] ????????????????Box2DFlash??????Box2D C++??????flash??????1m = 30 Pixel?????b2DebugDraw???????????m_drawScale??????????????????????????????????????????????textbed????????????????????????????( […]