Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Box2D Scaling factor — Gideros Forum
  • Home
    • ›

    Box2D Scaling factor

    twisttaptwisttap Member
    edited July 2012 in General questions
    While I was looking some stuff at Box2D offical web site, I come accross this:
    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.
    Is this possible in gideros or is there a predefined factor for this ?
    +1 -1Share on Facebook

    Comments

    • TeranthTeranth Member
      You can control the box2d scaling as needed with the built-in function provided by Gideros.

      In Gideros Studio, go to Help and Choose -> API Documentation, go to b2.setScale()

      In your example you could use:
      b2.setScale(0.01)
      That will allow you to set the pixels to meters ratio, and of course the documentation is nice to have on hand for many other functions.

      Hope that helps :)
      ThumbHurt Games / FB: ThumbHurt Games / FB: Eli/Teranth | Skype: teranth37
      +1 -1Share on Facebook
    • twisttaptwisttap Member
      Ah didnt see that sorry, I am a little bit exhausted, slept about only 8 hours for the past 3 days, a social gaming company is interested in one of the games we were developed at a game jam so we are working at full schedule to finish that up because I never ask a question before looking at the API docs.....

      Likes: gorkem

      +1 -1 (+1 / -0 )Share on Facebook
    • gorkemgorkem Maintainer
      Good luck! :)
      +1 -1Share on Facebook
    • atilimatilim Maintainer
      use b2.setScale(30) or b2.setScale(60) or b2.setScale(100) in your case, not b2.setScale(0.01) :)
      http://en.wikipedia.org/wiki/Cytorus
      +1 -1Share on Facebook
    • TeranthTeranth Member
      @atilim oh I got that one wrong heh :) Thanks for the correction, while I may have found the API documentation I didn't read it very well lol

      @twisttap best of luck man, sounds cool keep up the good work :)
      ThumbHurt Games / FB: ThumbHurt Games / FB: Eli/Teranth | Skype: teranth37
      +1 -1Share on Facebook
    • twisttaptwisttap Member
      edited July 2012
      Actually the thing I was asking is same as you @teranth not 30,60,100 fps thing :)
       
Box2D uses MKS (meters, kilograms, and seconds) units and radians for angles. You may have trouble working with meters because your game is expressed in terms of pixels. To deal with this in the testbed I have the whole game work in meters and just use an OpenGL viewport transformation to scale the world into screen space.
 
float lowerX = -25.0f, upperX = 25.0f, lowerY = -5.0f, upperY = 25.0f;
gluOrtho2D(lowerX, upperX, lowerY, upperY);
 
If your game must work in pixel units then you should convert your length units from pixels to meters when passing values from Box2D. Likewise you should convert the values received from Box2D from meters to pixels. This will improve the stability of the physics simulation.
 
You have to come up with a reasonable conversion factor. I suggest making this choice based on the size of your characters. Suppose you have determined to use 50 pixels per meter (because your character is 75 pixels tall). Then you can convert from pixels to meters using these formulas:
 
xMeters = 0.02f * xPixels;
yMeters = 0.02f * yPixels;
 
In reverse:
 
xPixels = 50.0f * xMeters;
yPixels = 50.0f * yMeters;
 
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.
 
If you use a conversion factor, you should try tweaking it globally to make sure nothing breaks. You can also try adjusting it to improve stability.
      +1 -1Share on Facebook
    • ar2rsawseenar2rsawseen Maintainer
      edited July 2012
      It's exactly as @atilim stated. Not an FPS thingy, not resizing of Box2d object.

      Here's more information:
      http://www.giderosmobile.com/forum/discussion/comment/3231#Comment_3231

      TLDR;

      There is a funciton b2.setScale(scale) using which you can scale all pixel units, by default it's value is 30, so all your objects are already scaled. As I understood, then it's done internally and nothing additional is required from you, then simply provide scale.

      It changes the ratio between 1m and 1 pixel in box2d simulation. It will change nothing from visual point of view. Only how simulations behave and maybe even get some performance, if internal calculations would be performed in interval between 10 and 0.1.

      For example if your largest object is 300px and your smallest object is 3px, then by setting scale to 30, box2d would handle them as they were 10 units and 0.1. It won't change the actual size. But simulations may behave differently. Try setting scale 0 and look and dynamic object moving and collisions. They should be pretty jigged.
      http://appcodingeasy.com/Gideros-Mobile
      +1 -1Share on Facebook
    Sign In or Register to comment.