x86 NDK support!

Finally it’s here! The NDK r6 was released and features two awesome additions: x86 support and ndk-stack. I’ll try to make our native code compatible with the x86 backend tomorrow night. Shouldn’t be a big issue as we only have very little ARM assembly code.

Good stuff!

Multi Sampling Anti-Alasing in libgdx on Android

Added that today. Here’s a pic of the MD5Test on my Nexus One

On the right there’s no MSAA, on the left there is. I used 2 samples for this. On my Nexus One i get a hit of 20fps, the HTC Desire HD takes it with grace and renders at full speed.

To get MSAA on Android (if available) just specify the number of samples you want in your AndroidApplicationConfiguration:

If no configuration with that number (or more) samples can be found libgdx will fall back to a non MSAA configuration.

Tegra chips don’t support MSAA. Instead, NVIDIA provides something called coverage sampling anti-aliasing (CSAA).

I tried to add this as a fallback but there are a couple of problems:

  • We need to also invoke the glCoverageMaskNV() extension at least. This method is not exposed in the Android SDK (not in libgles2.so). One has to link to NVidias binaries, something i don’t want to do as that would blow up the natives’ size on Android
  • As much as i tried, i couldn’t get a single EGL configuration on my Transformer that actually had > 1 coverage samples. Either i’m stupid (possible) or there’s something fishy here.

Long story short: no anti-aliasing support on the Tegra.

Well, i managed to get it working. To get CSAA for your app, just set the AndroidApplicationConfiguration.numSamples as shown above. However, CSAA needs you to also clear the coverage buffer. For this you have to do the following:

Gdx.graphics.getBufferFormat().coverageSampling is a boolean that indicates whether CSAA is enabled, in which case you also have to clear the coverage buffer as shown above.

Note: CSAA seems to be available only for GLES 2.0 contexts.

Stuff is in SVN, nightlies are build.

ShaderProgram additions & VertexAttribute naming conventions

edit: as pointed out by Michael, i changed TEXCOORDS_ATTRIBUTE to TEXCOORD_ATTRIBUTE and the string is “a_texCoord” now instead of “a_texCoords”
I added a couple of new methods to ShaderProgram.

Pretty straight forward and quite useful. You can now query for all the attributes and uniforms you defined in your vertex and fragment shader (that didn’t get optimized away by the gpu driver…). This is useful for wiring up Mesh VertexAttributes or creating little shader preview applications.

Speaking of VertexAttributes. The last parameter of a VertexAttribute is the shader attribute name used in GLES 2.0 for binding that attribute to the shader. Up until now there was no strict enforecment of the attribute names of Meshes generated by libgdx classes (e.g. SpriteBatch/Cache, ObjLoader, MD5Loader etc.). This has changed today. All those Meshes use default attribute names now which are defined as static Strings in ShaderProgram:

Note that the TEXCOORDS_ATTRIBUTE is ALWAYS augmented with the texture coordinate set it comes from. E.g. if you mesh has two texture coordinate sets the first one would be called “a_texCoord0” and the second one “a_texCoord1”.

When you create your own Meshes you can of course name things however you want. You can also modify the attribute names after loading a Mesh via say the ObjLoader if you so prefer.