did some physics libraries have ported to android?
what is better for perfomance? (2d)
I know this is an old topic but i thought i’d resurect it to offer some useful info.
For fun i tried JBullet on Android. The good: no garbage collection issues! The bad: it’s bat shit slow. You can find a demo of it at http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=81. I also did a quick JNI binding for the native lib and it has much better performance.
JBox2D is completely unusable as it produces so many short term objects that the GC goes crazy. The only way to get a proper and fast enough physics simulation up and running at the moment is to write JNI bindings to your favorite native physics library like Box2D, chipmunk or Bullet.
Hmmm but there are some games out there using Box2D or similar. Anyone knows how they are made? JNI bindings to Box2D? Camel Games has a few games like that - ShootU, Blow it Up, Crayon Physics clone. Any ideas?
Camel Games simply wrapped Box2D via JNI. There’s sadly no alternative to this in pure Java given the weak Dalvik VM.
I tried using the (most excellent) phys2d library during the early stages of writing Word Drop. It ran very slowly, with the main culprit seeming to be garbage collection. If I ever really needed 2D physics for a new game, I will definitely take a look at it again - maybe with a few object pools it would start to look pretty workable.
P.S. Sorry for reviving a long-dead thread!
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.
Thanks ewjordan, really interesting post and links…sounds like I was having a fit of ludicrous overconfidence with the “a few object pools” remark
Hi there ;D
i’m back to develop android game with physics but for this moment i’m need a 3d physics engine (like ode) for android. the game scene will be not so big : <35 objects like primitive cylinders. But i’m looking for a faster engine for android (also not eating much memory)
What the engine will be better?
[quote] But i’m looking for a faster engine for android (also not eating much memory)
[/quote]
Tried JPCT ? The only one I know of that works quite good.
[quote]Tried JPCT ? The only one I know of that works quite good.
http://www.jpct.net/jpct-ae/
[/quote]
Wow, looks pretty nice, and i will don’t need to make bicycles bymyself =) but as i see it uses jBullet?