2D graphical GUI

Java 2D
#1

I want to bring up a topic that comes up alot of nothing ever seems to come of it. All real games need some sort of graphical GUI, I’ve notice alot of smaller game skirt around it by having no good GUI inside the game, just using AWT/Swing and whatnot before playing. But for any larger projects this doesn’t cut it. It’s not really a simple subject, I spose thats why there really isn’t code like this just floating around in the air, but I ask everyone to share at least what their ideal game would require of a GUI system.

I would require buttons/combo boxes/textfields-areas/scrollpanes for simple components and the ability to add moveable windows that hold those components that can be modal, I also expect to be able to add a button/whatnot directly to the screen without a window.

The heirarcy would be something like AWT but as simple as you could make it class wise. component-container-window. Where say a scrollpane extends container and adds/changes what it needs. I suspect you would end up having fired events much like AWT for internal as well as external use, a scrollpane could listen for focus events on it’s components and it could say, reposition it’s viewable area if that component wasn’t visible. (say it was focused programmicly instead of a click)

I would imagine you would have to listen for AWT events off a frame and send them to some sort of GUI manager that would see if that event is used up by the components. If not, the click or key press would be meant for the game and you could store it in some kinda keys[] down/up type deal so the game could just poll. The input is always tangled in this stuff one way or another.

Any thoughts on this? Or better yet, your code or an explaination of how it works? meh.

#2

It’s funny you post this because I’m doing exactly what you’re talking about. Now, it’s nothing spectacular so far, all I have are labels, buttons (with images, in fact required images as I don’t have a standard button render aside from the text :P) and I just finished my window class.

By implementing my ClickableComponent interface, the components instantly are notified of any mouse event directed at them.

The way I did it was by using the concept of a screen. My render loop accepts a screen. The screen contains a list of components and a few other amenities like a background for instance. The screen then knows how to render itself, which is a simple loop of calling the components and telling them to render themselves. The way I handled mouse events was to have the screen setup as a listener to the frame. Anytime a mouse event is called, the screen is notified and then it determines which component on the screen should receive the event. The screen itself calls it’s own mouse notification methods (so subclasses know of the event and know which component it belongs to) and notifys the component itself of the event (so they can do internal stuff like button rollovers, window dragging, etc.). Note that once the mouse is clicked and the screen is notified, AWT and Swing are out of the picture.

Now, I’m going to say I feel like I’m re-inventing the wheel. But since I’m doing this for fun and education, no big deal. But I’m already forseeing that I’m going to need most of what AWT/Swing already does for me. Although, I must admit I really enjoy having my own components, since I can force them to render however I want with much more ease than modifying a Swing component.

I believe this is what you asked for. In fact, since I’m not really to far into it I can even send you my source. Although if you use it a mention would be nice.

Sorry for the long post. Hope this helps.

#3

I’m just glad for a decent reply. :slight_smile:

As far as feeling like your re-inventing the wheel, yes, I know EXACTLY how you feel. The truth is the exactly the opposite. Graphical GUI for java games does NOT exist on a public level IMO. I was acually hoping to see that as part of the java game profile or whatever. But bleh.

I was more or less poking for something finished, but even partially done is better then nothing for most people. I have a half implemented version of what I described, but it’s nothing I could bring myself to show anyone. I think I’m too anal. I changed my mind about a seemingly small issue and I’m basically going to have to rework it, not nessecarily throw anything away, but move it around. A structure change is what prompted my post. I wanted to see how other people structured theirs.

Up to you on that one.

#4

has anyone tried building a custom swing look&feel implementation? It looks like nasty work, but at least you’ll get to keep all the event handling & controls swing provides.

#5

I was working on something similar to what Darkwing describes last year.

Check out this book: Java 2 Game Programming by Thomas Petchel, Premier Press
Chapter 12 Creating Custom Visual Controls 70 pages

The chapter even starts with answering the question: “Why reinvent the wheel” :slight_smile:
covers:
Component
Label
Button
RadioButton
Container
Panel
Menu

#6

I’m pretty sure mangled awt/swing components wont entirely work for me entirely anyways.

