A GUI for libgdx

I haven’t worked a lot on libgdx in the past few weeks due to various things i won’t get into here. The last big thing was implementing the JNI wrapper for Box2D which Richard from StickCoding is now actively using in his Rokon engine.

The last couple of weeks went into discussing some potential games to be implemented in the neat future as well as looking into creating a GUI library on top of libgdx specifically tailored towards game development. An informal overview of what functionality would be needed looks as follows:

  • Support for different standard widgets and containers like labels, buttons, scrollable lists, dialog boxes and so on
  • Skinable
  • Auto-Layouting and support for multiple screen sizes
  • Animations/Transformations, e.g. translations, rotations, scaling, fade in and out
  • Data driven (e.g. XML) and programmatical ways to define the GUI
  • Easy integration with the input classes of libgdx, e.g. ease of determining wheter user input should go to the GUI or the game world

Now, i’ve written my share of game GUIs in the past years and have a pretty good crasp of how to design something like that. What’s new is the need for animations/transformations which i’ve always handled via small hacks up until now. All my previous GUIs have been using the standard event-driven OOP style you see with a lot of other GUI toolkits like Swing, or Nifty GUI.

It seems that in recent years a lot of people started hating this style of creating GUIs, saying it would be to tedious to work with. I can understand this notion to some degree. So a lot of fuzz was generated when so called immediate mode GUIs started to come out. What’s an immediate mode GUI? Instead of instanciating widgets from a class hierarchy and adding them into a tree like structure like a scene graph one simply calls methods that will immediatly draw e.g. a button with certain features and simultaniously checks whether the current input device state triggers an event for that button. This also means that state normally held by the widgets like the current value of a slider and so on becomes application data and has to be managed outside the GUI library. You can find a (rather confused at times) talk about this kind of GUI at https://mollyrocket.com/forums/viewtopic.php?t=134. Also, some of the bigger names out their have adopted this GUI paradigmn as well, like Unity 3D or even NVIDIA.

At first i really wanted to try out this “new” paradigmn and implement a GUI lib based on these principles in libgdx. Upon further investigation i found some problems with the approach though. Many common GUI operations seem to be awkward to implement with this approach, some seem to be solveable only with a multi-pass approach. In the end i find it more confusing to work with this approach then going the old way. I might just be getting old myself though for not seeing the brilliance in all this :).

Anyways, after discarding the IMGUI paradigmn for libgdx i was searching around for some GUI libraries which i could adopt. And i think Nifty GUI will be the winner. I’m tired of coding my own GUI library and Nifty GUI seems to be good enough for my purposes. All that is needed is implementing a few interfaces for rendering, input processing and sound output. I will try to do that tomorrow and see how it works out. At least the rendering interface should be a piece of cake really. The only thing that i’m a bit worried about is that it is not all that well documented yet, and i somehow have the impression that the developer is a bit sloppy at times. Also, it might do too many temporary object allocations but we’ll see about that. In any case Nifty GUI can fullfill all my needs listed above so i give it a try.

5 thoughts on “A GUI for libgdx

  1. I too am looking towards the nifty-gui approach for implementing a GUI on top of Android OpenGL ES and the 2D API. Perhaps we can work together on this as we are going to be solving and implementing the same tech essentially. On my side I will be interfacing nifty-gui with the TyphonRT event system such that it will work across the desktop and Android without modification for TyphonRT apps. I’ll check IM GUI links and look into it, but since I’m really keen on having it work across disparate APIs including Java2D nifty-gui is attractive since it already has peers for those APIs.

  2. Oh yes.. I’m also integrating your Box2D work into TyphonRT. Thanks for the effort there! I’m rather excited with my final entity system refactor as it should play nicely with integrating various physics systems.

    As always keep up the great work!

  3. Please keep in mind that the Box2D wrapper is not tested extensively. Also, i’d love to get credit where credit is due. Finally, if you plan on selling that stuff with the Box2D wrapper tip me enough so i can buy me 2-3 beer 🙂

  4. Well as you know I’d love to work with you regarding offering component add ons to TyphonRT and these can come out of your work with libgdx. My goal is to open a component marketplace where myself and any 3rd party dev can sell add ons to TyphonRT. Well maintained & tested native binding libs is right up that alley; perhaps even more than beer money is possible! 🙂

    I’ve not spent as much time recently on the native side of things making bindings and such, so you do have a knack here even though you down play it a little. 🙂 I think the key to offering a native binding as a for pay component is thorough testing and maintenance. That is the true value when creating the binding not just the quicker process of making the initial version.

    So yeah lets definitely keep in contact and get high quality tools out to devs on Android and the desktop at reasonable costs (or free, but beer is so good, perhaps even a steak dinner!) ;P

  5. What was the main problem with this approach?

    What about TWL? I see that now TWL will be dropped because of new Scene2D ui.

    At this moment, I don\’t know what would be the best choice of GUI on top of libgdx… Something which has focus control controlled also with TAB like, if you are running on desktop.

Leave a Reply

Your email address will not be published.