For 2d physics, what we're using at the moment is the Emini engine (http://emini.at
), which seems to run pretty well (it was originally developed for J2ME, so it's garbage-free and written using fixed point math). The only problem is that it costs money to use in a game, so I know that might be a show-stopper for some. It also doesn't have as many features as most of the Box2d-inspired engines, and as we all probably know (maybe we've blocked it out of our memories by now?), dealing with fixed point math in Java is a major pain in the ass because of the limitations of the language.
And yes, I do
notice the irony that as one of the developers on JBox2d I'm going to be paying to use a closed source engine with fewer features, and I'm not terribly pleased about that, but it's the shortest path to market at the moment...
The JNI bindings to Box2d seem decent, AndEngine (http://www.andengine.org/
) has all of that set up inside the engine if you're interested. You can get a sense of performance here: http://www.andengine.org/blog/wp-content/uploads/2010/06/andengine_physicsbox2dextension_chart.png
For us that's not an option because we're using a different framework that for various reasons makes using JNI very tricky.
@Mr EEK: I'm not sure if a few object pools will be enough, sadly. Locally I've gotten JBox2d down to almost zero garbage (I probably chopped away 99% of the allocations in the entire engine), and it's still not as fast as I'd like, even on my Nexus One. With 100 stacked objects, I'm ending up with about 20 fps, which is half the frame rate that AndEngine gets with the native binding (though to be fair, the drawing method that I've been using during debugging is extra slow b/c it's not using OpenGL, and I have no idea what sort of test config AndEngine uses, it might not be a full pile-up like I've been testing).
I think one of the problems is that the performance characteristics of Dalvik are very different from Hotspot, which we've gotten used to optimizing for over the years. In particular, things like getters/setters which are almost free on Hotspot are very
costly on Dalvik (http://developer.android.com/guide/practices/design/performance.html
) - there's a 3x speed penalty on crappy phones w/o JITs, and a 7x
penalty on the ones with JITs! I suspect this might be a large part of the reason that the native bindings work faster, the compiled code doesn't pay these penalties.
I'm going to see if JBox2d does any better when I pull out the getters/setters, but I'm not overly confident at the moment about finding any magic bullets for this...profiling seems to show no serious unexpected bottlenecks, compute time is pretty well distributed across the engine in proportion to where the actual work needs to happen, which leads me to think that without some major by-hand optimizations specific to Android (possibly including moving some code to use fixed point...blech), I may just be up against a performance wall.