2

Question is simple so, no codes! If someone knows Box2D and SDL2, then, please tell me how to wrap SDL_Rect with b2body. Ofcourse, it requires to know the conversion of metre to pixel and vice versa. This is because Box2D measures distance in metres. Can you give me a simple expression or function to convert metres(of Box2D) to pixels or pixels to metres(of Box2D)?

legends2k
  • 31,634
  • 25
  • 118
  • 222
user3820248
  • 84
  • 2
  • 10
  • 4
    I'm pretty sure it's up to you to invent a conversion factor based on your needs. There is no predefined concept of pixels-to-meters, it's up to your game world to determine this. – user229044 Jan 19 '15 at 15:34
  • Yeah, whatever conversion you want will work. I think box2D recommended something like a 20px per meter conversion, but literally anything is valid. It's just that some will make sense, and others won't. – BWG Jan 19 '15 at 15:35
  • Is there any 'Default' value of how many pixels is a meter. If there isn't, then how can a meter be defined without such aspect? – user3820248 Jan 20 '15 at 11:18
  • 1
    Pixels are only relevant when you are drawing things on the screen. Box2D does not care about them at all. Define your physics objects so that the most common body is around 1 unit in size. Then scale everything as necessary to draw it. – iforce2d Jan 20 '15 at 12:20
  • Thanks @iforce2d! I got your words as well as your tutorials! – user3820248 Jan 21 '15 at 13:40

2 Answers2

10

Can you give me a simple expression or function to convert metres(of Box2D) to pixels or pixels to metres(of Box2D)?

Unfortunately, this isn't as simple as it sounds, for us. Because, if your game is on worms, then your game world would be in millimetres while if it's like Space Invaders then it would be in kilometres? So it's up to the game designer to decide this scaling factor. Without knowing about the intricacies of the game, deducing this factor would just be a wild guess at best.

From Box2D's faq:

How do I convert pixels to meters?

Suppose you have a sprite for a character that is 100x100 pixels. You decide to use a scaling factor that is 0.01. This will make the character physics box 1m x 1m. So go make a physics box that is 1x1. Now suppose the character starts out at pixel coordinate (345,679). So position the physics box at (3.45,6.79). Now simulate the physics world. Suppose the character physics box moves to (2.31,4.98), so move your character sprite to pixel coordinates (231,498). Now the only tricky part is choosing a scaling factor. This really depends on your game. You should try to get your moving objects in the range 0.1 - 10 meters, with 1 meter being the sweet spot.

Here the scaling factor is what you set; your decision on how many pixels would constitute one unit of your game world.

It is usually recommended that you do all the calculations in the game world units and finally, as a last step (render), do the conversion to pixels; likewise before bringing in data from outside (say an image/sprite, which is in pixels) to the world space, do the reverse conversion only once and then deal in world units in the rest of the code. See this article by Erin Catto, Box2D's author, on this issue. An excerpt:

You should consider using MKS units in your game code and just convert to pixels when you render. This will simplify your game logic and reduce the chance for errors since the rendering conversion can be isolated to a small amount of code.

This paragraph appears in the manual too.

Community
  • 1
  • 1
legends2k
  • 31,634
  • 25
  • 118
  • 222
  • On my PC, I found it to be 2 pixels for every 1 meter (Just found it out by hit and trial method). Would it be different for other devices? You also said that at the point of render, one should convert all meters to pixels for the things that are going to be rendered. Is that statement, right? – user3820248 Jan 20 '15 at 11:15
  • 1
    Different devices have different DPI. Thus if you have an image that's 4 pixels in a row, on a 4 DPI device you'll see the image spanning 1" in length, while on a 2 DPI device you'll see it 2" long. Thus it's up to you to do the necessary scaling (or give different images) for a given device based on its DPI. By that statement, what I meant was, when you render an image, either render directly if you've the data in pixel units, else you need to make the conversion if the data is in metres. If you're doing the conversion, then do it only once. This is what the article also recommends. – legends2k Jan 20 '15 at 14:02
0

2 pixels a meter? This is a pretty big game world. Ignore DPI. This is completely confusing the issue IMO. Simplest : You model in real world coordinates (box2d does on meters) and you map, in libgdx terminology, via a viewport at rendering. If you make your game world too small there may be problems with vertices collisions however.

RichieHH
  • 2,116
  • 4
  • 28
  • 30
  • Thanks for answering! Actually, I am quite satisfied with what iforce2d said. Pixels and metres cannot be compared as 1 metre is for 2 pixels. In my structure, its independent of this factor. Scaling only affects the performance of things which can also be 'scaled' by using the aspect ratio. But if scaling is done by considering only one of the dimensions (usually vertical), the only thing that needs to be done, is to scale the whole rendering image that fits for the same vertical dimension. I am not good at explaining things. Also, I don't want to use libgdx! I use SDL2 with Box2D... – user3820248 Feb 25 '15 at 08:13