New JOGL binaries: September 5

[kbr]

[This has also been posted in the sticky topic on JOGL release information.]

A new JOGL build has been released on September 5, 2003. Summary of the new features:

• The ARB_vertex_buffer_object extension has been exposed. A new VertexBufferObject demo (which is a port of NVidia’s vertex_array_range demo) has been added to the jogl-demos source tree and web page.

• The GLU tesselator routines are now supported thanks to Pepijn Van Eeckhoudt and Nathan Parker Burg.

• The Mac OS X port has been updated for the latest 10.3 bits. Apparently the latest Java for 10.3 is going to be released as an update (1.4.1 Update 1) for 10.2 in the near future. Once that happens, JOGL will run on 10.2.

• JOGL’s Cg support has been ported to Linux and the current Linux binaries have it built in. Requires the Cg runtime from NVidia’s web site (http://developer.nvidia.com/).

• Several bug fixes, most of which were contributed by the community. Thanks in particular to community.java.net users abies and shawnkendall for help with the ARB_vertex_buffer_object extension and user GKW for help with the GLJPanel implementation on Windows.

Please post if you find any problems with the build.

[whome]

Its hard to keep track of installed jogl version as dll files don’t have “Properties/Version” tabsheet and .jar file MANIFEST.MF does not have “implementation-version” valuepair.

[rexguo]

Good point about the lack of version info in the binaries.

JOGL should also engage GL4Java’s help to do an automatic installer like what GL4Java’s been having for years.

.rex

[swpalmer]

[quote]- The Mac OS X port has been updated for the latest 10.3 bits. Apparently the latest Java for 10.3 is going to be released as an update (1.4.1 Update 1) for 10.2 in the near future. Once that happens, JOGL will run on 10.2.
[/quote]
As of today this has been released and is available via Software Update.

Has some problems though… see my post to the Wurm Online thread

[kbr]

swpalmer: Where’s the Wurm Online thread you mention?

rexguo: At some point in the near future we will have version information for JOGL, JOAL and JInput in a consistent manner. We don’t plan on making an installer for JOGL because we anticipate all developers will have their JNLP files or similar point to the same server for installation of JOGL, as the current JOGL demos do. Manual installation of the JOGL libraries is done only by developers.

[cfmdobbie]

[quote]swpalmer: Where’s the Wurm Online thread you mention?
[/quote]
This one, I’ll wager:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Announcements;action=display;num=1058284789;start=195#205

[gregorypierce]

Wurm isn’t going to work unless Markus and company revert to OpenGL 1.3 or lower Wurm uses 1.4 and none of the Powerbooks report GL 1.4 compliance.

[gregorypierce]

[quote]swpalmer: Where’s the Wurm Online thread you mention?

rexguo: At some point in the near future we will have version information for JOGL, JOAL and JInput in a consistent manner. We don’t plan on making an installer for JOGL because we anticipate all developers will have their JNLP files or similar point to the same server for installation of JOGL, as the current JOGL demos do. Manual installation of the JOGL libraries is done only by developers.
[/quote]
GL4Java’s installer was done specifically to make GL4Java work in web browsers. If there is an extension mechanism that wil allow us to install JOGL into a JRE so that we can use JOGL and others from the web browser via the Java Plugin, that would be great also.

[swpalmer]

[quote]Wurm isn’t going to work unless Markus and company revert to OpenGL 1.3 or lower Wurm uses 1.4 and none of the Powerbooks report GL 1.4 compliance.
[/quote]
I was referring to this particular exception:

java.lang.IllegalArgumentException: Illegally formatted OpenGL version identifier: "1.3 ATI-1.2.20" 
       at net.java.games.jogl.impl.FunctionAvailabilityCache.isPartOfGLCore(Functi onAvailabilityCache.java:185) 
       at net.java.games.jogl.impl.FunctionAvailabilityCache.isFunctionAvailable(F unctionAvailabilityCache.java:79) 
       at net.java.games.jogl.impl.GLContext.isFunctionAvailable(GLContext.java:31 5) 
       at net.java.games.jogl.impl.macosx.MacOSXGLContext.isFunctionAvailable(MacO SXGLContext.java:76) 
       at net.java.games.jogl.impl.macosx.MacOSXGLImpl.isFunctionAvailable(MacOSXG LImpl.java:22391) 
       at com.wurmonline.client.gui.WorldView.initGl(WorldView.java:194) 
       at com.wurmonline.client.gui.WorldView.display(WorldView.java:886) 
       at net.java.games.jogl.impl.GLDrawableHelper.display(GLDrawableHelper.java: 74) 
       at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:194) 
       at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:192) 
       at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.invokeGL(MacOSXO nscreenGLContext.java:76) 
       at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:182) 
       at net.java.games.jogl.GLCanvas.display(GLCanvas.java:82) 
       at com.wurmonline.client.WurmAnimator$1.run(WurmAnimator.java:95) 
       at java.lang.Thread.run(Thread.java:554) 
  

…which appears at first glance that it might be an issue with the JOGL code… Unless the string in question is being improperly parsed by the Wurm code first, or Apple/ATI didn’t follow the openGL spec when they made the string.

[ckline]

This is definitely a bug in either the version-string parsing code I wrote, or ATI didn’t follow the spec. It’s a weird looking version string; I believe the string is supposed to be in the format XXX.YYY.ZZZ but this needs confirmation.

Either way, it’s fairly easy to fix; the code is pretty simple. I’d fix it myself but I don’t have the latest JOGL source installed.

-chris

[cfmdobbie]

