• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
SonicD007

Box2D: Understanding the conversion to pixels

6 posts in this topic

Hey everyone,

I recently got interested in physics games and would like to create a small project using box2d. I have everything set up ready to go but I don't understand the conversion ratio from pixels to meters. How would I do this? Another thing that has been confusing me is which coordinate system I should be thinking in if box2d uses the Cartesian system and SDL uses the top left as 0,0 (don't know what the name for this system is). Normally I would program in terms of pixels. With this being said, if I have a sprite at location 100,100 in SDL terms, how does this translate to Box2D coordinates? Wouldn't I need to be keeping track of two coordinate systems? (If so, this is gonna drive me nuts). Hopefully you guys understand what I'm having trouble understanding. I've been looking for a good article on google all day but nothing has really helped make this click for me.

Language: C++
Drawing API: SDL

Thanks Edited by SonicD007
0

Share this post


Link to post
Share on other sites
It is my understanding that Box2D is optimized for an acceleration of 10m/s[sup]2[/sup]. You chose a scaling factor that works for the dimensions of your game. And should be sizably larger than 1 because that will cause objects resting on one another to have a visible jitter.

Personally I've found this conversion to be a pain in the butt as well as the Box2D collision handling API. I chose to use chipmunk instead. Though some argue that Box2D is smoother, I haven't found any real difference because it all depends on the number of sub iteration steps you choose. Of which there is no such animal as a conversion ratio to from meters to pixels. Pixels is the internal unit for Chipmunk.

But there is one valid reason to use Box2D instead of Chipmunk and that is continuous collision detection. If in a time step Box2D detects two objects went through each other if one body is defined as bullet, then Box2D will backtrack to the point prior to the objects passing through each other and redo the collision detection from that point.

The other thing I don't like about Box2D is the way bodies can snag on a path of segment shapes. There is a special type of joint to use to avoid this and I forget its name.

[url="http://box2d.org/2011/12/pixels/"]Here is a link I think may help[/url]. Edited by Animate2D
2

Share this post


Link to post
Share on other sites
I would still need to be thinking with two coordinate systems though wouldn't I? Or would I only need to think in one and by doing the conversion I would have the other coordinate system?

The author from the link you gave me says he programmed the demos using the box2d coordinate system then scaled the viewport to be the normal screen space. Looking up the function he uses for the scaling, it looks like it sets the top left to be the edge of the "world", which I guess would make the world coordinate system correspond to the normal screen space. Eh it's still confusing me....I'm going to take a look at the samples again, maybe there's something I overlooked in there that will help me understand this better.
0

Share this post


Link to post
Share on other sites
I believe 1 unit = meter.

Just pick a ratio of meters to pixels, such as 50.

const float MtoP = 50f;

Then for every pixel coordinate you pass in to Box2D you divide by MtoP, while every pixel out you multiply by MtoP.
0

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1351980853' post='4996989']
you divide by MtoP
[/quote]

Better to to multiply by the inverse constant for performance. So lets assume PtoM is 50.0F, then multiply by 0.02F into Box2D and 50.0F out of Box2D.
0

Share this post


Link to post
Share on other sites
In case anyone else is having a hard time understanding, this video helped me out.

[media]http://www.youtube.com/watch?v=QEzcr7AfZ0o&feature=relmfu[/media]

Thank you for your help everyone. Edited by SonicD007
0

Share this post


Link to post
Share on other sites
I'm glad you are getting things to work out for you now. A bit of a subtlety of what you mention above is the top left is zero zero which means to me that increasing y is down. This could be the great source of your troubles as you will need to multiply Y out box2d by -50.0F and X out by 50.0F. I didn't go through the video but perhaps because they too are using SDL it may have been explained there.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0