Migrating from JOGL 1.1.1 to JOGL2

OpenGL Development JOGL Development
#1

So I thought I’d make a start on porting my game over to JOGL2, oops! So just with switching the jars over I’m at 1000+ compilation errors. This seems mostly to do with a change with the GL interface hierarchy. Since I pass down my GL instance to many many util and drawing classes this is a bit of a pain. I kinda thought the default GL interface would still be OpenGL 1.3 or whatever JOGL was supporting before. Am I going to have to change everything to GL2 interface? or something else?

Basically, do we have an updated user guide, or some other document covering such migrations yet?

#2

I used simple sed scripts to port the jogl-demos, mostly getGL() -> getGL().getGL2():

GL2 gl = drawable.getGL().getGL2();

Yes, it’s GL2 for GL 1.5 - 3.0 desktop,
had that Q in my blog, why not 1.3 … well, I just can’t test it :slight_smile:

#3

If you call the new GL interface something different, and use GL as it was used in 1.1.1, this would make everyones migration alot simpler I would imagine. GL2 doesn’t seem to mean much anyway, esp. if it’s covering so many different versions.

#4

I don’t agree here … strongly.
GL2 covers all GL 1.3 - 3.0 features, well known as the ‘old’ desktop profile.
GL3 >= 3.1 forward compatible only - the new thing.
ES2 and ES1 …

In short … the new JOGL supports and differentiates these profiles,
as the underlying impl. does.

… see the specs …

#5

[quote]In short … the new JOGL supports and differentiates these profiles,
as the underlying impl. does.
[/quote]
I fully understand the division here between the new profiles, it’s more a naming issue than anything else :slight_smile:

I know we are now JOGL2, but it doesn’t follow that GL becomes GL2 imo. And the name GL2 doesn’t infer to me 1.3-3.0. So why not just have GLInf for example, and GL being 1.3-3.0. Makes migration easier and I think is less confusing. But since nobody else has brought this up, I guess it’s only me that finds issue with this :slight_smile:

Another example is an outsider one might assume that GL3 is actually 3.0 and upwards, rather than 3.1…

#6

Don’t worry … the naming convention fight already happened - I won :slight_smile:

GL2, because it mainly targets the merged GL2 profile plus extensions (incl. GL 3.0 extensions).
Note: GL 3.0 is available in a GL 2.0 impl. via extensions.

GL3 for GL3.1, because the whole 3.0 version was just a mistake by khronos.
Read: GL >= 3.1 headers are in GL3/gl3.h.

Good then … :slight_smile:

#7

Yet again jogl drifts further and further from being a proper opengl wrapper it seems…

So is any hardware which is only 1.1 or 1.2 unusable from Jogl2? Isn’t this somewhat daft since some current intel chips are only supporting 1.2 + extensions?

#8

You have to give more arguments for your thesis.
We actually properly support all GL profiles, and the desktop GL2 backward compatibility.
Just checked (again) the GL 1_3 add-on’s … sure you can use JOGL with 1_2 only,
just check the extension if you intend to use it against such a setup.

I doubt that Intel does not support GL 1.3, which would mean no multiple texture units …

Have fun …

#9

The Intel GMA X3100 on Mac 10.5 (Leopard) with the latest drivers only supports a core gl version of 1.2. Yes, this means no multitexturing in core, but it does support a lot of extensions (including multitexturing, FBOs and GLSL) so it’s quite copetant. From a driver POV I can see it makes sense, since they get to support only the modern extensions people actually use and non of the piddly crap that no one uses but made it into core. But it’s a pain from a developer POV since you have to use a separate set of entry points for multitexturing.

#10

[quote]Don’t worry … the naming convention fight already happened - I won
[/quote]
I guess I missed the discussion and vote on that one. As much as I dislike it, if I start my migration, is this interface reorganisation finalised now?

Also, as I mentioned, all my drawing utilities/routines called from the main display method pass down the GL instance eg:

void drawGround(GL gl, ...){...}

Now I’m wondering if I shouldn’t be passing around the GLAutoDrawable and calling

GL2 gl = drawable.getGL().getGL2();

