Moving from Gl4java to Jogl

OpenGL Development JOGL Development
#1

With Gl4java I’ve done some mini OpenGL apps. Now I’d like to move to Jogl. The short note http://jogl.dev.java.net/source/browse/jogl/doc/differences-from-gl4java.txt is helpful, but there a few problems I don’t understand.
[*]“No more GLAnimCanvas/GLAnimJPanel variants. To perform animation, attach an Animator to a GLDrawable.”
Ok, that’s clear. However, with Gl4java’s GLAnimCanvas one could do:

GLAnimCanvas canv = GLDrawableFactory.getFactory().createGLAnimCanvas(...);
canv.setUseRepaint(false);
canv.setAnimateFps(25);

When, for example, 25 frames per second did do the job.
Is such fine tuning also possible with Jogl? Or does Jogl’s Animator just call diplay() as often as possible? (Which is ok for most model-view-controller-games.)
[*]“GLContext is no longer exposed in the public API.”
Ok, no problem, expect: at the end of the display() methode in Gl4java one swaped the double buffer via:

GLContext mycont;
mycont.gljSwap();

How do you do this in Jogl?
Also, on this topic: when in Jogl I issue these lines:

GLCapabilities kap = new GLCapabilities();
kap.setDoubleBuffered(true);
kap.setStereo(false);
GlKanvas mycanv = GLDrawableFactory.getFactory().createGLCanvas(kap);

Then does Jogl use double buffering? When mycanv is in a full-screen windows, does this mean the good old Hardware page flipping we all know and love from C(++) OpenGL? :slight_smile:

[*]“No GLEnum class. Use GL.[GL_CONSTANT_NAME].”
Whoops. Ok, this is more Java? I don’t know, I’m no expert. :slight_smile: However I liked the GLEnum class much, because it reads more OpenGL like. But so what. It’s nice to see Jogl growing. Good job, you people doing it.

Oh, so many questions. Thanks in advance.

-ric

#2

Animator triggers the swapBuffers call after display returns. This one caught me out, the docs aren’t very clear on this. Animator currently runs as fast as possible, but i guess it wouldn’t be too difficult to crowbar in a well-placed sleep() call depending on a target fps.

Double buffer is automagic i think, i don’t recall having to do anything special for it. Since the buffers already live in vRam for a GLCanvas, it’ll be good old pointer swap/page flipping :slight_smile: Probably doesn’t apply to the Swing canvas though.

#3

[quote]Animator triggers the swapBuffers call after display returns. This one caught me out, the docs aren’t very clear on this.
[/quote]
Yes, me too. :slight_smile: But indeed that makes sense. Well then, no more manually Glu.SwapBuffers - that’s ok.

[quote]Animator currently runs as fast as possible,
[/quote]
That makes sense, too.

[quote]but i guess it wouldn’t be too difficult to crowbar in a well-placed sleep() call depending on a target fps.
[/quote]
Would be a nice-to-have feature in the future.

[quote]Double buffer is automagic i think, i don’t recall having to do anything special for it. Since the buffers already live in vRam for a GLCanvas, it’ll be good old pointer swap/page flipping :slight_smile: Probably doesn’t apply to the Swing canvas though.
[/quote]
Sounds great!
Many thanks for your answer.

#4

Double buffer is enabled by default. According to
http://jogl.dev.java.net/unbranded-source/browse/checkout/jogl/doc/userguide/index.html?rev=1.2

"A GLCapabilities object specifies the OpenGL parameters for a newly-created widget, such as the color, alpha, z-buffer and accumulation buffer bit depths and whether the widget is double-buffered. The default capabilities are loosely specified but provide for truecolor RGB, a reasonably large depth buffer, double-buffered, with no alpha, stencil, or accumulation buffers. "