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.

Fixed Point Support in libgdx is Gone!

So, the poll said i should get rid of fixed point support in favor of a cleaner implementation. I complied. A couple of tests have been removed and i had to adjust the Mesh class a little. For you this means you will need to check all the Mesh() constructor methods and remove the second parameter which specifies whether to use fixed point vertices or not.

To the one soul that voted against the exclusion of fixed point support: i’m sorry. What was your use case?

In other news: we are rewritting major parts of the backends now. We’ll start by cleaning up the Mesh class and rewrite it completely. After that i’ll go over all Backend implementations of Application, Graphics, Files, Input and Audio and see if i can make those leaner and meaner (Lwjgl will be rewritten completely as it sucks ass, might be true for Jogl as well.). The applet backend will die. Instead there will be a second Application implementation in the jogl and lwjgl backend that implement that functionality. For this we have to change the semantics of FileType.Internal on the desktop as mentioned earlier: it will first search the classpath and then the root directory of the application.

We’ll also remove some clutter methods from sprite batch in favor of the simpler Sprite class.

Lots and lots of work ahead. I will probably not make the end of october release :p You can play around with the nightlies in the meantime if you want. I want to get this right now so i can build upon a clean basis.

Warning: i consider removing the RenderListener interface and instead merge it with Application. Not sure yet, but might happen.