Making GUIs

Game Mechanics
#1

Hi all,

I was wondering if you guys could give me a recommendation on how to go about making GUIs? I’m using Slick2D and having some trouble.

I’m finding myself rendering a bunch of images using hardcoded coordinates, and the code seems messy in general. I can’t seem to find general advice/advice for Slick2D here on JGO for GUIs. Did I not look hard enough?

Sorry if this is a bit vague. If more specification is needed, let me know.

Thanks.

EDIT: I’d just like to note that I HAVE been using Slick2D’s GUI classes, but I still feel that I am not doing this correctly.

#2

The way I like to make GUI components is based on an abstract core class (named something like Component).

If you want to look around at some code I made, it’s here: https://github.com/CopyableCougar4/DigiTurtle-Library It’s inefficient (not to mention undocumented), but the packages ‘com.digiturtle.ui’ and ‘com.digiturtle.ui.components’ show the general component structure/inheritance.

Hope this helps :slight_smile:

#3

Thanks you for your reply!

I took a look, and since your library here is written in openGL, i’m having a little trouble deciphering it all (I decided to use Slick2D instead of pure openGL at first to get the hang of things. I plan to move more into raw openGL after I finish some projects). A few questions…

How do you decide what to use for the x and y of a component? With my current project, I seem to be hardcoding the x and y values to make the menus look even/proportional with other elements.

Would you mind giving me a rough explanation of how UIFactory is implemented/used? I’ve never dealt with XML before. Is it just a general hub for all of your UI components?

Also, off topic, but i’m curious. how much experience do you have with openGL? any projects completed with it?

#4 
UI ui = UIFactory.buildFromXML(new File("your file location"));
ui.render(); // to render
InputSystem.setHeight(...); // set this part to the height of your window. For some reason in LWJGL 2 with glOrtho I had to flip the coordinates to be right. 
InputSystem inputHandler = InputSystem.getSystem();
inputHandler.addComponent(ui);
inputHandler.collectInput(); // run 1x per frame

It’s been a while since I worked with this (I wrote it in november), but I think the XML file is read a little like this

<?xml version="1.0"?>
<ui x="0" y="0" width="1280" height="720">
... components
</ui>

I don’t want to put up a wall of text, but you can put all of the components in each other, and tags can be nested for nested UIs. Yeah the XML and UI factory just makes it so I can write UIs in XML.

In response to the off-topic:
I am quite a newbie with OpenGL (worked with it since last June), and I unfortunately have a hell of a time completing a project, so no projects completed with it.

#5

my imagination of a proper ui (based on experience with swing) is always coming down to …

  • shapes, grouped in abstract widgets like CopyableCougar4 said,
  • stored in a selfbalanced 2D-rectangle-tree,
  • fetching shapes/widgets with point-queries (at the cursor),
  • sorting front-to-back as organised in the widget,
  • peek(),
  • win

does it make sense ?

#6

Mine groups widgets in a tree-like structure, forwards input based on the component region, and sorts a UI’s components by layer :slight_smile:

#7

Interesting. I will definitely reference this when coding my GUI.

Also, I believe you missed this question :stuck_out_tongue:

[quote]How do you decide what to use for the x and y of a component? With my current project, I seem to be hardcoding the x and y values to make the menus look even/proportional with other elements.
[/quote]
@basil_, could you explain what you mean by “selfbalanced 2D-rectangle-tree”? I haven’t really dove into swing, I kind of know the basics and that’s about it. I should probably invest more into it…

Thanks again, guys.

#8

I think I just ended up hardcoding the coordinates. However, with that system I could define it in XML and it was much easier for me to tweak.

#9

sure thing. rectangle-tree like RTree, R*Tree or IntevalTree.

like CC4 says, it’s a tree-structure (nodes with n-children nodes). the twist with r-trees is - they’re very good at storing shapes. there are alot tree-structures around dealing with points - like KDTrees or splay-trees, but not so many dealing with objects of irregular dimensions or overlapping. dont get me wrong, all tree-structures are great - if used in the context they’re useful in :slight_smile:

rtrees are dynamic, adding in-flight is speedy. searching is fast, memory footprint is good, data doesn’t need to be known in advance.
check out http://www-db.deis.unibo.it/courses/SI-LS/papers/Gut84.pdf and https://ia700603.us.archive.org/0/items/nasa_techdoc_19970016975/19970016975.pdf

#10

There’s some relevant discussion at http://www.java-gaming.org/index.php/topic,25243.0

I used FengGUI on a project I was working on back in 2008/2009: it was a bit clunky, but with some theming and a few bugfixes I supplied I was happy with it. But I was using JOGL rather than Slick, and I don’t know how good the integration is; and it’s a dead project. (Or “stable” - it’s a question of perspective!)

