Hi, I’ve got a question about usage of Swing controls in a game.
For example, if I need several buttons in main menu I have two options: to implement my own custom control and program it’s behavior or to use swing implementation with some customization.
Second way seems to be better, since I do not have to reinvent the wheel, but I see that most games use first approach. My question is: why? Are there any traps or pitfalls that I can fall into if I’ll go that way?
Actually, it is possible to implement quite nice UI with swing, still nobody does this in the game dev.
I had a look at using swing to do the UI for the last game I was developing. In the end I gave up and created my own UI. Since I don’t really need all the features that swing has and I only use simple components it took less time to build my own than figure out how to make swing do what I wanted. I’ve reused the same UI in 3 games now so it was worth the time spent developing it.
My Swing is rusty, but IIRC repaint() is unpredictable - multiple requests to repaint may be merged meaning it’s useless to try and get a consistant framerate. And it’s causing unnessessary usage of multiple threads (and all their associated problems) when only one should be needed here. Ideally you’d be using a BufferStrategy for your display to get vsync and page flipping, and Swing controls really don’t like being put on one of those.
Although you can change the appearence of Swing controls, they still won’t look good enough for a game IMHO. Remember look and feel - you can change the colours and the graphics but they’ll still feel the same way. For a game you want all sorts of animation and behaviour going on on buttons which is pretty much impossible to do with Swing controls.
For 90% of games all you actually need is buttons and static text anyway, and you could write that yourself in a few days. Only if you’re doing some kind of stat-heavy management sim would you need anything more complicated, in which case you might be able to get away with using Swing.
That’s an interesting approach which will work and is thread-safe but it is not active rendering since the rendering takes place on Swing’s EventDispatchThread (EDT) - The javax.swing.Timer fires ActionEvents which are executed on the EDT - see the docs: http://java.sun.com/javase/6/docs/api/javax/swing/Timer.html
The hype is all about getting the rendering to happen in your game loop rather than in the EDT. The approach using SwingUtilities.invokeAndWait(…) is the same as yours and Andrew Davison’s approach here- the rendering is done on the EDT so it is not done straight away.
That’s right about repaint(), you can’t use it all all for games since the painting could happen at any time (it just causes the EDT to repaint the component at its leisure), but using paintComponents() is OK if you call it from the EDT. About BufferStrategy, I’ve got it to work with Swing controls, there’s an example in the link I posted.
I often find that I want tables, lists, trees, spinners, layout managers, and lots of things that Swing has which would be a pain to build on my own.
There’s a JGO user Schabby who has built a GUI for games but it’s only for JOGL or LWJGL games - it’s called Fengui.
But I still think the way to go for java2D games is to do your game’s painting in the game loop thread and the Swing buttons etc painting in SwingUtilities.invokeAndWait(…) or by synchronizing the EDT using the methods in that link.
I got around 37 fps so far - let’s find out if I can get more/get it to work with the EDT type code…
[quote]I often find that I want tables, lists, trees, spinners, layout managers, and lots of things that Swing has which would be a pain to build on my own.
[/quote]
I fully agree - also there are lots of ways to customize the components including animation: e.g. blinking button. Building them on my own would take lots of time.
