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.
|
|
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? |
|||||||||||
|
|
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.
|
|||
|
|
|
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.
|
|||
|
|