Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Making GUIs  (Read 24632 times)
0 Members and 1 Guest are viewing this topic.
Offline ratchet12340

Senior Newbie


Exp: 2 years



« Posted 2015-02-25 22:31:13 »

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.
Offline CopyableCougar4
« Reply #1 - Posted 2015-02-25 22:47:38 »

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 Smiley

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline ratchet12340

Senior Newbie


Exp: 2 years



« Reply #2 - Posted 2015-02-25 23:46:22 »

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?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CopyableCougar4
« Reply #3 - Posted 2015-02-26 00:20:26 »

1  
2  
3  
4  
5  
6  
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
1  
2  
3  
4  
<?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 <ui> 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.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #4 - Posted 2015-02-26 00:35:00 »

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 ?
Offline CopyableCougar4
« Reply #5 - Posted 2015-02-26 00:36:11 »

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

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline ratchet12340

Senior Newbie


Exp: 2 years



« Reply #6 - Posted 2015-02-26 00:42:38 »

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

Also, I believe you missed this question 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.

@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.
Offline CopyableCougar4
« Reply #7 - Posted 2015-02-26 00:46:27 »

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.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #8 - Posted 2015-02-26 09:22:07 »

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 Smiley

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
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #9 - Posted 2015-02-26 10:01:49 »

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?

There's some relevant discussion at http://www.java-gaming.org/topics/choosing-a-gui/25243/view

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!)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Nate

« JGO Bitwise Duke »


Medals: 167
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #10 - Posted 2015-02-27 00:22:58 »

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

Offline CommanderKeith
« Reply #11 - Posted 2015-02-27 09:49:04 »

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.

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #12 - Posted 2015-02-27 09:55:36 »

EDT is good and bad - for us it's a bit of blocker when thinking about L'n'F backed by opengl.
Offline CommanderKeith
« Reply #13 - Posted 2015-02-27 11:35:49 »

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.

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #14 - Posted 2015-02-27 16:23:21 »

Making GUI components is incredibly hard.

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.
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2015-02-27 16:49:31 »

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.
You'll understand one day, probably when you start really understanding threading...

Cas Smiley

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 272
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #16 - Posted 2015-02-27 19:08:21 »

It seems like it wasn't thought out very well by the Sun swing engineers.

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

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline BoBear2681

JGO Coder


Medals: 19



« Reply #17 - Posted 2015-02-28 00:18:47 »

This is a pretty presumptuous statement. Can you name any other thread-safe gui libraries?

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.
Offline CommanderKeith
« Reply #18 - Posted 2015-02-28 01:25:57 »

It seems like it wasn't thought out very well by the Sun swing engineers.

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

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:
Quote
"processes and monitors are duals". Well, yes, it's true.
In some sense we are using the event thread to implement
a global lock. We could invert things, and create a global
lock that is equivalent to the event queue.

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.

You'll understand one day, probably when you start really understanding threading...

Cas Smiley

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

Offline ziozio
« Reply #19 - Posted 2015-02-28 07:19:08 »

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
Offline princec

« JGO Spiffy Duke »


Medals: 982
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2015-02-28 10:56:09 »

Don't be patronising. I understand threads reasonably well.
But not well enough to understand why things are the way they are. KevinWorkman's excellent link describes what you need to know in a fairly succinct and enlightening essay.

Cas Smiley

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 272
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #21 - Posted 2015-02-28 16:33:34 »

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'm not sure what you're talking about here- the EDT is not an "OS event queue". It's a Java Thread that pumps events into Listeners. Nothing more, nothing less.

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

You can.

  • 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,

You can.

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

You can.

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.

You can.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline CommanderKeith
« Reply #22 - Posted 2015-03-01 00:05:04 »

Lol, well I appreciate your direct answers, but how would you achieve those things? I've never heard of anyone doing it, because I presume that it's impossible.

If it was possible, why does everyone choose to reinvent the wheel by making more GUI libraries rather than leveraging the existing Swing library? I know that swing uses java2d rather than opengl, but graphics2D can be over-ridden with calls to openGL so that can't be the problem.

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #23 - Posted 2015-03-01 00:37:39 »

i'm not leaving swing if dont have to. *edit* (shakes fist at lwjgl 3.x) */edit*

problem with paint-to-opengl is .. AWT is calling paint form it's thread.

we can call paint() from any thread and hope it does not explode, but when we'd try to create a look-and-feel implementation it would get us into trouble .. or tons of code, dealing with proper queueing paint -> draw-calls in the correct thread.
Offline CommanderKeith
« Reply #24 - Posted 2015-03-01 06:56:44 »

The closest thing that I could google which showed swing components being re-used, possibly in a direct rendering game, was this project:
https://code.google.com/p/swing-gl/
The problems I describe about the swing libraries being inflexible and not exposing hooks are made apparent in this statement by the swing-gl projects' authors:
Quote
Important: At the moment we use a nasty hack to make event system work: Set dispatcher field of Container class with reflection. This hack most probably won't work on non-SUN JVM's and will break in the future. However we beleive event system can also be made work with a custom Toolkit and a dummy Peer. Indeed we seek help from AWT/Swing gurus about this subject.
I think this shows that the Sun programmers did not make the Swing library with re-usability in mind, they have designed the swing library to be used on the event dispatch thread only. Which is not a bad thing for most people and probably a sensible design choice. But it's a pity for us game programmers who would like to use the swing components in a direct-rendered game, rendered in our own thread.

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 272
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #25 - Posted 2015-03-02 17:32:49 »

