Official OpenGL 3.0 support / How dead is JOGL?

[krausest]

Now that nvidia offers official opengl 3.0 support and JOGL offers no opengl 3 support I start to wonder whether JOGL is actually as dead as it currently seems. Is there any hope that after JavaFX has been pushed out we'll see opengl 3.0 support and new nightly builds?

[gibe]

JOGL is not dead: http://www.java-gaming.org/topics/jogl-es-binding/19251/view.html.

[Riven]

OpenGL 3.0 is not that interesting anyway, as it doesn't support geometry shaders and all other promised fancy stuff... yet.

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

[bienator]

OpenGL 3.0 is not that interesting anyway, as it doesn't support geometry shaders and all other promised fancy stuff... yet.

Well it always depends what you want to do but there is already some fancy stuff in it. Async vbo updates, texture arrays and AFAIK all OpenGL3.0 ready cards support geometry shaders via extension (GF8 and later).

But i agree GL 3.1 will look cleaner since it removes the now deprecated features.

[krausest]

Thanks for your answers - at least the community seems to be alive ;-)

Good to see that there is a momentum for JOGL (even if it's seem to be focused on OpenGL ES), but still a bit disappointing that there seem to be no GL 3 features in the JOGL_2_SANDBOX branch.
I really hoped that the official binding would keep up with current versions. I think I'll switch to LWJGL, since I want to play with the GL_EXT_direct_state_access extension.

[irreversible_kev]

I have seen a few people raving about the "GL_EXT_direct_state_access" extension and I get the impression it will play a large part in the future of OpenGL. But i'm not quite sure what it acctually does....

Does it allow the API to be more object orientated & faster in some way? (I read that it will help to get rid of the "bind" concept, and help to make the API more similar to DirectX)

A "hacked" version of JOGL was posted on these forums with 3.0 support. http://www.java-gaming.org/topics/jogl-and-opengl-3/19129/msg/150960/view.html#msg150960

EDIT: Ah yes you can load a matrix without setting the matrix mode

glMatrixLoadfEXT(GL_MODELVIEW, matrix);

EDIT2:

   (27) What feedback has Id Software given on this extension?
        John Carmack:  "This should have happened a long time ago."

EDIT3:

Very interesting post at gamedev.net giving examples of the benefits of DirectStateAccess : http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243609#Post243609

[gouessej]

Thanks for your answers - at least the community seems to be alive ;-)

Good to see that there is a momentum for JOGL (even if it's seem to be focused on OpenGL ES), but still a bit disappointing that there seem to be no GL 3 features in the JOGL_2_SANDBOX branch.
I really hoped that the official binding would keep up with current versions. I think I'll switch to LWJGL, since I want to play with the GL_EXT_direct_state_access extension.

Maybe it is not a good idea to switch to LWJGL only for this feature.

[irreversible_kev]

Maybe it is not a good idea to switch to LWJGL only for this feature.

Yes, absolutely right.

We have to remember that LWJGL is extremely evil and we have to be thankful that JOGL has come to save us.

[gouessej]

We have to remember that LWJGL is extremely evil and we have to be thankful that JOGL has come to save us.

That is not why I meant, sorry. But I really wonder if it is enough to switch to LWJGL just for a particular feature. Is it really a "must-have" feature?

[krausest]

But I really wonder if it is enough to switch to LWJGL just for a particular feature. Is it really a "must-have" feature?

It depends - from a OpenGL user's view it isn't, but from a OpenGL programmer's view it is.
Anyways JOGL's promise (at least my view of it) was to be the Sun endorsed OpenGL API. That's what I'm looking for (I was sick of all the short lived OpenGL extensions C++ wrappers), but if JOGL fails to support OpenGL 3 now (though as we've seen it shouldn't be too difficult - just a bunch of extensions and maybe some initialization stuff) then I lose confidence that JOGL will support the next revisions of OpenGL in time.

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

[Riven]

As for the short lived comment, LWJGL is older than JOGL.

[princec]

Lots older.

And better, of course

Cas

[jezek2]

Personally I don't know why JOGL exists. It tries to have object oriented approach on too low level and imposes arbitrary limits that OpenGL doesn't have. LWJGL on the other hand gives you exactly the same OpenGL API as is, eg. functions are static methods and can be called at any time as long as you have OpenGL context current on current thread. Exactly as in OpenGL in native code.

This conclusion is derived from my own experience with handling OpenGL. I did several attempts until I finally found the right choice. It began as simple utility classes which worked for awhile, but then things were getting messier and messier. Ok, I did a better object oriented abstraction which exposed all the state etc. it looked cool, so I've rewritten all my apps to it (and it wasn't that straightforward sometimes) and was happy for some time... then I started realizing how messy it is and realized that it's the very bad way of doing things.

