LWJGL vs Jogl

[Vorax]

First, I am not on one side or the other. I just use what works. I started my project with the one I saw the most demos for, JOGL, but will probably add LWJGL support later on.

[quote]Also:

• LWJGL is miles ahead in terms of reliability and compatibility. I couldn’t seriously expect any professional game to be satisfied with the current reliability of Jogl.
  [/quote]
  I have found JOGL to be very stable and have had no issues in this regard. The only problems I have ever really seen in running open gl java were actually LWJGL, but probably because it is more prevelant out there (an even more likely it was due to bugs in the program using the API). From what I have seen both are stable enough for real use.

• Jogl’s display creation is clumsy, awkward and not nearly as flexible as LWJGL’s. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.

I have found the API pretty easy to use. In terms of core dumps, I am doing some pretty advanced stuff with it and have not seen any core dump that wasn’t my fault… though I would like to blame the API, it hasn’t been an option so far

• Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.

At first I didn’t like this, but I found it made me do better code. My project is a multi-threaded engine and not having access to the GL reference has made me avoid temptation in the engine thread… Of course if I really did want it, I could make it available any time. However, I can see why that might be annoying to some. It’s a necessary evil for multiple GL contexts. Unless you had some kind of set active context method added that had to be called before executing any GL commands…and it would make threading between contexts a bloody nightmare.

• Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there’s now a proper swapBuffers interface now?

What’s this Animator you speak of? Kidding.
It’s very easy to write your own buffer swap in JOGL. There is no trick, just shut off the autoswap and then swap at the end of a render loop.

• Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn’t suffer from these problems. Realistically it performs so slow its just not practical for anything useful.

Not sure, haven’t used it like that yet.

• Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).

I found the Jogl demos to work perfectly, maybe it wasn’t always so? Dunno. They’re great now though.

[cyberyoyo]

It’s very personal but I don’t like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That’s why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or “framework” you have to spend a lot of time learning the library and how to use it.

[tom]

[quote]It’s very personal but I don’t like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That’s why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or “framework” you have to spend a lot of time learning the library and how to use it.
[/quote]
Do you think LWJGL is a “external game library” in contrast to JOGL? Or are your comment just off topic?

[weston]

lwjgl is a lot easier to just pick up and use, there really is no learning; if you know opengl you know lwjgl. In contrast, jogl forces you to learn a bit more api specific stuff: should you use a glcanvas or a gljpanel? whats the best way to design your system so that everything that needs to have access to ogl can use the GL object? what should I put ean each of the 5 or so methods you have to implement when using the GLEventListener interface. Of course all that stuff is trivial, I’m just trying to point out that its sort of silly to say that you have to learn more to use lwjgl than jogl.

p.s. I don’t actually think your silly I’m sure it was just a misconception about what lwjgl is, which is why it would be good to have all the facts in a single location.

edit: one of these days I’ll learn to type.

[Matzon]

[quote]It’s very personal but I don’t like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That’s why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or “framework” you have to spend a lot of time learning the library and how to use it.
[/quote]
Wow, you really don’t know what LWJGL is?
There is no “learning” curve or framework you have to adhere to, to use LWJGL - you just plonk it in, and use OpenGL.

At most, you could argue that LWJGL forces you to use it’s display system - but it’s hardly difficult:

Display.create();

// and we're set to go in fullscreen 640*480

[Deadcow]

Comparison of JOGL and LWJGL seems pretty pointless to me, as their design goals are different. JOGL is supposed to be a generic and object oriented binding of opengl for java, that is, be able to handle every kind of opengl usage : games, CAD/CAO, etc. Thus, opengl context management makes sens in JOGL. On the other hand, LWJGL purpose is to provide a direct, lightweight and game oriented binding of opengl for java. Context management is of no use in games, as for AWT/Swing widget, so, what’s the point adding it ?

[Orangy_Tang]

Damnit, point-by-point argument makes reading messy :o So I’ll try and keep this direct:

• On display creation:
  Jogl’s system means you must ‘guess’ at what might or might not be avalible, which would be ok if failing actually triggered an exception. However what you really get is a core dump so you can’t do jack about it. LWJGL’s method of giving you a list of modes allows you to be much more confident of picking a working display.

Equally, I’ll bet no-one’s fixed the no-alpha-bits-in-the-framebuffer-on-linux bug yet in Jogl? That makes a whole bunch of nice rendering methods unusable.

Equally equally, take a glance at the Jogl forum and all the traffic seems to be on bugs, crashes, freezes, lockups and odd flag workarounds. Not what I’d call stable or mature.

[princec]