Which seems a bit ugly, and is still exposed to future renaming issues I guess. I don’t really want to wrap GL2 or derive my own interface.

I could try and rename all the GL parameters to GL2, but that’s beyond my osx scripting skills, and far too painful to manually trawl through 64,000 lines of code.

So has anyone got a script to do this migration job? recurse a directory tree and make the changes from GL to GL2?? pretty please? I had a look at netbeans but it’s rather limited on refactoring options, Eclipse gets alot closer but still aint gonna handle this one.

All method arguments of GL will need to become GL2
All import statements fixed (looks like some package heirachy changes thrown in too?)
The getGL call is only in a couple of places easy to handle by hand.
I guess all the GL.GL_ constants have also changed to GL2.GL_ ?
what else needs to be done?

#11

@Orangy Tang:

[quote]only supports a core gl version of 1.2
[/quote]
Ok … updated it in the FAQ and the spec - thank you !
http://kenai.com/projects/jogl/pages/FAQ#What_are_the_runtime_OpenGL_Version_Requirements_?

@Cork:

[quote]is this interface reorganisation finalised now?
[/quote]
I guess we are very close after all reiterations, ie. just cleaned up the subsumed/promoted extensions within
the GL2 class (OpenGL 3.0) … and the documentation targeting all these questions …
You can see these changes in the current git, or tomorrow at
http://download.java.net/media/jogl/jogl-2.x-docs-next/

[quote]GL2 gl = drawable.getGL().getGL2();
[/quote]
That is easy to add with a shell script, we did it for jogl-demos too …

Then you also can just use:

 sed -i 's/GL\.GL_/gl.GL_/g' a_file.java

and you are done.

In the end … I guess you truly know why there is a GL2, GL3, GLES1, … etc
marking the OpenGL profile in their name.
That’s why GL cannot kept it’s OpenGL 2.0 semantics.
Sorry …

Cork, your help is very welcome, meaning if you can make a little writeup/transcript
of your own conversion, others could use that … thank you.

And last but not least, you are very welcome.

~Sven

#12

So here is some feedback on my migration:

Pulled everything back into eclipse (just much better for refactoring)
Some simple text ‘Search and Replace’ of the following:

GL. -> GL2. final GL gl -> final GL2 gl GL gl = drawable.getGL(); -> GL2 gl = drawable.getGL().getGL2();

Followed by a Reorganise Imports at project level (added the ‘all’ jars just to get going)

Next I needed to implement the following new method in all classes implementing GLEventListener:

public void dispose(final GLAutoDrawable drawable){}

I haven’t worked out if anything needs to be done within the method, or if I need to call it yet.

Next I needed to identify all the jars/natives required. Thanks to bienator for pointing to the new NetBeans plugin which helped me identify required files.

So this is what I’m currently using.

gluegen-rt.jar
jogl.all.jar
libgluegen-rt.jnilib
libjogl_gl2.jnilib
libnativewindow_awt.jnilib
libnativewindow_jvm.jnilib
libnewt.jnilib
nativewindow.all.jar
newt.all.jar

eclipse users: with JOGL 1 I always needed the natives in the root of my project for eclipse to find them for some reason. Anyway, I’m using an updated eclipse and found something that may have been there before, but maybe I overlooked. After adding the JOGL jars in build path of project properties, if you click the jars, you can specify the location of the appropriate associated natives files, which can be within a subdirectory of your project. Keeps things a bit cleaner :slight_smile:

The next thing that tripped me up was a missing GLU utility method : gluBuild2DMipmaps. I think the team is aware of this. But to make some progress I switched my custom Texture loading over to the TextureIO class. So far that’s working out quite nice with a bit less code on my side to maintain!

Now I’m down to about 10 errors in my project, some of them are related to some offscreen rendering in a utility class, so not an urgent fix, but will post some feedback if I discover anything strange in that migration step.

Finally I need to work out the new applet/webstart packaging and then I’ll be ready to demo my updated game play :slight_smile:

Overall the migration has gone fairly smoothly, mostly thanks to feedback & support from users here!

Update: The utility code also turned out to be quite easy to fix, getFactory just needed a profile:

GLDrawableFactory.getFactory(GLProfile.get(GLProfile.GL2))