Android threading vagaries

Any which way you need to justify it, suit yourself. :wink:
* Nate goes back to developing on the desktop and deploying to Android…

Very cool. Android caused me to step up my game as things go too. Testing never hurts.

Some of the silliness on Android is well just blatant lack of testing on big G’s part. I’ll throw out some stuff starting with Froyo though it goes back to the beginning; the “official” Java GL/ES 2.0 bindings in API level 8 are incomplete as code gen was used to create it, but it was never tested thus wrong signatures on some methods preventing some VBO usage. Gingerbread for the most part had no new problems as far as I’m aware for game dev. Honeycomb (3.0 / 3.1) had a major Java NIO regression where calling duplicate on a non ByteBuffer caused an immutable endian swap on the buffer! Way non-kosher there and it broke all my GL code as I have a little extended NIO API that used duplicate on a FloatBuffer; that took me 45 hours of debugging to find and then provide big G a test case; I bitched them out over that though. :stuck_out_tongue_winking_eye: Only time I’ve seen the Android team fix a major regression in ~3 hours after test case was provided. Most items in the bug tracker languish forever. Last big thing to cause a ~4 day workaround in my efforts, IE 2 to fix, 2 to make clean, is the piss poor annotation support in Class likely taken from Harmony; horrible GC triggering code. All API levels affected up to Ice Cream Sandwich; had to implement caching myself. MotionEvent and such is an abortion of a proper API. So yeah… There is always another big bomb shell awaiting around the corner. Not exactly an exhaustive list and of course off topic.

You should be able to get far more than 500 sprites on screen w/ mid level hardware. I’m sure the OG droid can pull that off. Fill rate / overdraw is the biggest issue, etc. Err… this is not about threading anymore… :stuck_out_tongue_winking_eye:

@Nate libgdx still require ~6 lines of code changes to configure between desktop & Android usage? I’m aiming at no code changes.

Don’t worry, it’s still on topic! Indeed on the Galaxy 2 I managed some daft figure like 2000 sprites @ 60fps but the problem was that to do it reliably everywhere I had to return to single threaded code and the lowest common denominator that I wanted to support. 500 sprites is still quite a lot!

Cas :slight_smile:

how does sprite count reflect say, poly count for “3d”? not at all, or just a little etc…

Sprites and 3d polys are very much like comparing apples to oranges. Sprites are the worst possible case for 3d cards to render, generally. GPUs are designed to render models super-fast by virtue of shared vertices already being transformed. Furthermore they rarely have to worry about transparency. And of course each sprite needs rotating and scaling individually, probably on the CPU. And so on.

Cas :slight_smile:

A little OT, but did you make any progress on doing the rotating and transforming on the GPU with shaders? I assume this is all ES 2.0?

No that requires geometry shaders basically, trying anything else is just like gnawing your own legs off to gain a 5fps gain = #FAIL.

Cas :slight_smile:

What’s wrong with geometry shaders?

ES 2.0 does not have them.

I use lots of threads, but for Android I found the same issue and just use a custom GLSurfaceView with a single rendering thread.

My multi-player games have 2 constantly running threads and even that is a bitch on Android even though they don’t synchronize.

So it is not just a rendering issue, but a scheduling issue on Android.

I’m not hearing much good stuff at all about Android nowadays… Google needs to start bitching on the phone manufacturers…