A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it’s not a gaming oriented API, it’s a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don’t need and left it at that.

When we get AWT rendering some eyebrows will be raised I should think.

Cas

[Orangy_Tang]

There seems to be this image that because something is a semi-official Sun API it must magically be better, more reliable and more likely to be maintained over any 3rd party library.

The grim reality is that Sun don’t care about gaming, and so don’t care about its related technologies. Being an official Sun API didn’t help Java3D any. And the GTG seem to have vanished without even the customary wisp of smoke.

[z.e.r.o]

[quote]A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it’s not a gaming oriented API, it’s a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don’t need and left it at that.

When we get AWT rendering some eyebrows will be raised I should think.

Cas
[/quote]
Well, the problem is not the halo, but the focus.

You changed lots of things in LWJGL 0.95, removing something, too, and leaving lots of unresolved issues to whom want to upgrade (like the ILU.DLL dependancies just to be able to run a LWJGL game).

This left me uncapable of using JME with LWJGL 0.95 since
I figured the fix, fix that when first appeared not even the development team wwas aware of (look at your forums).

This is not way a finger pointed in your direction but it’s an hint to fly low with the ego… Cross platform support was clumsy from time to time (like in the donation drive for mac support), if also the architecture (well, it’s not the exact term since LWJGL/JOGL are substantially wrappers) fails to remain stable and consistent there’s no way to define it professional. Hacky may be a more appropriate term.

JOGL has focus on a subset of what LWJGL does but does it trying to remain compliant with old code. It has a slower development process, but it is also more harmonic.

You’ll not see many: “I at the moment don’t need it, so I will put it on the backburner”, from the JOGL team.

Sure, Alien Flux drained some attention to the lib (but also spotlighted some issues in the deploy, like you admitted), but the aims are different.
JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.

Don’t get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I’m pretty sure the project will continue).

These are the factors that are relevant when you are developing real software (that spans years, not a couple of months) and have to make choices.

Rest assured that I’ve nothing against JME, LWJGL, JOGL or Xith3D, but if one has to rely on a mature technology for a real project he has two choices: fork an existing project, or adopt a support license. For professional needs I’d like to use AgentFX, more than rely on unsure & unstable specifications, for example. If I’ve the money I’d like to try to get my in-house one. And for that I thank you all to release the libs in the OS-friendly BSD instead of the zealotish GPL.

[oNyx]

You changed lots of things in LWJGL 0.95 […]

I would like to point out that the leading 0 is there for a reason

[princec]

S’rite, we’re still just in “alpha”. I believe Elias is just about to break everything again.

Cas

[Matzon]

[quote]You changed lots of things in LWJGL 0.95, removing something, too, and leaving lots of unresolved issues to whom want to upgrade (like the ILU.DLL dependancies just to be able to run a LWJGL game).
[/quote]
Actually, very little changed - less than 5 methods I’d wager. As for requiring ILU - thats ONLY if you use Devil. If you don’t use devil, you dont have to distribute it along.

[quote]This left me uncapable of using JME with LWJGL 0.95 since
I figured the fix, fix that when first appeared not even the development team wwas aware of (look at your forums).
[/quote]
Not being able to use jMe with 0.95 is really not an LWJGL issue!! but rather a jMe issue.

[quote]JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.
[/quote]
1 - JOGL is not a reference to anything. No JSR has been released (JSR 231 is still in progress). It might become it in the future, but it certainly isn’t right now.
2 - LWJGL is NOT a hacky tool - what a ridiculous statement. There are a lot of people using LWJGL AND delivering commercially available games!

[quote]Don’t get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I’m pretty sure the project will continue).
[/quote]
Right, and don’t claim some stupid stuff, when you’re obviously not in tune with LWJGL development. Development of LWJGL will certainly not stall, at most it would be a minor bump on the road. LWJGL isn’t a one man job.

[quote]Rest assured that I’ve nothing against JME, LWJGL, JOGL or Xith3D, but if one has to rely on a mature technology for a real project he has two choices [snip]
[/quote]
Come on, using OpenGL in java with any current binding is:
A) not mature
B) well, don’t need a B, coz the A was so f*cking great

Other than that, what they said - wait for a point release, then whine.

[kbr]

[quote]- On display creation:
Jogl’s system means you must ‘guess’ at what might or might not be avalible, which would be ok if failing actually triggered an exception. However what you really get is a core dump so you can’t do jack about it. LWJGL’s method of giving you a list of modes allows you to be much more confident of picking a working display.
[/quote]
There have certainly been bugs in JOGL’s OpenGL pixel format selection in the past, but JOGL has always, since its first release, given the end user full control over the process from through the GLCapabilitiesChooser mechanism. Where JOGL’s default selection mechanism has been found lacking, groups like Wurm Online have written their own choosers with good success from what I hear.

