next »

[Julien Gouesse]

Hi

I ported Xith3D to JOGL 2.0 yesterday, it wasn't difficult, I have just sent the source code by email to a French active contributor. This is only a straightforward port. If anybody requires an AWT-free canvas, then I will use NEWT too as I did in my port of Ardor3D (and I will try to do the same in my port of Java3D).

I know the JOGL renderer is no more the default renderer of Xith3D, I don't know whether some people are still using Xith3D with JOGL. Using NEWT (the native windowing toolkit of JOGL) would allow to work around the bug of the fullscreen mode in AWT under GNU Linux (particularily since KDE 4) and eases the support of Android. I remind that JOGL 2.0 contains a mature binding for OpenGL-ES too 

As JOGL 1.1.1a is no more maintained, I really encourage you to switch to JOGL 2.0 as soon as possible. I don't come often here, you can contact me on the official website of the JogAmp foundation:
http://jogamp.org/wiki/index.php/Maintainer_and_Contacts

Best regards.

[Marvin Fröhlich]

I just read that up. Sounds very interesting. If JOGL now uses an input layer better suited for games, then it would be even more interesting. Ok, we can still use JInput. But I think, Java should provide a native input binding (with an API like the JAGaToo input system ) out of the box.

Please send me your sourceforge nick. Then I can grant you dev access and you can commit the changes yourself to take the full credits. And yes, using NEWT would be desiarable.

[Julien Gouesse]

Hi

I have to replace some JARs before committing. I won't modify gluegen-rt-webstart.zip and jogl-webstart.zip. I have to modify JOAL JARs too because JOGL and JOAL must use the same version of GlueGen.

Please be aware of this important change:
JARs containing native libraries have to be put into the same directory than jogl.all.jar and gluegen-rt.jar.

Perhaps I will try to implement a sort of plugin to use NEWT in JInput but I'm already very busy.

[Julien Gouesse]

The whole source code has been committed. Some things require a small cleanup. Xith3D does not follow some important "rules" to use JOGL properly, these rules already existed with JOGL 1. I will have to modify a bit some parts, it won't change anything in the public API except the exposure of a canvas based on NEWT.

[Marvin Fröhlich]

Thank you very much. I will have a look at it soon.

I am curious. What are these rules, that Xith doesn't follow?

[Julien Gouesse]

Thank you very much. I will have a look at it soon.

I am curious. What are these rules, that Xith doesn't follow?

The GL instances should never be stored because it can be invalidated at any time, for example when the user resizes a window containing a GLJPanel or when a laptop decides to switch from its high performance GPU to a weaker one to lower its energy consumption (see Nvidia Optimus). Some "hacks" allow to get a fresh GL instance (GLAutoDrawable.getGL()) but it is better to avoid using them. You should always call GLContext.getContext().getGL(). Storing a GL instance is dangerous because a programmer can be tempted to use it when the context is not current or when this instance is invalid.

I'm not sure you support BIT_DEPTH_MULTI and REFRESH_RATE_UNKNOWN in your legacy JOGL AWT canvas. If you force 0 for some values, it will simply crash your application.

There are some tricks I used in the alpha version of TUER that have never been ported to any engine but I'm not sure that they could not cause some regressions in multi-purpose engines even though they allowed me to have a better framerate even when NEWT had not yet been created.

I have committed some code about NEWT but I don't have enough time now to modify JagaToo.

[Julien Gouesse]

Actually, I have to implement only 3 classes in JagaToo, it is not very difficult. I will try to do it tomorrow. Do I have a write access to JagaToo's SVN repository?

[Marvin Fröhlich]

I'm not sure you support BIT_DEPTH_MULTI and REFRESH_RATE_UNKNOWN in your legacy JOGL AWT canvas.

I don't know these. So I guess, we don't.

Do I have a write access to JagaToo's SVN repository?

Now you have .

[Marvin Fröhlich]

I had a look at your changes. Great job. Thanks a lot.

I have a few questions though. Isn't it (potentially) slow to get an instanceof GL2 hundreds of times during one frame instead of once per method (store in local variable)?

I don't unterstand the package and classname change. The new classes and methods seem to be fully compatible with GL(1). They just carry the 2-postfix. Why is that? Why didn't you simply improve the GL classes?

[Julien Gouesse]

I had a look at your changes. Great job. Thanks a lot.

You're welcome. Xith3D could not go on using an obsolete version of JOGL.

I have a few questions though. Isn't it (potentially) slow to get an instanceof GL2 hundreds of times during one frame instead of once per method (store in local variable)?

No it is not slower as a GL2 instance is a GL instance (but a GL instance is not necessarily a GL2 instance).

As a first step, I don't store GL2 instances into a local variable, I start doing it after ES2 isolation. Keep in mind that JOGL 2.0 supports both OpenGL and OpenGL ES. When I separate which parts of the code requires GL2ES1 and which parts of the code will rather use GL2ES2, I can use local variables.

I don't unterstand the package and classname change. The new classes and methods seem to be fully compatible with GL(1). They just carry the 2-postfix. Why is that? Why didn't you simply improve the GL classes?

Profiles have been introduced in OpenGL quite recently, they were not supported in JOGL 1. GL instance for Backward compatible profiles are called GL*bc (GL3bc, GL4bc) whereas other don't have the suffix "bc". Mickael Bien explained that here:
http://michael-bien.com/mbien/category/3D+Graphics

GL contains only the common stuff. Best regards.

[Marvin Fröhlich]

No it is not slower as a GL2 instance is a GL instance (but a GL instance is not necessarily a GL2 instance).

I am not sure, if I expressed this correctly. I meant, whether a is slower than b:
a:

Code:

gl.getGL2().bla();
gl.getGL2().blub();
gl.getGL2().foo();
gl.getGL2().bar();
gl.getGL2().lala();
(and more of them)

b:

Code:

GL2 gl2 = gl.getGL2();
gl2.bla();
gl2.blub();
gl2.foo();
gl2.bar();
gl2.lala();
(and more of them)

[Julien Gouesse]

a is not slower than b and I will use b when I decide whether I can implement ES2 isolation or just clean up the code and leaves it as is.

[Marvin Fröhlich]

ok, thanks

[Julien Gouesse]

ok, thanks

You're welcome. I'll give another try to the NEWT part of JagaToo Monday. I will probably postpone the implmentation of JInput <-> NEWT interoperability.

[Julien Gouesse]

Hi

I've just committed a part of NEWT support for JagaToo. I'm a bit ill; therefore, I will try to finish this implementation as soon as I feel better.