[quote]This is definitely a bug in either the version-string parsing code I wrote, or ATI didn’t follow the spec. It’s a weird looking version string; I believe the string is supposed to be in the format XXX.YYY.ZZZ but this needs confirmation.
[/quote]
Well, I think the 1.4 spec says it should be either “major.minor vendor-specific” or “major.minor.release vendor-specific”. However, there have been drivers that omitted the space before, and I wouldn’t rely on nothing else funny going on.

I’d recommend getting numerics up to the first dot, then numerics up to the first non-numeric, and if that last character was a dot, again grab numerics up to the first non-numeric. That should be safe enough, although I’m sure something somewhere will still break it!

[swpalmer]

You can’t easily tell because of the line break, but there is a space before the vendor specific bit. I would guess it is following the spec.
“1.3 ATI-1.2.20”

[gregorypierce]

The OpenGL version is indeed following the spec (OpenGL specification section 6.1.11).

[shawnkendall]

I finally got a chance to test out the new build.
VBOs worked famously, swapped out my “hacked” version and made the appropriate changes in my engine

      static ByteBuffer zeroOffsetBuffer = BufferUtils.bufferOffset(0);
.
.
.
            if (staticGeometry)
            {
            gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, bufferV[0]);
            gl.glVertexPointer(3, GL.GL_FLOAT, 0, zeroOffsetBuffer);
            gl.glEnableClientState(GL.GL_VERTEX_ARRAY);

            if ( colorArray != null )
            {
                  gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, bufferC[0]);
                  gl.glColorPointer(3, GL.GL_FLOAT, 0, zeroOffsetBuffer);
                  gl.glEnableClientState(GL.GL_COLOR_ARRAY);
            }
            
            if ( normalArray != null )
            {
                  gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, bufferN[0]);
                  gl.glNormalPointer(GL.GL_FLOAT, 0, zeroOffsetBuffer);
                  gl.glEnableClientState(GL.GL_NORMAL_ARRAY);
            }

etc...

Unfortunately, I am getting a significant slow down with the latest build.
At first I though maybe it was from calling BufferUtils.bufferOffset(0) in ALL my glpointer calls (maybe some "new"ing), but then I replaced it with the above single static holder for all of them. No change in frame rate. My app drops from ~180fps to 130fps between the releases. In my wrappers, I made new calls to glPointer, that took INTs for the buffer offset and simply passed it on. Of course it wasn’t SAFE.

Any interesting changes that could cause this that we should know about?

On a side note, we are commiting to a chapter drop for our Java game book this week and it is supposed to be tied to these Java games tech releases. We can only make minor changes between now and the final drop in November (in theory ;)).
Perhaps I should have a voice discussion with someone free in the games group to make sure we are as forward compatible as we can be into next year…

Thanks!

[kbr]

[quote]Any interesting changes that could cause this that we should know about?
[/quote]
Not that I’m aware of. If you could try to narrow down the cause of the slowdown that would be helpful. I’d be surprised if it was due to unwrapping of the bufferOffset object down in the generated glue code (as opposed to passing down an int) but if you could see if that is the root cause by putting back in your alternative wrappers I’d appreciate it.

[quote]Perhaps I should have a voice discussion with someone free in the games group to make sure we are as forward compatible as we can be into next year…
[/quote]
We have no intention of deliberately breaking backward compatibility. The only reasons for doing so would be (a) bugs (I am aware of one with the feedback and selection mechanisms that will break some applications due to those routines becoming NIO-only), (b) essential new features (though we will always try to maintain compatibility), and © tracking of the forthcoming JSR on official OpenGL bindings for Java, which I think should be a goal of this project so that we don’t have two incompatible APIs.

[DavidYazel]

I am having some problems resolving a native link error with the sep 5th build. I am not ruling out some messup on my runtime configuration, but I haven’t found any older versions of the jogl.dll anywhere that could be causing problems.

Exception in thread “main” java.lang.UnsatisfiedLinkError: bufferOffset0
at net.java.games.jogl.util.BufferUtils.bufferOffset0(Native Method)
at net.java.games.jogl.util.BufferUtils.bufferOffset(BufferUtils.java:87
)
at com.xith3d.render.jogl.ShapeAtomPeer.(ShapeAtomPeer.java:58)
at com.xith3d.render.jogl.RenderPeerImpl.(RenderPeerImpl.java:61)
at com.xith.worldbuilder.ModelViewer.jbInit(ModelViewer.java:448)
at com.xith.worldbuilder.ModelViewer.(ModelViewer.java:157)
at com.xith.worldbuilder.ModelViewer.(ModelViewer.java:170)
at com.xith.worldbuilder.ModelViewer.getModelViewerInstance(ModelViewer.
java:957)
at com.xith.worldbuilder.ModelViewer.getModelViewerFrameInstance(ModelVi
ewer.java:964)
at com.xith.worldbuilder.ModelViewer.main(ModelViewer.java:1100)

[DavidYazel]

The DLL does seem to have it:

_Java_net_java_games_jogl_util_BufferUtils_bufferOffset0@12

But it just wont resolve it. I even moved the DLLs into the JDK bin dir, still no dice. Tried complete recompile against new jar, no change.

[DavidYazel]

Figured out the bug. You cannot access the routine until the first time you create a opengl context. It must be loaded explicitly from JOGL.

[kbr]

That’s a bug. BufferUtils should be calling NativeLibLoader.load() in its static initializer. Could you please file an issue? Thanks.

[shawnkendall]

I just made some clean-up changes to our engine, and “Wham!” up pops the BufferOffset error.
David, I second that big report… ;D