Lol, well I appreciate your direct answers, but how would you achieve those things? I've never heard of anyone doing it, because I presume that it's impossible.

I could get into each of them individually if you wanted, but the point is that you can turn off Swing's double-buffering and painting mechanisms and do your own active rendering on your own Thread.

However, if you think you have to be doing active threading in Swing, you either A) don't actually have to or B) should be using something like libGDX that will handle it for you anyway.

If it was possible, why does everyone choose to reinvent the wheel by making more GUI libraries rather than leveraging the existing Swing library?

Eh, that's like saying: you can make any program by using machine language, so why does everyone choose to reinvent the wheel with other languages?

Swing is great for some stuff. It's not so great for other stuff.

I think this shows that the Sun programmers did not make the Swing library with re-usability in mind, they have designed the swing library to be used on the event dispatch thread only.

Again, I think you're being pretty unfair, or at least measuring Swing against metrics that aren't really compatible with it. It honestly seems like you might not really understand how threading works, or how the EDT is supposed to work. I agree that it can be pretty confusing at first, but I think it's unfair to blame that on a lack of thought on the developers' part.

I assure you that the developers of Swing put quite a bit of thought into their design decisions- probably more thought than any of us are putting into these forum posts.

Also keep in mind that a lot of the Swing developers went on to develop Android. They ain't dummies.

But it's a pity for us game programmers who would like to use the swing components in a direct-rendered game, rendered in our own thread.

If you really need that, you can absolutely do that. But you probably don't actually need that.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline nsigma
« Reply #26 - Posted 2015-03-02 19:37:08 »

Quote
Important: At the moment we use a nasty hack to make event system work: Set dispatcher field of Container class with reflection. ... However we beleive event system can also be made work with a custom Toolkit and a dummy Peer. Indeed we seek help from AWT/Swing gurus about this subject.
I think this shows that the Sun programmers did not make the Swing library with re-usability in mind, they have designed the swing library to be used on the event dispatch thread only.

I was waiting to see what @KevenWorkman replied first, but there's probably another hacky (but less hacky than above!) way of doing this, without going as far as creating a new Toolkit - run the main game loop on the (well, an*) EDT.  The EventQueue will give you access to events which you can filter and dispatch as you like.

* Stupidest threading decision in AWT / Swing is blocking threads and pushing a new EDT / EventQueue when a modal Dialog opens!  Roll Eyes  The above suggestion would break if a Dialog opened.

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.

Which is still doing the work on the EDT - invokeAndWait() - the ideal way to make hard to find bugs - there's a reason they left it out of JavaFX!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 272
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #27 - Posted 2015-03-02 20:45:24 »

I was waiting to see what @KevenWorkman replied first, but there's probably another hacky (but less hacky than above!) way of doing this, without going as far as creating a new Toolkit - run the main game loop on the (well, an*) EDT.  The EventQueue will give you access to events which you can filter and dispatch as you like.

You can do active rendering in a relatively hack-less way by just disabling Swing's painting and using your own thread. But you're right, you'll have to use the invokeLater() to move events from the EDT to your thread- but again, most people who *think* they need to do this, really don't.

* Stupidest threading decision in AWT / Swing is blocking threads and pushing a new EDT / EventQueue when a modal Dialog opens!  Roll Eyes  The above suggestion would break if a Dialog opened.

What would be the alternative? For the entire GUI to freeze up whenever a dialog was opened? Or for no modal dialogs to be supported?

Which is still doing the work on the EDT - invokeAndWait() - the ideal way to make hard to find bugs - there's a reason they left it out of JavaFX!  Wink

JavaFX does have an EDT- they just call it the JavaFX Application Thread. And they do have an invokeLater() method, they just call it Platform.runLater()! But it's interesting that they chose not to include a runAndWait() method.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline nsigma
« Reply #28 - Posted 2015-03-02 21:30:28 »

What would be the alternative? For the entire GUI to freeze up whenever a dialog was opened? Or for no modal dialogs to be supported?

You're blurring together threads and modality.  There's no reason for dialogs not to be done using asynchronous callbacks - eg. the approach something like jQueryUI uses.  Swing is mostly event driven, so it just seems weird to me that this isn't the approach here.

JavaFX does have an EDT- they just call it the JavaFX Application Thread. And they do have an invokeLater() method, they just call it Platform.runLater()! But it's interesting that they chose not to include a runAndWait() method.

That was what I was trying to say, possibly too cryptically! Grin

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Riven
Administrator

« JGO Overlord »


Medals: 1327
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #29 - Posted 2015-03-02 21:37:24 »

Modal dialogs do not cause a new Thread to spawn. They create a new Event Queue and Event pump, right on top of the current queue/pump. Think of it as recursion. A stack of queues and pumps, where only the top of the stack is active.

When you have an uncaught exception reaching an event pump callsite, however, a new EDT will be spawned, as the active EDT is considered in a state not worthy to recover.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Pages: [1] 2
  ignore  |  Print  
 
 

 
Ecumene (149 views)
2017-09-30 02:57:34

theagentd (214 views)
2017-09-26 18:23:31

cybrmynd (300 views)
2017-08-02 12:28:51

cybrmynd (288 views)
2017-08-02 12:19:43

cybrmynd (296 views)
2017-08-02 12:18:09

Sralse (291 views)
2017-07-25 17:13:48

Archive (968 views)
2017-04-27 17:45:51

buddyBro (1094 views)
2017-04-05 03:38:00

CopyableCougar4 (1667 views)
2017-03-24 15:39:42

theagentd (1428 views)
2017-03-24 15:32:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!