# What do I need to change in Box2D to work in pixels?

Box2D seems to be set up in such a way that you cannot work in pixels (i.e. physics scale = 1). It produces very strange results as it hits maximum speed limits at low speeds and looks very strange. It only seems to work well at a physics scale of around 15 or 30. For me, working in pixels is the logical way to handle physics and movement in a game, as you are already using that measurement for lots of other things. I don't want to have postionX/30 all over my code, so what variables do I need to hack in the box2d source in order to make physics scale 1 work as if it was physics scale 30? I'm using the latest version from box2dflash.org.

• In my experience the best thing to do is isolate the conversions to as few places in your code as possible, and learn and stick to the range of values that you find Box2D works best with. Or, of course, utilize a different physics engine. – Christopher Horenstein Dec 3 '10 at 6:06

I would advice against changing it, for a couple of reasons:

1) It might not be a trivial task; it's been a while since I last used Box2D, but I don't think it has changed much regarding that.

2) Using pixels can lead to very (I mean, VERY) large numbers, and to some computation errors.

Instead of having posX/30 all over your code, as you said, ¿why not try something like a static method ToPixelUnits (or whatever), which returns the pixels, so that you can use it when displaying things on the screen?

• Also, you could try to create a Camera class (I was refraining myself from using OOP, but what the heck...), which handles the drawing. In each loop, you could pass a reference to the world to it, and then the camera would take care of the rest. Something like: camera.draw(w) ===> void draw(World w) { for (Entity e: w.entities){ e.draw(e.posX/30, e.posY/30);} – Gastón Nov 19 '10 at 22:10
• Because for games when you want the highest performance possible, calling a method instead of using a static var is too costly. – AttackingHobo Dec 2 '10 at 16:46
• @AttackingHobo: True, but nowhere in the question did he mentioned performance, so I opted for an easy, maintainable solution. – Gastón Dec 2 '10 at 17:58
• A CONSTANT value for a multiplier would work as well, and for the same effort yield faster code while even being easier to maintain. – AttackingHobo Dec 2 '10 at 20:03
• @AttackingHobo: Fair point, that should do as well. – Gastón Dec 3 '10 at 2:36

I have implemented a ratio variable on items/entities/objects. So whenever you need to update the sprite position for an "item" you use the ratio to determine the visual position in pixels. Then you don´t need to convert the units in box2d.

private function updateSpritePosition() : void
{
_sprite.x = _body.GetPosition().x * _ratio;
_sprite.y = _body.GetPosition().y * _ratio;
}


You can try what Gaston suggested or design a very simple class that takes care of the conversion implicitly** when you pass in the position values from Box2D (the class can also have overloaded operators to make the conversion even simpler). All your 'pixels' can then inherit from this class (or use it directly if they are not doing anything special). This will make your code look less cluttered as compared to function calls and also more scalable.

** by implicit I mean you will have to perform the conversion manually and in such a way that when a function such as SetPosition() is called, it performs the conversion which is then transparent to the client who is using the new 'pixel box 2D object'