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.
\$\begingroup\$
\$\endgroup\$
1
-
\$\begingroup\$ 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. \$\endgroup\$– Christopher HorensteinDec 3, 2010 at 6:06
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
5
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?
-
\$\begingroup\$ 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);} \$\endgroup\$– GastónNov 19, 2010 at 22:10
-
\$\begingroup\$ Because for games when you want the highest performance possible, calling a method instead of using a static var is too costly. \$\endgroup\$ Dec 2, 2010 at 16:46
-
\$\begingroup\$ @AttackingHobo: True, but nowhere in the question did he mentioned performance, so I opted for an easy, maintainable solution. \$\endgroup\$– GastónDec 2, 2010 at 17:58
-
\$\begingroup\$ A CONSTANT value for a multiplier would work as well, and for the same effort yield faster code while even being easier to maintain. \$\endgroup\$ Dec 2, 2010 at 20:03
-
\$\begingroup\$ @AttackingHobo: Fair point, that should do as well. \$\endgroup\$– GastónDec 3, 2010 at 2:36
\$\begingroup\$
\$\endgroup\$
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;
}
\$\begingroup\$
\$\endgroup\$
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'
