This year’s physics tutorial was a lot of fun and all the speakers did a great job. We had some new speakers this year and all the presentations contained new material. You can get all the presentations here: Downloads. Look for files with a summary prefix of “GDC 2013″.
You can get Glenn Fiedler’s presentation here: click
The best way to use SSE is to use the __m128 intrinsic directly. Unfortunately Visual Studio displays the values backwards (w,z,y,x). Bleh. Here is a change to autoexp.dat to correct the order.
First comment out this line:
And add this line:
__m128=<m128_f32>, <m128_f32>, <m128_f32>, <m128_f32>
I gave a presentation this year at the Game Developer Conference on building a ragdoll system for Diablo 3. You can get it from the download page here: http://code.google.com/p/box2d/downloads/list
While the presentation is focused on ragdolls, there is some information that might be useful to many Box2D users, especially if you use joints.
Keep in mind that a shape does not know about bodies and stand apart from the dynamics system. Shapes are stored in a compact form that is optimized for size and performance. As such, shapes are not easily moved around. You have to manually set the shape vertex positions to move a shape. However, when a shape is attached to a body using a fixture, the shapes move rigidly with the host body. In summary:
- When a shape is not attached to a body, you can view it’s vertices as being expressed in world-space.
- When a shape is attached to a body, you can view it’s vertices as being expressed in local coordinates.
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;
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.
I miss having a blog.
I brought down the old gphysics blog because I was having too many security troubles on godaddy. My new host has had zero security issues. Hurrah!
The old Box2D site was custom made raw html, making it tedious to add posts. Hopefully soon you will start seeing more content on this page.