#11

Shameless self plug: See scene2d.ui. See Spine for what you can do with it.

#12

Making GUI components is incredibly hard. Next time I do a project with a GUI I’ll try to use someone else’s code and save time.

I haven’t used libgdx’s scene2d.ui (https://github.com/libgdx/libgdx/wiki/Scene2d.ui) or TWL (http://twl.l33tlabs.org/) but I’ve heard they’re both very good.

Another which was good but has since been abandoned is pulpcore (https://code.google.com/p/pulpcore/).
It’s no longer maintained but has some good GUI component code that you could pilfer.

All of these projects are generously licensed as either apache 2 (libgdx) or BSD (TWL and pulpcore).

Last time I made a semi-complex GUI rendered in java2D I had to use Swing. But swing and javafx force you to use their own threading model. Everything must be done on the event dispatch thread rather than your game loop thread, which is quite irritating.

#13

EDT is good and bad - for us it’s a bit of blocker when thinking about L’n’F backed by opengl.

#14

I can’t really see anything good about the EDT. I don’t see why painting, logic and event processing should be restricted to the same thread. It seems like it wasn’t thought out very well by the Sun swing engineers. I remember when Java 1.4 was being released and the ‘do everything on the EDT’ rule was being promoted by Sun engineers, which was presented as a new best practice despite the fact that Swing had been around for years before and even the sun java tutorials at the time were calling Swing object code on non-EDT threads.

I persevered and used Swing in my own game loop thread anyway. But to my horror, some swing components trigger events in their own code which are processed on the EDT and then painting and logic threading problems arise between my game loop thread and the EDT.

#15

I second this. I’ve written a simple panel library in OpenGL for use with my own game and probably sunk about 2 months of work into it. It includes relative position of sub-components as well as an event dispatch and handling model.

It’s at a point where it does the trick for my game and I can avoid unmanageable spaghetti code but I’d guess it probably only has about 10% of the functionality of some of the available GUI libraries such as Nifty or TWL.

It was 2 months of hard work and a lot of bug fixing and refactoring. I don’t regret doing it because I learned a lot and it satisfies some of my specific requirements that I couldn’t find elsewhere.

Tread carefully.

#16

You’ll understand one day, probably when you start really understanding threading…

Cas :slight_smile:

#17

[quote=“CommanderKeith,post:14,topic:53555”]
This is a pretty presumptuous statement. Can you name any other thread-safe gui libraries?

Recommended reading: https://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

#18

Indeed, I thought that many (most?) of the “popular” UI toolkits are single threaded - Win32, Android, etc. Looking it up though I can’t tell about OS X or whatever rendering pipelines are popular for LInux these days. I’d also be interested in whether the new, cool ways of creating Windows desktop apps all still boil down to (custom-drawn) win32 stuff or if things are different these days.

#19

[quote=“KevinWorkman,post:17,topic:53555”]

Thanks for the link. Most widely used GUI libraries are ‘heavyweight’ since they use the operating system components rather than Swing which is lightweight, and has the opportunity to do things with more flexibility.

I like this quote at the end:

This is my major gripe with Swing. Swing takes sole control of the operating system (OS) event queue in its event dispatch thread (EDT), forcing us to do all of our work on the EDT or making us do messy invokeAndWait’s all the time.
I can’t see why the Swing engineers couldn’t:

  • Expose a hook to let us see the OS event queue in our game loop thread so we can take the events we want to consume and make game logic updates

  • Call an update method on the Swing components with any relevant events for them given as an argument which would happen in our game loop thread,

  • Call paint on the Swing components from our game loop thread and repeat.

That way Swing components could be used in a ‘direct-rendering’ game loop thread, rather than the current requirement where everything to do with them must be done on the EDT.

Don’t be patronising. I understand threads reasonably well.

#20

Swing as a whole is a light weight framework that is platform independent but at its core it still extends AWT (JComponent extends the AWT container), this is its hook in to the OS to get screen graphics and user interface events of the operating system which it then translates to an OS agnostic set of events for it to use (it therefore manages its own event queue on top of the OS event queue). It also does this translation on its own thread which is why you need those invokeLater commands to run anything on the underlying event queue thread. AWT was born when Java was born and is a very old horrible piece of technology.

JavaFX should fix a lot of the AWT issues, it doesn’t run the event processing on its own thread, it instead does this in the same thread that the application is run on (JavaFX Application Thread). It also hooks in to the native OS event queue rather than maintaining its own version of the event queue. JavaFX also has a separate rendering thread (Prism render thread) to the main application thread (which helps you use multi threaded systems better for rendering). Lots of good things in JavaFX but its big disadvantage is it will need a different native build for every OS it runs on and it currently doesn’t run on all OS’s