Gdx2D and Super Jumper

Good news everyone. I finished the gdx2d backend today. What is gdx2d? An image manipulation library. A very small one. It allows us to load Pngs, Jpegs and other formats uniformely on all platforms in native code thanks to the awesome stb_image library by Sean Barett. The stb_image library will load an image to either alpha, luminance-alpha, rgb888 or rgba8888 format, immediately suitable for uploading as an OpenGL (ES) texture. In addition i added support for converting images to rgb565 and rgba4444 so one can conserve some memory if needed (e.g. large backgrounds and the like).

Based on the image loading and conversion functionality I implemented procedures to set and get pixels, draw lines, circles and rectangles, fill circles and rectangles and most of all blit portions from one image to another image. All this works without you needing to care for the underlying pixel format, you always work with rgba8888 when specifying colors and alpha. The same is true for blitting of course. Additionally we support alpha blending for all operations. Finally, i implemented nearest neighbour and bilinear filtering for the blitters. While i tried to make the performance not suck entirely, i didn’t put any emphasis on speed. Especially the blitters are not something i’m proud off so if you want a good laugh check out the source code. I’ll eventually convert the bilinear blitter to fixed point. For now the performance is sufficient.

Why did I do that? For one, i wanted to get rid of the dependency on BufferedImage on the desktop and Bitmap on Android. There’s just so much shit going on behind the scenes (e.g. alpha premultiplication and so on) that it’s not funny to work with these classes. Due to this dependencies we also have to implement custom backends for the Pixmap and Texture interfaces which led to some incoherencies when it comes to premultiplied alpha (jogl and android backend have it, lwjgl and angle don’t). With gdx2d we can decouple libgdx from those system dependencies and have a single Pixmap and Texture class. Best of all: we have full control over everything. You can now directly access the memory a Pixmap occupies via a direct ByteBuffer if you feel that our implementation of the drawing methods is lacking!

It also means that using Pixmaps and Textures gets a bit easier. I have yet to make those changes live, i’ll wait for Dave to give me the green light as he’s working off the trunk in Discretion. Don’t want to fuck up his game so close to release 🙂 Here’s a fun image from the test of gdx2d. Just some clearing, drawing, filling and blitting with and without blending.

If all goes well you can use the new Texture and Pixmap class by tomorrow evening. Hurray…

In other news: i converted one of the example games from my book “Beginning Android Games” to libgdx. Took me maybe 20 minutes in total and worked as expected out of the box. You can find it in SVN/trunk/demos/superjumper. Here’s a screenshot.

There’s only a few minor things left for 0.9, then it’s time to go fullblown 3D. The book is nearly finished as well (at least the first drafts for each chapter) so i’ll have a lot more free time to go back to libgdx more often.

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 🙂