libgdx 1.0 roadmap
So we are heading towards the 1.0 release of libgdx. Here’s the list of things i’d like to add.
- 3D Model loading/rendering: loading of skinned and static models. We currently support OBJ (to some extent) and MD5 (without materials, those have to be hooked up manually). The new core API will only understand a binary format in 1.0, an import tool for Ogre XML and possibly Collada (ugh) will mediate. During development time you can hook up the 3rd party loaders via simple plugins (jars…). See http://www.badlogicgames.com/wordpress/?p=1652.
- Model Preprocessing: Conversion of skinned models to simpler keyframed models. That’s already implemented to some extent and known as baking (at least between me and Dave ). While it takes up more memory it’s a lot less heavy on the computational side of things
- DecalBatch: integrate Vevusios awesome DecalBatch as a counterpart for the 2D-only SpriteBatch. Useful for 3D particle systems and more advanced 2D rendering. Consolidate with SpriteBatch? Probably not.
- AnimatedSprite: I’m still not happy with the idea of an AnimatedSprite as it promotes the wrong pattern imo. But who am I to judge! Wavesonics and Cyble have done some great work and posted it on the forums. With their permission (and one or two tests to be integrated in our “test suite”) I’d like to add it to the core API. For now you can use the Animation class or roll your own.
- Application Configuration: at the moment you can only configure a few things related to the application Window/activity/OpenGL/EGL context. I’ll look into making this more flexible, namely full-screen support, easier integration of Jogl/Lwjgl application into Swing/SWT UIs (with context sharing), turning off unneeded listeners on Android (sensors) and so on. The constructors of the different Application implementations will change slightly (they’ll expect an XXXConfiguration object), nothing super API breaking
- TrueType Fonts: that was actually part of libgdx up until version 0.6 or so. For various reason it got replaced by Nate’s BitmapFont stuff in conjunction with Hiero. I’ll add this functionality back in with the help of stb_font, just as we use stb_image for our image manipulation API. (Btw, did you know that Andengine still uses a modified version for TTF font rendering of our original code? All hail open-source )
- GPS, Gyro, new Android Key constants:: We have most input devices covered (save for cameras). The GPS and Gyro is the last big thing on the todo list. I haven’t looked into the differences between handling Gyros and Accelerometers on Android, might be the same thing API wise actually. Android 2.3 adds a couple of new key constants which should also get some love
- libmpg123: Add support for libmpg123 decoding back in. It’s actually just a matter of getting the build up and running and packaging the shared libs along side our gdx-natives. Thotep will hopefully like this
- Box2D Pre-/Post Resolve: while super useful you can actually do this already without that resolver interface. See the box2D test bed. It’s the only thing that’s actually missing from the JNI wrapper so for completeness i might just add it. Maybe i find the time to update to the latest and greatest version as well (probably not).
- Native Math: some of the math classes could need some native code love on Android, namely the Matrix class and some of the Intersector methods (ray vs triangle soup).
- tile map rendering: I’ll have to look into Dave’s mighty TMX at some point and see whether i can improve performance a little. Maybe make things a little bit more generic and decouple them from the TMX format
- 3D scene graph: very, very, VERY simple 3D scene graph support. For many game’s it’s just overkill and you should usually separate your logical scene graph from your graphical scene graph (unlike our scene2d package…). To not further encourage a wrong pattern i’ll try to keep this at the most basic level
- Space Partitioning: I really love spatial hash grids as they are more than sufficient for most games and very easy to implement. I’ll try to implement those for 2D and 3D (2D is done and discussed in the book actually…).
- bug run: Fix the four bugs on the issue tracker
- Keycode Constants: KEYCODE_ must die!!! (Nate’s request)
Given that the book is almost finished and that i have a little bit more free time a lot of this should be possible in the next 1-2 months. Contributions are of course welcome as always (they of course have to pass our nitpicking and unfair screening process).
That’s the plan. Let’s see how it turns out. Leave feedback and suggestions in the comments!