JOGL port

dhdd said:

gouessej said:

I don't know but in my humble opinion, JOGL is more reliable than LWJGL, especially under Linux, it is worth using it inside JME.


I have been using jME with LWJGL under Linux for 2.5 years now and never had problems  :wink:

But it sure as hell won't hurt to have options in the future, so keep committing gouessej.

I have had some noticeable problems under Linux with an "old" graphics card supporting only OpenGL 1.3 especially when I had to test lots of games for the previous version of the Java Game Tome. Often the fullscreen mode didn't work because the programmers wanted to force a display mode that wasn't available on my machine. JOGL is not only an option, not only an option for the future, it is a serious alternative for now and for the future, this has to become more reliable inside JME (at least as reliable as LWJGL).
gouessej said:

I don't know but in my humble opinion, JOGL is more reliable than LWJGL, especially under Linux, it is worth using it inside JME.


I have been using jME with LWJGL under Linux for 2.5 years now and never had problems  :wink:

But it sure as hell won't hurt to have options in the future, so keep committing gouessej.
Often the fullscreen mode didn't work because the programmers wanted to force a display mode that wasn't available on my machine.

This sounds an issue with programming, not the graphics binding. The programmer should only use the display modes that were provided by the device display mode query.
Momoko_Fan said:

Often the fullscreen mode didn't work because the programmers wanted to force a display mode that wasn't available on my machine.

This sounds an issue with programming, not the graphics binding. The programmer should only use the display modes that were provided by the device display mode query.

The program should not completely crash when the display mode is wrong. In JOGL, nothing is done to go into exclusive fullscreen mode, you have to rely on Java and when you try to set a wrong display mode, you receive an IllegalArgumentException, it is a bit cleaner. Maybe some LWJGL didn't use org.lwjgl.util.Display.setDisplayMode correctly.
gouessej said:

The program should not completely crash when the display mode is wrong. In JOGL, nothing is done to go into exclusive fullscreen mode, you have to rely on Java and when you try to set a wrong display mode, you receive an IllegalArgumentException, it is a bit cleaner. Maybe some LWJGL didn't use org.lwjgl.util.Display.setDisplayMode correctly.


Currently (with LWJGL) you get an exception with Message "Bad Display Mode".

The following is my opinion and my opinion alone!:

gouessej stop searching for flaws in LWJGL that aren't there. I (and I think all of us) would be glad to have a JOGL-pro on board and we highly appreciate all improvements to the JOGL port, but you are tireing me out with your attempts to convince everybody to dislike JWJGL and instantaneously jump to JOGL. Instead, 'convert' us to JOGL by creating and finishing an awesome JOGL port.  :wink:

That said, I'm glad to have you on board  :)
dhdd said:

gouessej said:

The program should not completely crash when the display mode is wrong. In JOGL, nothing is done to go into exclusive fullscreen mode, you have to rely on Java and when you try to set a wrong display mode, you receive an IllegalArgumentException, it is a bit cleaner. Maybe some LWJGL didn't use org.lwjgl.util.Display.setDisplayMode correctly.


Currently (with LWJGL) you get an exception with Message "Bad Display Mode".

The following is my opinion and my opinion alone!:

gouessej stop searching for flaws in LWJGL that aren't there. I (and I think all of us) would be glad to have a JOGL-pro on board and we highly appreciate all improvements to the JOGL port, but you are tireing me out with your attempts to convince everybody to dislike JWJGL and instantaneously jump to JOGL. Instead, 'convert' us to JOGL by creating and finishing an awesome JOGL port.  :wink:

That said, I'm glad to have you on board  :)

Don't try to convince people that LWJGL is as reliable as JOGL whereas it is not the case and it is not new. Using the full-screen mode only when necessary and supported, setting carefully the display mode when display mode changes are really supported and using only the supported extensions solve most of the problems I have had with LWJGL, it is up to the programmers, not up to LWJGL, but it should not crash the machine (it crashed a machine under Microsoft Windows XP with an old VIA onboard graphics with Jake2 LWJGL version, no message, the previous bit depth and display mode not restored; I reproduced this bug under Linux 2 years ago but no more now).