I needed something that is realiable from API view, uses modern rendering approach that is shader-centric (= same as current HW implementations). This means my new library has reversed approach, you set shader and it's inputs (uniforms, vertex data, etc.) and there is minimal set of states (eg. some fixed functionality is grouped into few classes containg more states, which can be replaced as a group). It requires Shader Model 2.0 or better. After I've again rewritten all my apps to it (which was even more painful as it diverged from original OpenGL pretty much, practically I did more a rewrite as I did also other things badly), I'm very very happy now and finally feel confident it's the right apporach. Nice object oriented, still low-level (nothing engine specific is there, just better exposing of HW) and reliable by design (just few state groups to handle and easy to reset to known default state).

My experience concludes that JOGL has stuck with the first design of mine and thus it's FAIL. You know when design of something is flawed then it's needed to move on and use better one. LWJGL does exactly what it has to do on it's level, eg. exposing just OpenGL as is.

[krausest]

Personally I don't know why JOGL exists. It tries to have object oriented approach on too low level and imposes arbitrary limits that OpenGL doesn't have.

Can you please explain what limits JOGL imposes? I don't know any GL feature that LWJGL supports and JOGL does not (except GL3 of course). And I'm the greatest fan of DebugGL (and it's the object oriented approach that makes that decorator easily possible) - if I had had that with C++ it would have saved me much frustration. Is there something like that in LWJGL?

Another question: Do you LWJGL users really know to which GL revision or extension a specific function belongs (I don't) or do you have static import blocks that you simply copy each time?

[Riven]

You are absolutely right, those are my only two 'problems' with LWJGL.

It hate to scatter glGetError all over the place to narrow down the bug.
It feels like System.out.println("1" -> "2a" -> "2b" -> "3") scattering...
and I sometimes (have to) use Google to find the class of a certain
GL extensions in LWJGL. Somebody should write a debug-version of
LWJGL that does the checks, maybe bytecode transformation...

Other than that, it rocks...

[Matzon]

You are absolutely right, those are my only two 'problems' with LWJGL.

It hate to scatter glGetError all over the place to narrow down the bug.
It feels like System.out.println("1" -> "2a" -> "2b" -> "3") scattering...

comment in <arg value="-Ageneratechecks"/> when compiling to get a debug lwjgl.jar

we dont provide this because ... well ... we dont

[Riven]

Nice one. I'm going to give it a try later.

It wouldn't be a bad idea to provide this out of the box though, in a seperate jar...


me is a lazy basterd, like the bunch of us

[gouessej]

Lots older.

And better, of course

Cas

Lol I like your objectivity.

[princec]

It has to be said I am probably one of the least objective people in that particular argument

As for DebugGL... yeuch! Nobody in the industry uses this horror. You either use a native GL interceptor or you just narrow down your problematic bits of code or you use that LWJGL debug flag (and Yes, it would be a great idea to include it with the distribution).

Cas

[Z-Knight]

sigh...I'm lurking here...damn it to heck, why can't we just get one graphics api and stick with that and make that the best it can be rather than jumping from one to another every other year!!!!!

I initially started with Java3D but then that pretty much died when Sun stopped releasing updates....yes it lives, but in my opinion it is on its last legs.  So I move to JOGL thinking this will be backed by Sun and now it seems to be dying as well?!?!!  Frack me, I don't want to go learn yet another package and convert my code to it!!!   Sorry, but JOGL sounds better than LWJGL so I'm gonna stick with it for a bit and then I'm giving up on graphics programming forever.

edit: Meant to say I moved to JOGL thinking it WOULD be back by Sun (had a "not" in there).

[gouessej]

sigh...I'm lurking here...damn it to heck, why can't we just get one graphics api and stick with that and make that the best it can be rather than jumping from one to another every other year!!!!!

I initially started with Java3D but then that pretty much died when Sun stopped releasing updates....yes it lives, but in my opinion it is on its last legs.  So I move to JOGL thinking this will not be backed by Sun and now it seems to be dying as well?!?!!  Frack me, I don't want to go learn yet another package and convert my code to it!!!   Sorry, but JOGL sounds better than LWJGL so I'm gonna stick with it for a bit and then I'm giving up on graphics programming forever.

JOGL is not dying! It is tiring to read this whereas JOGL 2.0 is going to arrive. Don't worry.

[krausest]

Now that OpenGL 3.1 is released and (beta) driver support is also already there from day one (nvidia even released a linux version!) I'm excited to see if JOGL and when lwjgl will support OpenGL 3.1 and how the removal/deprecation of functions shows up in the java api.

[kappa]

LWJGL has already added opengl 3.1 support. 

[turquoise3232]

LWJGL has already added opengl 3.1 support. 

Should have choosen LWJGL so it seems...

[gouessej]

Should have choosen LWJGL so it seems...

If you want a big black screen under some Linux machines like mine, you should have chosen LWJGL 

Watch this a bit:
http://www.java-gaming.org/topics/nightly-builds/19941/view.html

[kappa]

If you want a big black screen under some Linux machines like mine, you should have chosen LWJGL 

Watch this a bit:
http://www.java-gaming.org/topics/nightly-builds/19941/view.html

I've used LWJGL on many linux machines and never had any problems with black screens. The LWJGL developers are aware of this bug and are willing to fix it, but it seems to only be specific to your machine (since you have a very old gfx card which ATI no longer support and you are using dodgy third party drivers), with no way to reproduce it, its very difficult to fix.

LWJGL is a community project and relies on the community to support it track down bugs and fix them, we do know that it worked on your machine with older versions of LWJGL and it was a change in a recent version of LWJGL that broke it correct?

It should be a simple matter to fix if we can find out which change caused it to break on your machine, if you can help by testing to find which change to the LWJGL caused it to break on your machine maybe this issue can be fixed.

Other than that this bug effects only an insignificantly small number of machines (and most likely due to crappy drivers).

[zammbi]

Gouessej you might want to be less negative against LWJGL, your the only one who complains about it, you don't want to anger more people. What I hear JOGL can have some rare problems too. Nothing is perfect. But doing what Kapta said might help fix this and then LWJGL can be your friend too 

[gouessej]

I've used LWJGL on many linux machines and never had any problems with black screens. The LWJGL developers are aware of this bug and are willing to fix it, but it seems to only be specific to your machine (since you have a very old gfx card which ATI no longer support and you are using dodgy third party drivers), with no way to reproduce it, its very difficult to fix.

LWJGL is a community project and relies on the community to support it track down bugs and fix them, we do know that it worked on your machine with older versions of LWJGL and it was a change in a recent version of LWJGL that broke it correct?

It should be a simple matter to fix if we can find out which change caused it to break on your machine, if you can help by testing to find which change to the LWJGL caused it to break on your machine maybe this issue can be fixed.

Other than that this bug effects only an insignificantly small number of machines (and most likely due to crappy drivers).

But now it happens only with some applications, not systematically, even though they use the latest version of LWJGL 

If you don't succeed in reproducing this bug, I will have to take another look at it (when I have some time) at least to tell you exactly which change list breaks LWJGL at home. Did you try LWJGL with a Matrox Millenium G400 under Linux? I remember that it worked reliably with JOGL even with the G200 that is older.

Gouessej you might want to be less negative against LWJGL, your the only one who complains about it, you don't want to anger more people. What I hear JOGL can have some rare problems too. Nothing is perfect. But doing what Kapta said might help fix this and then LWJGL can be your friend too 

I already tried to fix this bug as it annoys me too! A final user does not make any difference between JOGL and LWJGL. If he gets a black screen when launching a Java game, it is bad for Java on the whole. I'm not the only one to complain about it. I interpret the fact that some LWJGL users come here to encourage people to use LWJGL rather than JOGL when they speak about OpenGL 3.0 and 3.1 as a provocation whereas it is difficult for me too, I have no idea of when Mr Russell will release a beta version of JOGL 2.0.

LWJGL is not my enemy if and only if bugs under Linux are treated as good as bugs under Windows.