porting to r112

Coordinator
Jun 19, 2010 at 7:24 PM

It looks like Box2D r112 on the Google Code project is the latest stable revision (all future revisions have warnings from Erin).

I am beginning to update Box2D.XNA from about r70 to r112 and expect to be done in the next 3-5 days.  It's a pretty big amount of change and some new concepts were added (edge shapes, loop shapes, new tests) as well as some bug fixes.

I'm about 10% through the port right now and will update our Source Code when I am finished.

The recommended release will remain the same (r70+perf optimizations) until we know the new port is stable and has the same or better performance.

 

I'll update here again when it is ready.

Jun 19, 2010 at 10:53 PM

Good news, I'm eager to see the latest Box2D changes incorporated in Box2D.XNA. Thanks for your efforts!

Jun 20, 2010 at 8:23 PM
Edited Jun 20, 2010 at 8:40 PM

Has Erin added any sort of 'not affected by gravity' flag yet?

I keep having to re-add it every time the project gets updated. There are ways to fake it by applying forces, but the most efficient way is to never apply the gravity at all.

 

[edit]

I've also been wondering how direct this port is. Are you able to capture the little optimizations Erin makes in C#, or do you have to duplicate the functionality using the same techniques, and then optimize in a different direction?

Jun 21, 2010 at 6:15 PM
Great news! I'm very interested in edge and loop shapes.
Coordinator
Jun 24, 2010 at 2:52 AM

This is still coming along, about 50% done now.

I don't think Erin has added any "not affected by gravity" flag, but if you have a patch I can look at applying it as part of our next update.  We have some other pending patches that I will look at as well.

As for the optimizations, we capture most of them unless they are micro-optimizations that only make sense in C++.  Algorithmic wins are reflected for sure since we copy the data structures and algorithms from the C++ version for the most part.  We do not use Erin's vector type since XNA has a good version of that and it would be annoying for game developers to have to use a special Box2D vector.

We also add a ton of our own C# and Xbox360 specific optimizations.  Certain things in the C++ code like stack arrays are not practical in C# so we have helpers like FixedArray<T>.

With our latest code (not what I am working on now but what is checked in) we generate 0 garbage per frame and that takes a lot of modifications, so we do have some changes compared to C++ version that are performance related but nothing at the algorithmic level.  For instance, we reuse islands instead of creating new ones for each iteration but the algorithm for solving position and velocity constraints is exactly the same (but we do manually inline a lot of the math since the C# compiler for Xbox360 won't do much for us).

Coordinator
Jul 6, 2010 at 1:55 AM
Edited Jul 6, 2010 at 1:56 AM

We're now fully updated to r112 and have fixed all known bugs related to the port.

We still have some outstanding patches that we will be looking at applying and also we intend to do a perf push now that we have the new constructs associated with r112 (they probably hurt perf a little bit so we need to make it up somewhere else).

We will probably add threaded island solving that will be configurable, so on Xbox360 you'll be able to take advantage of all 5 hardware threads.

Jul 6, 2010 at 11:45 AM

Great. Does r112 include the edge bodies? And if so, which do you think would be the 'preferred' method of handling concave polygons; several convex polygons, or a loop of edges?

Coordinator
Jul 7, 2010 at 1:48 AM

It includes edge and loop shapes.

A loop shape has up to 8 sub-shapes which are each edge shapes.  This unfortunately means there was an extra level of indirection added to all Shape derived types which might impact perf even if you aren't using Loops.

Given the nature of a Loop it is probably going to be significantly faster to use a regular PolygonShape when you can.  It depends on how hard it is to make the concave shape with convex polygons and how many you will need.  Loops also will not collide on the inside which means you can have things inside of them and they won't be able to get out (compared to a PolygonShape which will push anything inside of it out as fast as possible).

I think in general Loops or Edges will be good for making line-rider style level definitions for platformer games and also for cases where you want to have a container with dynamic bodies inside.

Jul 18, 2010 at 4:14 AM
Edited Jul 18, 2010 at 4:55 AM

I'm a little confused about how I am supposed to use a loop shape. It looks like, in the current code, it's just a collection of vertexes. There doesn't appear to be any limit on the number of them, either, seeing as you aren't using the fixed array to store them. Am I supposed to just assign my vertexes to the shape's _vertices member before creating the fixture?

 

I'm going to try exactly that, but if there's a right way to do it and that's not it, let me know.

[edit] That seems to work. I am seeing a definite speed decrease with the new version, though. Not much, just enough to bump me down from 60fps to 57 or 58 now and then. [/edit]

 

An aside; since in C# arrays already have a Length member, the _count member seems redundant.

Coordinator
Jul 27, 2010 at 6:54 AM

I am actually not familiar with the usage pattern of loop shape (we ported it, but haven't played around with it).

Based on the code we were porting, we are expecting a small perf degredation but it should be minimal if you stay away from loop shapes.  We noticed some weird behavior on the dynamic tree test in our version and the C++ version so there might be a new bug there, we'll follow up with Erin.

To offset some of the perf degredation (and even get better perf than before) we are looking at making island solving parallel as much as possible, and will continue to make targetted perf improvements.  First step is to get some good microbenchmarks set up to work against.  The pyramid test has been one that we've used but it is a somewhat narrow use case.