I don't want to convince people to jump instantaneously to JOGL whereas I estimate the JOGL renderer inside JME is not reliable enough but I want to show what I had already understood 2 years ago: LWJGL has still some serious problems under Linux. For example, in LWJGL 2.0 RC1, sometimes there are still some rare crashes with no exception trace when toggling full-screen mode. Some Linux users (boa13.free.fr for instance) who tested Tribal Trouble said that they had to disable the native cursor handling to play correctly. Another examples here:
http://www.jmonkeyengine.com/jmeforum/index.php?action=printpage;topic=9362.0
http://www.splashground.de/~andy/tmp/hs_err_pid29121.log
Programmers have to be aware of these problems.

Finally, I will do my best, perhaps I will fail (I hope not). I I only encourage the current contributors to submit my fixes and the JME users to plan to use JOGL rather LWJGL if they have the problems I have spoken in the precedent paragraph and if Linux support is important for them.

Well since JME supports both it sounds like everyone's happy?

Thank you gouessej for working on the jogl implementation.



I think everyone needs to take a few steps back and remember our common goal. To provide the best product and experience we can. This includes the best support for both JOGL and LWJGL we can do. Comments need to be made (and received) in a constructive manner. If there are possible improvements that can be made, then they should be seriously considered.

I totally second nymons reply:



I have only used LWJGL with JME (b/c up to this point, it's the only one supported,) however, I've been using Ogl for a long time and jogl since it's inception (before that gl4java and other implementations.)



I don't know that one is better than the other.  I prefer jogl b/c in the past it's been easier to simply make one or two changes to my C/C++ or other java code and it just runs.  With LWJGL, I'd always liked the static implementation because it was closer to Ogl, however I always hated adding the GL11 or whatnot to the beginning.  With static imports that's less of an issue.  There are a few things in LWJGL that I adore (which I'd have to go back and look at my implementations for JME and GBUI to tell you exactly what), and there are things I don't like (same with jogl); that being said, I have had less problems in the past setting up my environment with JOGL b/c I came from the C/C++ Ogl coding and nehe's tutorials.  That's not so much of a big deal.



I don't think there should be any picking on one or the other, I've been waiting for jogl support for a long time -years- (cause I've been too lazy to do it and too busy to care)



I'm just happy that jogl and lwjgl are around… back before the ports I wrote my Ogl code in C/C++ then wrapped them in a dll in most cases and called it from Java… (that was back in the day to be sure.)



thx gouessej for the JOGL impl and matzon thx for the LWJGL impl and support.

standtrooper said:

thx gouessej for the JOGL impl

Don't thank me now, it is too early, you should wait that I finish to drive the JOGL renderer more reliable. I'm a bit worried. The basic test in jmetest.util with the cube is slow on my computer, only 49 FPS, and the frame rate is not stable. The frame rate becomes more stable only I ask the frame to ignore some repaints (setIgnoreRepaint(true)) and only with an AWT frame, not with Swing.

I'll pull down the code and take a look.  I'm not saying I can fix anything, but maybe I can help with something.

standtrooper said:

I'll pull down the code and take a look.  I'm not saying I can fix anything, but maybe I can help with something.

Thank you. Testing it is better than nothing.

I've run a few tests locally on two different machines (windows xp pro, windows vista) and both showed frame rates between 52 and 58 for both JOGL and LWJGL.



Is there another test you want me to run?

standtrooper said:

I've run a few tests locally on two different machines (windows xp pro, windows vista) and both showed frame rates between 52 and 58 for both JOGL and LWJGL.

Is there another test you want me to run?

The problem is that the frame rate for such a simple example should be stable. Can you modify the source code so that the frame rate is computed each second instead of each 5 seconds please? What is the graphics card used for your test? Thank you very much for your efforts.

Sure I can modify the code.  I'll let you know when I've run it.