I will peek at that book if I ever drop into a bookstore but I remember when that came out and it got tore up on amazon.com pretty badly. Still, there could be something useful in it.

You never know.

#7

I’m glad that the approach I took seems to be a good idea. I was doing it more from a standpoint of learning and what not (although learning is questionable, I’ve been programming Java professionally for about 3 years now :)).

Do you know if they have excerpts from that book online anywhere? I know I can probably go to my local book store but I’m lazy ;D.

#8

The classes that are created are not extended from AWT/Swing. They are completely lightweight and original.
I’ll have to look at those reviews. I’m just an entry level java programmer, so maybe the pros like to do things different.

I felt reassured that I was working on something that somebody else was already writing in a book. I had already made ImagePanel and ImageButton classes that were in AWT and heavyweight. I made the button with 4 state images able to be transparent and use the image buffer from the panel to erase it. A good learning experience. So after seeing the book I started on making totally lightweight components.

No idea where you might find excerpts, maybe Google does.

#9

The funny thing is I wouldn’t even know where to begin to create heavyweight components. All the components I’ve created rely on only one AWT class, Graphics. (Well, maybe Graphics2D here and there). So I’m pretty sure my implementation is lightweight.

And btw, I’m cheezing out on my transparency, if you use a GIF, it automatically handles transparency, so that’s how I’m doing it.

I’ll try doing a search, thanks.

#10

I heard that making lightweight components gives you genital herpies.

No really.

So long as it’s fast and interacts with my graphics and input engine the way I want, it might be what I would use. Well see.

Edit: I just made a little button to test, and it works ok. I’ll have to still work a system around a custom window/modal deal and some minor code for the input engine but overall I think it will work.

I knew this forum was good for something.

#11

bedelf said: “I heard that making lightweight components gives you genital herpies. I knew this forum was good for something.”

Ok I may have taken that out of context a bit, but maybe that should be an advertising endorsment for Javagaming.org :slight_smile:

#12

Well, I’ve already made a lightweight label, button and window and so far my nether regions remain herpes free. Coincidence? I think not.

#13

The problem I see so far is modal windows, I dont think you could make a lightweight version of that i.e. just extends Container and reacts like a normal modal/nonmodal window, could you?

Seems like you would have to extend Window/Dialog for these to work properly in terms of tabbing and events going where they need to go first.

Let me know if I’m wrong.

#14

I’m not sure what the difficulty is. If you set a window to modal, then the event dispatcher can simply not dispatch your events to anything but the modal window. Sure it requires notifying your event dispatcher of the windows modality, but that shouldn’t be to tough considering we’re writing own dispatcher :).

Now, what I would do as well is simply have a stack which keeps the modal window list. Each time a modal window is displayed, pop it onto the stack. Before dispatching any events, check the top of the stack. Have a window there? Ok, dispatch to only that window otherwise proceed as normal. Once your modal window is gone, life is back to normal.

Now let’s say you have a modal window that opens another modal window (bad design IMHO). The stack simply pops the new modal window on top, giving it priority over the other modal window. Once it’s popped off, voila, we’re back to our original modal window.

Of course, one could simply say don’t implement a stack but simply a pointer as that would enforce by design the rule of only one modal window at a time.

Anyhow, that’s how I plan to implement mine.

P.S. I haven’t decided on how to implement my focus manager. Although since I have a strict listing of components, I figured that I would simply just transfer down the list. Although that might cause a problem since my render order is determined by the same list. I guess that could cause a problem if you want to render something first but have it come later in the focus chain. Oh well, I’m rambling, the point is I’m still not sure how I’m going to handle the focus stuff.

P.P.S. Upon further reflection the difficulty is in notifying the event manager when a window is shown or hidden, not upon creation. This in itself is not difficult coding wise, but it forces a decision I’m not thrilled about. The only way to do that is by implementing a window listener system, so that the main rendering loop can listen for a window being shown or hidden. As I said, that’s not difficult but it’s starting to cause a web of triggered events, which IMHO is one of the reasons why Swing is as slow as it is, everything you do ripples down to 10 to 20 events if not more. I can’t think of a better way yet, but I’ll mull over it and get back to you if I come up with a better solution.

