Revisiting the issue of LWJGL vs JOGL for game programming

Question

There exists the question, "Java Game Programming: JOGL vs LWJGL?" but it's not exactly what I'm looking for, and it's over a year old (in which time JOGL has gone through some changes) so I'd like to revisit this issue...

I have been studying game development with a focus on Java. I've worked on some little projects with JOGL, but lately I'm having thoughts of changing to LWJGL.

I like JOGL's exact replica of OpenGL. It's fairly easy to create a JOGL app, and it doesn't try to impose a "framework" on your code. But JOGL has recently been moved around several times (it currently resides on jogamp.org) and doesn't seem to be well-maintained by its developers. In addition, it's terribly hard to figure out exactly what version of JOGL is stable, the differences between the versions, and which one to use; this was bad before, but has become something of a really terrible situation with JogAmp, as it's not even clear exactly where to download JOGL from its new homepage.

My most recent project was a game developed for Ludum Dare, the 48-hour game programming competition. I spent at least 3 of my hours fiddling with a couple different versions of JOGL and finding a webstart version which might work on Mac, because the one I was using didn't. When I finally got it to work, it then started crashing my Windows browser (the whole time, Linux worked perfectly with either version). Long story short, it was painful trying to figure out a version of JOGL which worked cross-platform, using the official JOGL webstart files, and I ended up just shutting out Mac users. This was a very unfortunate failure which I don't consider to be my fault.

LWJGL, on the other hand, I've had very limited experience with. But in my short time using it, I really liked how it provided other handy features (like input handling); however, I found that in order to use the graphics, I had to know exactly what version of OpenGL a certain function call resided in. In JOGL, a GL2 object is able to call OpenGL 1.1 functions, because of course they are supported in OpenGL 2; but in LWJGL, the GL2 class only contains the few methods which are new to OpenGL 2. I can't keep track of which functions belong to which version, so I end up very frustrated and guessing until I get it right. I just want to use OpenGL. I was put off by this enough to stick with JOGL.

One other thing I really miss with LWJGL is the helper classes that JOGL provides; classes like TextRenderer and TextureIO greatly help with the use of JOGL, and LWJGL doesn't seem to have anything like them. I'd be in the same boat if I were using C++ and OpenGL, but I still just love those helper classes and I will really miss them with LWJGL.

So, have I covered all the issues? Are there other concerns that I should take into account when choosing between JOGL and LWJGL? How do I choose between the two?

Answer 1

Have you looked at JMonkey engine? It's an abstraction on top of JOGL/LWJGL. This is from their website:

jME (jMonkey Engine) is a high performance scene graph based graphics API. jME was built to fulfill the lack of full featured graphics engines written in Java. Using an abstraction layer, it allows any rendering system to be plugged in. Currently, both LWJGL and JOGL are supported.

From a coding point of view, you don't really have to choose one vs the other.

Answer 2

It is absolutely wrong, stop FUD, JOGL is actively maintained. The latest autobuild has been done 2 days ago, we do our best. JOGL 2.0 is still in beta. Use JOGL 1.1.1a while JOGL 2 is not stable enough as I do there: http://tuer.sourceforge.net

JOGL 2 supports OpenGL-ES, this library is used in commercial games like Wakfu (Ankama Games), in a lot of professional applications like Sculpteo and Playviz.

Answer 3

I'll second what Ricket says about JOGL. Going to http://jogamp.org/ the obvious place to find builds to download on that page is a section titled "builds". Under that is listed 4 directories:

• Webstart - Test Release
• Latest Aggregated Build
• Archived Builds (may incl. signed webstart bundles)
• Automated Builds

There is no explantion as to what each of these categories mean in terms of being a stable release. What's the significance of an "aggregated" build? Is that supposed to imply some greater degree of stability than the automated builds? What about "archived"? Does archived mean they are old and deprecated, or is there where they go once they are (presumably stable) official releases and no longer nightly builds? Similarly, there is no explantion of what the files in each directory mean (there's a little tradition for this sort of thing called a "readme"...ever hear of it, JOGL guys?)

Even given gouessej's hint to use 1.1.1a, I cannot find that. The closest I can find to something resembling that version is jogl-old-1.1.1 under archived. But there is no "a" and the "old" isn't encouraging.

It really boggles my mind that the JOGL people can be so oblivious to how this appears to a newcomer who may come to their page interested in using their library. It turns me off from the outset, because if they are this disorganized and clueless on such a simple thing, what should we expect from their code? I'm sorry if this sounds harsh, but their library could be wonderful, but if this is the gateway to it for new users, that hardly matters.

Then there is the userguide, listed on this page under Outdated and with a big red warning at the top of it "WARNING: This document has not been updated for a long time." That's great, but how about giving us a hint as to what version of JOGL is or isn't up to date with? If I managed to find this 1.1.1a, would it be up to date with that though not with 2.0? Or is it even out of date for 1.1.1a? Or on the other hand, has it been updated with 2.0 changes (and therefore wrong for 1.1.1a) but just not up to date with the latest 2.0 development? We are left to guess.

So don't blame people like Ricket for the FUD, JOGL fans, the Fear, Uncertainty, and Doubt is being created by the JOGL maintainers themselves.

Answer 4

I want to add that the missions of JOGL and LWJGL differ slightly. LWJGL is a "Game Library", and as such, they focus heavily on having OpenGL and OpenAL and input handling, and they have some other quirks like requiring hardware acceleration on Windows and using only one window. LWJGL is not a game "engine", but as a wrapper for cross-platform game functionality in Java, it does an excellent job.

The 2.6 "stable" LWJGL has been pretty reliable for me, and the native bits have worked without a hitch so far.

Edit: If you're really bothered by having to specify which version of GL you want to call a method from (GLxx.whatever), you can import all of the methods statically:

import static  org.lwjgl.opengl.GL11.*;

which will let you call the methods without specifying the package. You can import multiple GLxx like this, since the method names don't conflict. See http://lwjgl.org/wiki/index.php?title=General_FAQ