Alternatives to Swing

[fletchergames]

Swing doesn't seem as slow to me as some say it is.  However, there is at least one issue that could be faster: Swing has its own double buffering.  Shutting it off causes flicker even when I use a BufferStrategy.  I certainly don't need to double buffer twice.

The obvious alternative is the AWT.  The problem I have with the AWT is that it has only a tiny percentage of the features that Swing does.

One issue that I have with both AWT and Swing is the AWT Event Dispatch Thread.  Now that I know a bit about Swing, it's not that big of a deal, but it's still annoying.  I would rather call a method like "checkForKeyboardInput" than have AWT's passive input-checking.  This seems to be a common preference among game programmers.  I would rather not have the AWT Event Dispatch Thread and have everything included in my main loop with a few simple method calls.  Then I could use multithreading as needed and have it in my own control.

There's SWT, but that doesn't seem to be able to use full-screen exclusive mode.  It also isn't that much different from Swing.  Though it's better in some ways, it's also worse in others.

I've heard of various game programming libraries.  Slick seems to be the most programmer friendly.  Jogl and LWGL are very low level libraries that serve the same purpose.  Do any of these libraries (or others) include any alternative gui?

What is everyone else here using?  Though I can't change for the project I'm almost done with or the project that I'm going to revisit briefly, I may change we start our next new project.

[Riven]

I think double-doublebuffering is the least of your problems. The last 'blit' of a big buffer to another big buffer should be 'fast enough' in most cases.

About the input-handling: I remember kevin glass wrote an input-framework that could be backed by quite a few implementations, like AWT/Swing, JInput and LWJGL. The front-end had methods like isKeyDown(...) and could iterate over the (queued) events.

I bet you'll find it somewhere on cokeandcode or newdawnsoftware, otherwise google might find it, or kevin himself might point you in the right direction!

[Linuxhippy]

I wrote a quite large project using LwVCL

Games published by our own members! Check 'em out!

[broumbroum]

hi!
I've been developing under Java2 for a while with AWT/Swing libs to make a small 2Dimensional game framework, LJGWL-like but on my own.
It is seemly important to use DBffr' for any real-time Graphics application, if you intend to get an user.friendly interface.

So I also faced the EDT issues about refresh speed, both with AWT and Swing. Therefore I looked for another way to render components, and that is, JCSP which involves USA students in the project. JCSP for Java communicating seuential processes renders Java components throughout an integrated Channels-Processes network that make the Components Active.

You can find some piece of my work-in-progress at souceforge.net listed below. I'm about to get the graphics rendering active. And also at JCSP they're gonna get out of the Swing implementation of their project.
  

[fletchergames]

I've written my own "GameKeyListener" with methods like isKeyPressed, wasKeyReleased, etc.  It's mostly the strange weirdness that happens from time-to-time that I don't like.

For instance, I added my KeyListener to every component in my game due to focusing issues.  It wouldn't be a problem if I just drew whatever I wanted onto the JFrame, but I use actual Swing components.  I request focus as necessary and make as many components as possible unfocusable, but it doesn't work well enough.

Since I'm detected key presses no matter what screen is being displayed (each "screen" is a different card in a card layout), I was detecting Escape key releases on the menu screen (the Escape key is used in the game screen to go to the menu screen).  This caused the game to freeze after returning to the game screen.  I don't know exactly why this happened, but explicitly checking for input in the menu screen (and then ignoring the input) fixed this bug.  It shouldn't have mattered because I was clearing the input when I shifted screens anyways, but it did.

That's a problem I fixed, but it was annoying.  I want the power of Swing without having to use code I don't understand.  I've learned more about Swing, but not enough to write perfect code.  It's just one of those problems we all have to deal with.

I have tried writing my own gui code in both C and Java.  I've had some limitted success, but Swing is by far better.  That's not much of a surprise as it was written by professionals.  Still, I like having complete control of my code.

LwVCL seems like an acceptable alternative to Swing.  Some items look strange when selected, but that's probably configurable.

JCSP seems to claim to magically fix the multithreading issues I was complaining about.

Both libraries seem to still use the AWT in some way.  They also both seem to have no tutorials, but they do have javadoc-created documentation.  I think it wouldn't be too hard to figure out either one of them.

It's weird, but I think what I really want is to implement most of the same features myself but in a vastly different way.  From previous experience, I know that it would probably take me years and that I would probably just find out that I like the already available ways better.

If I had a little bit more than 10 times the amount of money I have now, I could live at poverty level indefinetly from the interest alone (if I ignore inflation).  And then I could do sit down and write my own gui library.  As it is, I guess I'll take some time after my current project's done to try out some of the libraries mentioned and see which one is the best for me.

[cylab]

If you just need a GUI in your game and are not searching for a general purpose swing replacement, FengGui seems to provide a reasonable set of GUI components for OpenGL games.

[fletchergames]

FengGui looks ok, and seems to be better documented than the other options.  I've added it to my list of libraries to look at.

I think I'll have to include the full embedded JRE anyways to satisfy Sun's license, so replacing Swing completely wouldn't help me that much.