It's small. Really really small. You can ship 3 platforms' worth of code in well under a meg.

We use Buffers in a particularly intuitive way in keeping with the whole Buffer API. They're secure and fast.

Our methods are static. That's because they are static methods. We switched from the JOGL style instance methods because it's wrong. When static import arrives in 1.5, you'll want our babies.

It's proven! It really works! Flawlessly! We've got a "flagship" app Alien Flux wot works on Linux, Windows, and now MacOS X (albeit in alpha), and it's released! And Tribal Trouble's going to take it that bit further.

It's been in development for a good long time, constantly, and we're determined to keep it in very focused development to solve real world game problems.

We cut out a lot of cruft that's inefficient, outdated, or just Wrong In Java, saving you from the trouble of discovering this for yourself.

We're generally less bug-prone being small and focused, and when we find a bug, we fix it - fast.

It's still dead easy to port from JOGL to LWJGL and vice-versa. By no means is it a one-way ticket.

LWJGL cons:

If Elias gets run over by a bus tomorrow the Linux and Mac ports will stall for a few days whilst we find another Dane to take it over

Danish bacon is bad for pigs! The poor things are farmed in horrible batteries before being cured and sliced up and exported to the rest of the world to undercut local pork farms. Support your local farmers! Down with the Danes!

No-one really knows where Denmark is. Go on - ask an American where Denmark is, without looking at a map.

The API is much smaller than JoGL, making it easier to comprehend as a whole.

For the newbies: no AWT experience required, and less Java knowledge required in general.

Setup/initialisation code is so much less than with JoGL.

Static classes are a lot nicer than passing GL references into every single function, or storing them on every single class. LWJGL 0.6 used to work that way, thank God things changed.

Core dev team are very quick at providing fixes: most posts saying "XXX is broken" are replied to within a day with "XXX now fixed", instead of opening issues, assigning people to work on them etc. (Note: this isn't necessary a bad thing about JoGL, but it is a good thing with LWJGL)

Other cons:

No AWT integration. You can't mix your Java2D with LWJGL.

Smaller community, so fewer image/model loaders etc. Not as much example code as JoGL provides.

Haha, the docs are awful, and it's probably my fault because I've been promising to do them for so long!

I'd just like to clarify a subtlety about the AWT:

The LWJGL is independent of the AWT. They can both coexist happily. You can use the AWT to do things and then render them using LWJGL if you like - font building and glyph layout spring to mind; I'm doing just that for a realtime TV graphics system right now using LWJGL and AWT together. Just remember that there is no automatic interaction between the two - you can't paint AWT stuff with into LWJGL window, and you can't paint LWJGL stuff into AWT windows. But there's no harm in shuffling BufferedImages between the two.

The latest AF works on the G400. However, as I say to any customers who can't get their old sucky card working - if you go out and buy a GeForce or Radeon, all you have to do is tell me what you bought in the end, and I'll treat you to a free copy of Alien Flux.

Windowed mode is still officially debug mode. It behaves nicely on Windows, allowing you to minimize and drag and close the window. Linux works too but has a couple of issues with keyboard focus. Mac can't yet do windowed mode.

The Mac performs as well as the PC and Linux versions I believe. In part this is helped by the fact that most Macs capable of running it in the first place already have processors and RAM at twice the minimum specs.

If I actually get Mac customers I'm going to ringfence the money and buy a development Mac with it.

Cas, you should get the latest Mac port bundled up and post a message to mac-games-dev@lists.apple.com (you will need to sign up first). The guys on that list frequently post requests to beta test new games and it might help spread the word in the Mac community. When you have something easy for user to install (see the link I provided in the Mac Alien fluc thread - it is easy to set up a app bundle that is simple drag and drop to install) try to get Apple to host a link to it at: http://www.apple.com/games/orhttp://www.apple.com/downloads/macosx/

I've seen other shareware titles there, it's not just stuff from EA and the likes.

My gut feeling is that every Mac user that downloads the demo you will get more buyers from Mac users vs. PC. Mac users had to pay a premium to get a Mac.. so I conclude that they are less cheap ;-)

Well with regards to interacting with the window system.. it is much different from other platforms, probably due to the fancy OpenGL based UI that OS X uses. (Which is really sweet for impressing your wintel friends )Maybe in Longhorn (next generation of Windows) where I hear the desktop is DirectDraw/Direct3D based we will have some of the same headaches?

The keyboard issues are odd.. I was under the impression that 10.3 was supposed to fix a lot of that. The HID code seems a tad unpolished from what I've heard.

Using standard Swing UIs I have found that my Java apps work fine on OS X, Windows and Linux... The mess is always with the native side.

Well I have also been working quite a lot in JOGL lately but perhaps I was also thinking of switching to LWJGL to see if it really is better for games, and if you say that the porting isn't hard at all, then I might try it .. any tips on porting from JOGL to LWJGL ?

1. You no longer have to worry about getting references to some "gl" instance everywhere. Simply replace all your gl.gl* calls with GL.gl, because it's static.

2. Everything is done in the main thread. You can safely search for any code with the word "synchronized" or "Thread" in it and most likely rewrite it, single-threaded, unless it's something to do with networking.easier to get to grips with.

3. Be prepared to understand Buffers completely, and forget all about passing arrays into GL methods.

5. Running with -ea on the commandline causes the lwjgl_d.dll to be loaded which has lots of extra debugging and checking in it. In particular all GL commands automatically call glGetError() to check for errors and throw runtime OpenGLExceptions.

I mean no malice. I figued that I should present the opposing view to Cas' statements so that we understand the implications of the "pros" (i.e. a "pro" can actually be a "con").

