Dear All,
I’ve just uploaded a JOGL chapter at the Killer Game Programming in Java web site http://fivedots.coe.psu.ac.th/~ad/jg/. It’s located about halfway down the page.
The chapter looks at two programming frameworks: callbacks and active rendering, and includes example code.
Comments are appreciated.
Thanks for writing this chapter. Please do not recommend to end users to install jogl.jar and the JOGL DLLs/.so’s into the JRE. Instead please encourage them to set CLASSPATH and PATH/LD_LIBRARY_PATH/DYLD_LIBRARY_PATH as in the JOGL User’s Guide. Installing JOGL directly into the JRE defeats Java Web Start and the JOGLAppletLauncher installation mechanisms. We may change this “conventional wisdom” in the future, but not right now. You should also mention that for end users no installation is necessary.
Sorry about the termination issues. I haven’t seen any problems with the Animator.stop() mechanism recently, although I think you’re right that a poorly-timed repaint by the OS could cause an exception to be thrown. If you have a test case which reproduces this reliably please file a bug.
It would be more efficient to instantiate the GLU object once, not every time you enter display().
Did you call gl.setSwapInterval(0) in your init() method? Does that change the ability or inability of certain machines to reach certain target FPS rates?
Would you consider filing an RFE with the JOGL Issue Tracker to add a flag to the FPSAnimator to optionally use fixed-rate scheduling?
In your active rendering example, I’d recommend you makeCurrent and release the context each render, or at least once every several renders. On X11 platforms the AWT lock is currently held between the makeCurrent and release calls so for example mouse input wouldn’t work in your example. We plan to change this behavior in an upcoming build.
Again, looks good and thanks for covering JOGL in your book.
Ken,
Thanks for the great comments. I’ll update the draft chapter and code next week.
As regards the GLU object in the callback version. Doesn’t making it global open up the chance of another thread using it, or of the listener thread using it when the context isn’t current?
Actually, due to GLU’s reliance on the current context, maybe it’s better to have to instantiate it from the context (GLAutoDrawable), as in version 1.1 (?).
gl.setSwapInterval(0) has no discernable effect on frame rate on my Windows test machines, and they all use different display cards.
BTW, the Jan 30th nightly build that I’m using has the utility Texture classes in two places in jogl.jar – in com.sun.opengl.utils and com.sun.opengl.util.texture. There’s a few classes in com.sun.opengl.utils, which i guess should be in com.sun.opengl.util (singular) (?). It’s nothing serious, and maybe already been fixed in a more recent build (?).
If you keep the GLU object private to the listener and only use it within the callback methods then there’s no danger.
With the JSR-231 changes to be able to fetch the current context there is no longer a strict dependence between the GLU object and any particular context. If you know what you’re doing you could actually use the GLU object with two different contexts. For this reason we didn’t artificially tie it to the GLAutoDrawable.
OK, thanks for trying it.
This was a bug in the nightly builds which has since been fixed. There should be no problems either with the just-released JSR-231 beta 3 or the current nightly on the JOGL home page.
Dear All,
I’ve updated the chapter and examples according to Ken’s comments. I’ve also upgraded to the JSR-231 beta 3 release of JOGL.
This a very good and up-to-date learning-ressource for Jogl.
Hope there will be more about JSR-231 in future.
Thanks!
The CubeGL active rendering code does not work for me on linux. I am using the latest version of the code from your website along with the latest JOGL (beta5). When I run it, sometimes I receive a blank window, and sometimes I see a single still frame (showing the cube). The message “fps: 80; period: 12 ms” is printed, but nothing else responds. Is this another manifestation of the X11 lock problem?
The other implementation (CubeGL_CB) works fine.
I am using Mandriva Linux 2006 with the latest NVidia video drivers, Java 1.5.0_06, on AMD 64. (Running 32-bit linux on the 64-bit processor.)
Thanks to Dr. Davison for sharing the fruits of his work. I’ll have to go back to the callback approach for the time being.