Your libgdx apps will break

Nate and me had an hour long discussion about the current architecture of libgdx. We came to the conclusion that while it is not bad we’d like it to be more streamlined for game development. We thus decided that Application, ApplicationListener and RenderListener will be merged and replaced with something new (the design is fixed but i want it to be a surprise).

We also removed Font from libgdx. The reason is that its implementation was suboptimal and that BitmapFont is actually more powerful. While the old Font implementation promised to support full Unicode text rendering it was not fully implemented. Arabic scripts are a no go on Android, other complex scripts do not have as complex behaviour (e.g. right to left rendering, marks etc.). It was also fairly hard to implement a low memory footprint version of Font so you wasted quite a lot of memory when using it. BitmapFont can be as lean and mean as you want it to be and support outline fonts with gradients, kerning and what not. In the future we will include full Unicode support in BitmapFont.

So if you use the nightlies expect things to break hard. We do not give a release date for the next version instead we stick to Duke’s policy: “We’ll release when its done”. Libgdx 0.7 is stable and if you don’t want to change your source i suggest just sticking to it. The new API will be nicer though 🙂

We are fully aware that this might piss of some people and will be considered a bad move on our side. We think however that a beefy refactoring will provide libgdx user’s with many benefits and make the library easier to maintain and extend in the future. The next version will be 0.8 instead of 0.71 to reflect the major change in API.

7 thoughts on “Your libgdx apps will break

  1. Sounds good. Thanks for all the hard work. I recently started using libgxd for the game I’m writing. I tried andengine and rokon, but libgxd won out for many reasons (thorough javadoc, portability, clean api, etc). Just wanted to say thanks!

  2. Glad it is useful. We are not happy with the current state of the Javadoc as it contains a lot of Javadoc errors (not content errors). We need to clean this up so we can generate proper Javadoc html output for reference.

    I’m also very happy that at least one person found the Javadoc 🙂 People seem to prefer small code examples over Javadoc, so i guess that’s why Andengine and Rokon go that way. Libgdx has a big test suite which can serve as a replacement for example code.

  3. I started using libgdx a few days ago and I like it. I’m looking forward to your changes, since I haven’t made any big projects yet, I will use 0.8 as soon as it’s ready.

  4. Mario,

    This latest change intrigues me- I can see why you may want to streamline things a bit more.

    One plea if I might- please ensure that non-full screen Views remain supported. I would be very disappointed if that recent capability that you put in were to disappear. Libgdx is great for not only game development, but also for graphics intensive applications that require the speed of OpenGL yet still also require standard Android view components.

    Great job- keep up the fantastic work!


  5. No worries my solution boils down to keeping the old Application interface and building a Game class atop of it that is specialized for game programming. I need libgdx at work as well where i write visualization apps, so i too need that more “serious” functionality 🙂

  6. From what I am seeing the changes make sense. Though my app is getting royally borked by them at this stage 🙂

Leave a Reply

Your email address will not be published.