[quote]Equally, I’ll bet no-one’s fixed the no-alpha-bits-in-the-framebuffer-on-linux bug yet in Jogl? That makes a whole bunch of nice rendering methods unusable.
[/quote]
I haven’t heard any complaints about this recently, but I think the bug you are talking about, where the visual selection on Linux occurred too late in the AWT’s widget creation process, was fixed in 1.1 b01, released nearly a year ago.

[quote]Equally equally, take a glance at the Jogl forum and all the traffic seems to be on bugs, crashes, freezes, lockups and odd flag workarounds. Not what I’d call stable or mature.
[/quote]
The most recent build of JOGL has worked around a lot of stability issues on various vendors’ hardware, ATI in particular but Intel and NVidia as well. There is one primary flag which enables “the” workaround to force all OpenGL rendering to occur on one thread, which seems to address almost all known issues. The JOGL library has been increasing in stability as we have learned more about the intricacies of interacting with the AWT and OpenGL in a multithreaded fashion, and from what I hear from users, things are working pretty well at this point.

[kbr]

[quote]When we get AWT rendering some eyebrows will be raised I should think.
[/quote]
I will personally be very interested to see how and whether LWJGL will interoperate with the AWT. I have found it challenging to handle situations where the underlying widget is being created and destroyed asynchronously. Perhaps you and the rest of the LWJGL team will find simpler solutions than those we have discovered in JOGL.

[Orangy_Tang]

I haven’t heard any complaints about this recently, but I think the bug you are talking about, where the visual selection on Linux occurred too late in the AWT’s widget creation process, was fixed in 1.1 b01, released nearly a year ago.

Not when I tried it it wasn’t.

[kbr]

Not when I tried it it wasn’t.

Do you have a test case? If so, could you please file a bug?

[z.e.r.o]

[quote]> You changed lots of things in LWJGL 0.95 […]

I would like to point out that the leading 0 is there for a reason
[/quote]
Well, yes.
But the more you try to reach 1 the more your specifications should be consolidated.
Otherwise you’re just hacking your way out of troubles.

But I’m just saying stupid things… like someone like to think, instead of trying to get something out from constructive criticism.

[CaptainJester]

Well, yes.
But the more you try to reach 1 the more your specifications should be consolidated.
Otherwise you’re just hacking your way out of troubles.

But I’m just saying stupid things… like someone like to think, instead of trying to get something out from constructive criticism.

Just because someone makes a change to the API, does not mean it is a hack. There are reasons for it and discussions are made behind the scenes between the developers. That is also the reason for 0.95a. It is not considered a production release, so ANYTHING can change until version 1.0 comes out. That is always the risk you take when using a tool that is in alpah/beta/pre-1.0 release. If you want to have a stable release, then stick with one version for your project until you are done.

[z.e.r.o]

Matzon saying stupid to others and keeping things close & personal will not make you be smarter, just childish.

If JME is not able to run for a simple 0.01 update is your fault no matter how right you think you are.
If you’re providing a library you shall provide the less possible hassle for the developers, expecially when closing to a major release.
Have you thought of just deprecate features to give developers time to adjust their libs (giving them time till 0.99)?
You’ve just broken support for one of the best 3D library out there.
And what about the countless professional games developed around the library? It’s stupid “whining” (or it was suggesting, point of views) for an unfinished library but is intelligent (and pro) using an immature artifact to develop professional things? You’ve a quite confused opinion about how “pro” software is developed (I must assure than starting on the base of an alpha lib is not part of the equation, JOGL is not excluded from these considerations).

Before another flame will start I will leave Puppygames projects outside on purpose since Cas is involved in the development and knows where the lib will go (It’s his own middleware after all).

Anyhow, let me remember you that most of the features removed where because you cannot stand the effort to support them cross platformly (like the input devices or EAX sound) at the moment. Will we must assume “blinking” features? Better to leave them incomplete to than removing them to be added later.

BTW my first post was more broader than you undestood, there are a lot of potentially good (but unfinished) products out there. Xith3D and JME are just splendid examples of Scenegraph engines, JOGL and LWJGL are decent wrappers. My opinion about JOGL is a better RI candidate is because JOGL is just OpenGL for Java. No other stuff involved.

Nobody is saying that you all are doing bad jobs, just keep things on track and do not take unilateral decisions convinced that your choices are the choices of the community (or of the “pro”).