Slow news day

I’ve been rather busy today with my day job and only found 2 hours to do something related to Android (yes, only 2 hours…). I played around with shaders and extremely large vertex counts today, and behold it was good. With around 100000 triangles i get a steady frame rate of 37fps most of the time. Now the setup of the scene is a bit special, many of the triangles are rather small or get backface culled. It’s still nice to know that the PowerVR is not all that bad after all. I also noticed a problem with libgdx on Android where loading a non quadratic texture with mip mapping enabled produces nice black output. I have to look into that. But not today. Stefanie made me go to the fitness center she works at. She says i’m to lazy, fat and to dumb :/

I reworked a lot in libgdx as you can tell from the last couple of posts. The reason i haven’t yet release a new version is that i still want to rough out some edges. Text rendering is now extremely easy and fast via the SpriteBatch class and the new Mesh class really helped a lot when intially trying some shaders. I hope to get a new version out by tomorrow. I also fixed a nasty “feature”: When using OpenGL ES 2.0 the surface created will not have a depth or stencil buffer by default. I fixed that and everything works fine now. You can check out the latest source from the SVN if you want the cutting edge features. The examples in src/com/badlogic/gdx/tests should give you a pretty good insight into how things work now along with the extensive documentation.

androidgl2 release 0.3

As suggested by Scott in a comment glBufferData and glSubBufferData now also allow the use of non-direct buffers which should speed up things like doing sprite batching. You can find the latest release and source at http://code.google.com/p/gl2-android/.

I’m still in the process of making some libgdx parts work out of the box with OpenGL ES 2.0. The mesh works perfectly fine as shown earlier and SpriteBatch is also coming along nicely. What’s not working at the moment is outputting text via SpriteBatch and i can’t find the problem. Well, the day still has some hours left.

Dalvik, direct Buffers and VBOs

Today i found some time to implement the SpriteBatch class which is losely copied from XNA. It’s purpose is it to make writting 2D games easier as well as outputting text strings. API wise i’m happy with it and it’s extremely easy to use. It basically allows you to output textured quads. Then i did some micro benchmarking, 7fps for 50 quads. Wtf! To make a long story short: in the new Mesh class i used direct ByteBuffers all the way out of an old habit coming from my Jogl background. SpriteBatch assembles multiple quads sharing the same texture in a float array which is then transfered to the ByteBuffer which in turn is uploaded to a VBO on the GPU (yeah, that double transfer sucks, another reason to go native). Now, to write that float array to the ByteBuffer you usually use ByteBuffer.put() or rather FloatBuffer.put() by simply getting a FloatBuffer view of the ByteBuffer. For my test case that single put of 50 * (2+4+2) floats took 90ms. Nice. I will dive into the source of Dalviks implementation of a direct ByteBuffer tomorrow to figure out what goes so horribly wrong there. For now the simple solution was to use non-direct buffers which work fine with VBOs. The reason you can use non-direct buffers is that upon a call to glBufferData or glSubBufferData the non-direct buffer is accessed once and its content is uploaded to the GPU. No further reference to the buffer is made. The problem is that on some Android devices VBOs are not available or don’t work properly (Samsung Behold 2, Cliq etc.). There one has to use vertex arrays which in turn need direct buffers as the memory area specified via glXXXPointer is in client memory (RAM) and not on the GPU. When you call glDrawArrays or glDrawElements the memory areas you specified with the glXXXPointer will be referenced and their content will be transfered to the GPU. This means that the pointers to those areas have to stay the same which might not be the case with indirect buffers. What does this all mean? SpriteBatch will crawl on devices not supporting VBOs. Nothing i can do about it. A sad day 🙁

Hamsters are fun!