Box2D Forums

I am porting the JBox2D testbed to Android. Now Varying Restitution, Varying Friction, Pyramid have succeeded to run.
Details, source, etc. are available here:

http://code.google.com/p/androidbox2d/

Currently, I have two questions:

1. There are a lot of garbage collector when the test is running.
2. The tests run slow, espicially the Pyramid test which have many objects.

Any idea about optimization?

Hello.

I'm also working on using JBox2D with Android. I mentioned in the main JBox2D thread that I'm doing some optimization with the goal of reducing garbage collections. Essentially my strategy is to remove as many Vec2 creations as possible by inlining them into local floats. I expect I'll post a patch sometime this week.

Re: the Pyramid test, I would be surprised if that ever ran very quickly. On the iPhone with optimizations cranked up (using the C++ Box2d), the Pyramid slows the thing to a crawl, and while I don't know the Dalvik VM very well, I can't imagine that its performance will ever compare with pure C++ code running on an iPhone, even apart from GC issues.

As JJC1138 mentioned, the GC issues are manageable with some work. I never finished them myself because GC is less problematic on desktop and when we first ported we thought mobiles were not realistic targets for JBox2d (see below), but it's mostly straightforward stuff. It sounds like it's coming along well, so perhaps we'll eventually get down to near-zero garbage. I'll make sure that future updates keep this down as well (in retrospect, I wish I had been more careful about it in the initial port, but it seemed like a premature optimization at that point).

One thing - can Android do native floating point math? I was under the impression that you needed to do fixed point, so JBox2d wouldn't be feasible to run on it without first converting everything to fixed point; is that not the case?

Eek... It hadn't actually occurred to me that the G1 might not have floating point, but you're quite right, it's based on the Qualcomm MSM7201A, which includes an ARM11 processor with no FPU. I didn't notice because I started experimenting with JBox2D by hacking it into my air hockey game, and the performance was acceptable except for the GCs. But now I realize that the air hockey example is extraordinarily simple, of course (three circles bouncing around inside a handful of static axis-aligned rectangles). I just tried building a prototype that is more representative of the game I was hoping to build, and it was unplayably slow. So I guess I'm heading back to the drawing board.

That's unfortunate, lack of FPU in any Java system makes for a more difficult development experience, especially in light of the lack of operator overloading and a typedef statement (and it results in worse performance, for that matter, as the most reasonable way to handle fixed point math in Java is to make a Fixed class, which is always going to be slower and more memory-hungry than using primitives).

Do you know of any semi-automated ways to turn floating point Java code into fixed point code? I know there are some areas of Box2d that need alteration for fixed point, but that's almost trivial compared to what it would take to convert every floating point op to a fixed point one without operator overloading to aid us...

On the bright side, it's marginally easier to pool wrapped primitives than objects because of the semantic differences, so a stack-based Fixed pool could probably avoid any additional GCs.

Maybe once I get an Android phone I'll take a look and see what I can do about creating a fixed point port, or at least setting up a code transformation utility to achieve the same (I don't want to have to maintain two separate codebases, and I couldn't run them side by side without trading off performance in the floating point version). At the moment, I don't have enough time to do this, but I am planning to move into Android development eventually, so we'll see...

I had the same thought. I couldn't find any such tool, though. I can't think of a reason why it wouldn't work, but I decided against making the effort, mainly because Android is getting a native development kit soonish ("1H2009").

Well, idea about optimization including:
- remove as many Vec2 creations as possible by inlining them into local floats; JJC1138 has release a patch.
- convert float point to fixed point.

As JJC1138 metion, C/C++ native applications are able to run on Android.
I am thinking if it is better to port Box2D to Android using native C++ instead of Java. we build Box2d into a dynamically linked library. Of course, maybe the drawing is still implemented using java API of android.

Native C in Android doesn't have any hardware support for floating either, right?
So why would it be so much faster? If that was the case, wouldn't it be possible to let Java call native C-functions for lengthy calculations? Maybe a stupid question ......

The original C++ version of Box2D already has a compile-time option for fixed-point so we would be using that.

I don't recommend making a Fixed class. Just use a scaled integer primitive for fixed-point numbers.

Android supports both OpenGL ES and a native Android2D library.

OpenGL ES has one set of methods for floats and another set for fixed-point. Floats may be slower but they're easier to deal with for simple programs. A fixed-point number is scaled by 2^32, or 65,536. So, 32,768 in fixed point is equivalent to 0.5f. Put another way, the integral part uses the most significant two bytes of a four-byte int, while the fractional part uses the least significant two bytes.

The Android 2D library generally accepts floats, but some functions work with whole integer pixel coordinates.