I have developed a physics engine specifically for mobiles. You can check it out here: http://emini.at

I also developed a small game using it recently. It is still in development. Specifically I have not yet been able to test it on a real device: http://emini.at/download/Tremini.zip

It uses physics, touchscreen and accelerometer - all you can wish for.

I looked at quite a few physics engines (for android) both 2d and 3d implemented in java but most had performance issues - the garbage collector on the phone will cause glitches every few seconds no matter how careful you are with dynamic allocations.

I even implemented my own impulse based solver for simple rigid bodies and solid joint and saw the same problem although less frequent even though I was using object pools, there are things in java where you just can't control. (I come from a c and c++ background so there maybe better java programmers but not me and I tried for 2 days).

I've not looked at the previous posters engine so can't comment on that but I think the best thing to do for performance is to use the android native sdk (ndk) and run the physics engine in unmanaged code written in c or c++. That way the physics is outside the domain of the garbage collector and runs much much more smooth. (I've done the same for rendering in open gl also).

Also another point, my handset (actually most current android handsets i think) the htc hero does not have a fpu so you will get a big performance increase if you dont use floats but fixedpoint instead. The library I used (free 2D physics lib called box2d) allowed me to do this and I am more then happy with performance now.

Hi,

I have optimized the engine not 2 day, but more like 2 month - it really does not allocate unnecessary stuff. In some situations the GC is even better than directly allocating in c++, because it can distribute its junks better. But that is probably quite a theoretical thought.
I have tested the engine against a tightly JNI wrapped box2d and found that I have almost the same performance.

My library uses fixpoint arithmetic, but there is also a floating point version. Both library can be used through the same interface. So you could write the game code and compile it once with the fixpoint library and than with the floating point library.

However, I consider using the NDK. But I would not use it in order to get rid of the GC, but of virtual method calls.

The main advantage that a SDK library offers is a much more comfortable integration.

Congrats I know how hard a job it is to do that. Like I said there are lots of better java programmers then me :) coming from c its difficult to work with Java and giving up the memory managment - I do disagree about the GC being better then manual management (although thats a big debate im sure), sure its easy to screw up in c but at least you can more easily without spending 2 months optimimise and be more specific by using your own allocators/memory management scheme.

It probably would be easier to use a java library such as yours to avoid the hassle of using 2 languages but I think its worth pointing out that there are open source alternatives and box2d is very good i've found.

There maybe portability issues with the native code but so far all the android phones use ARM based cpu's - im not sure how the ndk will resolve the issue in future non-ARM android phones flood the market but hoping google have a plan :)

Yes, of course Box2D is a great library. I have great respect for the work of Erin Catto, who did a really great job.

And for some people (like you probably) this is certainly a very good way to go. For people who do want to have simple interface and want to see results fast, my Engine is better suited.

(Aside: I did not spend 2 months only optimizing memory issues, but a lot of other stuff too)