1. Using statics (which I'm not against in the GL layer BTW) allows any class to insert GL calls onto the stack at any point. You cannot prevent an arbitrary class from calling into GL. This throws "defensive coding" out the window. Boo hoo! to all of those that can't pass a simple reference around! That "annoyance" provides you with the knowledge of exactly what classes can access GL. This simplifies debugging and maintenance. Think of it like the American HIPPA standing (it's a medical privacy law). HIPPA doesn't care about "who accessed the data", it cares about "who had the ability to access the data". The difference is subtle but very important.

2. Threads are not bad. We all need to get out of this mindset. Just because most people seriously fubar threads does not mean that we should eradicate them. Since I don't want to waste space I will refer you to:

Don't forget to call rewind() between retrievals of the value from textureIdentifier. Oh! And be prepared for cryptic VM crashes and core dumps.

I should point out that glGenTextures is even worse than I'm making it out to be: there's no number parameter. After scouring the code (as this function has no javadoc) I determined that:

1

nglGenTextures(textures.remaining(), textures, textures.position())

This means that if I wish to use a shared buffer of size n when I only want m textures, I need to explicitly set the position and limit of the buffer before I can make the call, so add two more calls to the already bloated code.

The bottom line is that more lines of code = larger possibility for bugs. The second bottom line is that you're making the trade-reability-for-performance decision for me. The developer should be provided with the ability to make that decision.

4. "GLCaps"? "GLCapabilities" too long to type? Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension? More code = more bugs.

5. The debugging is done in a separate dll? Oye! The developer does not have the ability to choose at runtime nor selectively choose which set of GL functions they want debugged. Why isn't this done in the Java layer where more control can be handed to the developer?

Now with all of this said, I stand behind the LWJGL effort 100% and I recommend it to everyone that I talk to. Those guys are doing a great job. They're handing bug reports very quickly. There are no production bugs that I have ever run into that have ever stopped me from coding.

Those are very good points, and mostly reflect a difference of opinion in the performance trade-offs the two libraries decided to make. In the interests of disagreeing, though, I have to be picky about this comment:

Which is basically the same as your array version, except with different words used. There's some familiarity advantage to using arrays, but buffers really aren't hard to get used to - really. Come to think of it, in my code I would actually write:

Of course you can wrap the code that I presented but the point is that the code has to be written, debugged and maintained. Instead of debugging and maintaining three lines of code, I'm dealing with six which are intrinsicly more complex.

Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension? More code = more bugs.

The library _does_ check for nonexistent function pointers, so the GLCaps check is not strictly nescessary, as your application will bomb out with an exception if the function pointer is NULL. However, _not_ checking your (required) extensions before using them is not good OpenGL practice anyway, so I can't see why the extra GLCaps checks (they only need to be done once per extension at startup mind you) can be avoided in a wellbehaving application.

You're right in that threads can be useful, my griefs are just that they're highly overrated, really. Many programmers (including myself once upon a time) will happily use threads for anything that smells like "multiple tasks at once", ignoring the fact that most of the time the complexity of using threads correctly outweighs the little extra performance they may give. I deliberately say 'little' here because it is well known that you can achieve thread-like execution without threads in common tasks related to games. Take OpenGL for example. Calling OpenGL from multiple threads will likely hurt performance, but using APIs like ARB_VBO cleverly ensures that both the CPU and the GPU is working at all times. Even Cas' example of networking can be solved with non-blocking NIO (most of the time).

...But I completely agree with your statement about the debug version of the libraries. It does remove some debug flexibility, but more importantly, lwjgl is about simplicity and the separate debug version simply does not fit into that goal.

So we're slowly working on a solution that removes the need for the debug version while maintaining the same level of error checks, but without introducing too much overhead per GL call. Stay tuned.

The library _does_ check for nonexistent function pointers, so the GLCaps check is not strictly nescessary, as your application will bomb out with an exception if the function pointer is NULL

This is exactly what I'm referring to. Why force the developer to make the call to GLCaps? Shouldn't the library be the one that's concerned about not throwing NPE's like they're going out of style? Having the library log some sane message is better than an NPE any day of the week!

Quote

However, _not_ checking your (required) extensions before using them is not good OpenGL practice anyway, so I can't see why the extra GLCaps checks (they only need to be done once per extension at startup mind you) can be avoided in a wellbehaving application.

Developer correct / sane / defensive coding procedures weren't in question and of course the developer should check the available extensions before using them. The root of what is in question is the need for the call. So let's look at this the other way, if the library didn't throw on an unavailable extension and instead logged the error what would the developer lose?

In response to your threads topic, I most certainly agree that calling GL from multiple threads is a recipe for disaster. Just to be clear, Cas was implying that you dump all threads (with some networking footnote) and that's what I'm calling into question. Threads can be a "good thing" if used appropriately and the link I provided shows how this may be possible. I just want to get the word out that threads aren't as bad as everyone thinks they are. Add to that the fact that multi-core processors will be quite common in the near future. Unless we start to get over our "threads are evil" hangups now, we're going to have a lot of idle processor time out there

In fact, LWJGL will not throw NPE's, but OpenGLExceptions, but this is not the point. You're saying that LWJGL should log a message, probably something along the lines of "Application tried to call nonexistent function glBlah", right?

If that's what you're saying, then no, that's simply not better than an exception, ever. I'm certainly not calling OpenGL functions because I like to see my nvidia card sweat, but because I want something drawn or a state changed. If the GL library does not support the call there's no other choice than to halt the running program, hence the nescessity of checking with GLCaps. I like bugs to scream in my face, not hide in a log file somewhere.

I don't want to side-track more interesting points with this so I'll simply say that unchecked exceptions (be it NPE's or OpenGLException's) are a developers worst nightmare and anything that you can do to eliminate them should be persued. Unchecked exceptions serve only to bite developers in the ass when their code goes into production.

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