#15

I meant I don’t want to extend Window, it’s a heavyweight. The idea is I wanted a feather-light graphical GUI system for games.

If I was going to use Window/Dialog I might as well just use their Button etc as well and just create the ones that don’t exist. Which is bleh.

Edit: I spose what I need to try to figure out is the best way (if possible) to make sure all the events get sent to a specific component no matter what.

Even if that means moving the component to the first position and making contains always return true. :stuck_out_tongue: (assuming that would acually work). But is there a way to tell AWT to just give this component everything untill I say otherwise?

#16

Doh. I think we have a misunderstanding here. My window IS lightweight. So I’m not extending anything at all.

#17

Ya I prolly didn’t read it all that well. You write novels like I do. =D

As it stands I think I’m gonna go back to what I was doing, I wasn’t “reinventing” all that much (pretty much just the window/component add/remove and initial event recieving, which was done) and my stuff was cleaner and faster.

Interesting experiment though. Still, I spose I could look at some code someday of a purely lightweight game gui built on awt component etc that would make me want to use it. But atm I’m not convinced I’m gaining anything by doing that.

#18

Hello there!

Could you give me an example of your different works. I’m a beginer in Java Gaming Programmation and I’d be pleased to see your different implementations of graphic components/event manager :D. Currently I used Swing API but I want to code my own event manager & widjets. So, first, I need to know how to code this “event manager”, including a key buffer which I could poll for being acknoledged from keyboard state, and a similar simply way of getting informed about mouse actions. Then manage these events and make a dispatcher to graphic components. What means could I count on?

Thanx for your help,

Ouh oO oOo OoOoOh!

#19

If I ever get mine releasable I might, at the very least I’ll explain how it’s works when I know that much for sure. :stuck_out_tongue: Right now it’s mired in a heavy flux of decision making and implementation. I may make a game with it before releasing, I really don’t know. Who knows what could change with practical use?

We’ll see I spose. I will post something about it if it ever gets done though, if not the code itself. No promises though, bedelves could shank me in the eye with a sharpened toothbrush in the shower tomorrow. Who knows.

#20

I’m kind of in the same boat as BedElf. I don’t really have enough yet to give out although if you really wanted to I could send my source.

However what I can tell you is that ultimately I have a hybrid. The way it works is that I have a main Frame (JFrame actually, no particular reasons why it’s a JFrame at the moment, doesn’t seem to hurt any) that by default will accept all input. This is due to the fact that it’s, well, full screen and therefore all events go to it. I have a class I called a “screen” which then listens to the Frame for events. The Screen itself then is responsible for dispatching the events based upon the location of the event.

Now, this means that I don’t have keyboard events yet. But that’s okay because they way I plan to implement them is by first catching the event, determining if it should be a global event, i.e. handled by the screen itself, or a component event, in other words handed down to a component. However, in order to do that, you unfortunately need drum roll please a Focus Manager. So yeah, it’s a pretty tall order all in all since you really do need almost everything Swing already does. But that’s already been discussed.

BTW, my Screen is an abstract class and since that’s where it handles the event dispatching you get this nice little ability to override the event dispatching in any concrete screen. Of course, that’s highly undesirable as you never know what might happen if you do that but since this is a game who knows what wacky situation may arise that calls for custom event handling.

Ok, hope this helped. If not, I’ll be glad to answer any questions and like I said, if you desperately want it I can send my source (although it only has labels, buttons and windows right now).

Have fun! And remember, implementing a full UI with Event Management is a tall order, think about how long it took to get AWT and Swing to where they are today (and see how much further they still have to go :)).

P.S. A Focus Manager can be pretty easy. If you keep your components in a Vector like I do, then traversing the focus is very easy. However, my render order is also the same. So I’m not sure how I’m going to deal with that at the moment. My current theory is that you should never need something that comes earlier in the focus chain that comes later in the render chain. I’ll find out later if I’m right. Oh yeah, and if you didn’t catch this earlier, the focus manager is needed because only the focused component should ever receive key events.