Android only game in OpenGL: performance in C++ (NDK) vs Java (Dalvik) [closed]

Question

I know that similar questions have been asked before, but...

We want to develop (at least hope) an indie game but still a game with high quality graphics with hundreds if not thousends of moving objects on the screen so we expect very high number of polygons and requirements for hittest and perhaps some AI.

I know the basic problem with java is garbage collection. But it's not an issue, we plan to allocate all of the required memory before the game starts and for transient objects we will use pooling (so in the game loop the new keyword will never be written). And we plan to use every possible techique mentioned here (Google I/O 2009 - Writing Real-Time Games for Android).

The main reason we insist on Java is deployment and we only want to develop for Android (for now at least)

So can the same performance in a game be achived with Java (even if that means ugly/not idiomatic code) as if we did it with c++. If not, what are the specifics? Or perhaps if it's possible but very-very unpractical what are these reasons?

(For example I read something about java Buffers and OpenGL are not the best pairing but don't remember the specifics - maybe some expert)

Answer 1

You're going to be paying a fixed additional cost per call to use OpenGL from Java source code. Android provides Java-language wrappers around the calls. For example, if you call glDrawArrays, you're calling a native method declared in GLES20.java, which is defined in android_opengl_GLES20.cpp. You can see from the code that it's just forwarding the call with minimal overhead.

Nosing around in the file, you can see other calls that perform additional checks and hence are slightly more expensive.

The bottom line as far as unavoidable costs goes is that the price of making lots of GLES calls is higher with Java source than native source. (While looking at the performance of Android Breakout with systrace I noticed that there was a lot of CPU overhead in the driver because I was doing a lot of redundant state updates. The cost of doing so from native code would have been lower, but the cost of doing zero work is less than the cost of doing less work.)

The deeper question has to do with whether you need to write your code so differently (e.g. to avoid allocations) that you simply can't get the same level of performance. You do have to work with direct ByteBuffer objects rather than simple arrays, which may require a bit more management on your side. But aside from the current speed differences between compute-intensive native and Java code on Android, I'm not aware of anything that fundamentally prevents good performance from strictly-Java implementations.