OpenAL & Natives Loading in Libgdx

Nate’s been hard at work the past few weeks and implemented a new audio backend for all desktop backends (Jogl, LWJGL, Angle). It’s based on OpenAL instead of Java Sound and should work a lot better, especially on those pesky pulse audio infested new Ubuntu versions.

Nate also rearranged the natives loading for the desktop quite a bit. No more pollution of the temporary folders. Instead we now CRC special files in the natives jar and create a folder from that. This way a user will always only have a single version of the natives on her PC (for a given gdx version that is). This also include snapshot builds like the nightlies.

Finally, i found some time to implement most of our own 2D image library based on the might awesome stb_image. We now support alpha, alpha luminance, rgb565, rgba4444, rgb888 and rgba8888 image formats on all platforms. You can draw lines, circles, rectangles and blit one image to the other. Well, the blitting is a WIP but i hope i can use this weekend to finish this off. For you this means that the way you create Pixmaps and Textures will slightly change. Instead of this:

You can start working like this

The same goes for Pixmaps which will also be constructed via a constructor instead of the factory methods of the Graphics interface. All this changes will allow us to get rid of the backend specific image loading and processing cruft and unify our image pipeline.

As it looks the 3D related stuff won’t make it into 0.9. My book writting still keeps me very busy and i can’t find the time to get into that stuff. Fear not though, we have something very nice for you in store once we start working on the 3D classes again. Look up assimp 🙂

So the roadmap will be to finish off the musts for 0.9 and then fully concentrate on the 3D features for 1.0. Once 1.0 is out i’ll start working on documentation in form of tutorials and maybe some more screencasts. Once that is done we’ll go into maintainance mode and i can finally start writting some games again 🙂

3 thoughts on “OpenAL & Natives Loading in Libgdx

  1. To some extend yes. We are currently up to 3 times faster than Skia (the lib used on Android). But that can be attributed to the complexity and power of Skia which we won’t mirror 100% of course. We can take some shortcuts.

    Concerning getting and setting pixels: You have direct access to the image memory and therefor pixels via a direct ByteBuffer. In this regard you’ll get a little better performance, especially if you temporarily copy the contents of the ByteBuffer to a working array on the Java side, manipulate the array and then put the pixels you manipulated back into the ByteBuffer.

    However, we do not aim for the fastest possible implementation as setting and getting individual pixels is nothing you want to do in an OpenGL based application due to texture uploads being darn slow.

  2. It’s more to do with procedural textures at init or in a concurrent task. So slow is fine, but being faster is obviously better!

Leave a Reply

Your email address will not be published.