NeHe, package change and now broken stuff?

OpenGL Development JOGL Development
#1

Hi,

I first started using JOGL a few months back and now getting the latest version see that there have been some major changes, when it comes to the package naming and some of the method signatures. None of that really bothers me, since I accept that at this stage we are dealing with early-access software.

What is causing me a few headaches is trying to get the JOGL examples at nehe.gamedev.net working with the refactored API. Some of the changes seem straight forward, such as renaming GLDrawable to GLAutoDrawable, moving GLU to class variable and not getting it from GLAutoDrawable.

BTW is the correct usage: GLU glu = new GLU() or am I meant to associate with the GL instance somehow?

Others I am having to guess at, since I don’t have a strong Open GL background.

I have got lessons 1 to 3 working on my sysem. I decided to skip ahead and try lesson 8, since I wanted to see whether the transparency issue had been fixed on “MacOS X”. Everything compiled but when I run I get the following exception:


javax.media.opengl.GLException: java.nio.BufferUnderflowException
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:203)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:219)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:112)
	at net.gamedev.nehe.lesson08.GLDisplay$AnimatorTimerTask.run(GLDisplay.java:109)
	at java.util.TimerThread.mainLoop(Timer.java:432)
	at java.util.TimerThread.run(Timer.java:382)
Caused by: java.nio.BufferUnderflowException
	at java.nio.Buffer.nextGetIndex(Buffer.java:398)
	at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:204)
	at com.sun.opengl.impl.mipmap.HalveImage.halveImage_ubyte(HalveImage.java:111)
	at com.sun.opengl.impl.mipmap.BuildMipmap.gluBuild2DMipmapLevelsCore(BuildMipmap.java:367)
	at com.sun.opengl.impl.mipmap.Mipmap.gluBuild2DMipmaps(Mipmap.java:721)
	at javax.media.opengl.glu.GLU.gluBuild2DMipmapsJava(GLU.java:1535)
	at javax.media.opengl.glu.GLU.gluBuild2DMipmaps(GLU.java:1591)
	at net.gamedev.nehe.lesson08.Renderer.loadGLTextures(Renderer.java:122)
	at net.gamedev.nehe.lesson08.Renderer.init(Renderer.java:133)
	at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:71)
	at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:227)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:123)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:261)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:179)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:478)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

the line in question reads:


        glu.gluBuild2DMipmaps(GL.GL_TEXTURE_2D,
                3,
                texture.getWidth(),
                texture.getHeight(),
                GL.GL_RGB,
                GL.GL_UNSIGNED_BYTE,
                texture.getPixels());

Note before the refactoring this was working. Can anyone suggestion what the issue might be?

NOTE: MacOS X native library and jogl.jar from 2005-11-01, running on MacOS X 10.4.3

#2

[quote]BTW is the correct usage: GLU glu = new GLU() or am I meant to associate with the GL instance somehow?
[/quote]
Yes, that is now the correct usage. It automatically associates itself with the current GL context. However, in using it, it also assumes that you are making the calls to the code when the current context is valid (eg within one of the autodrawable callbacks).

#3

Sounds fair enough. Just came across this forum entry:

http://www.java-gaming.org/forums/index.php?topic=11280.0

It appears that I need to rewind the Texture buffer first. Doing so resolves the issue. Question: should this be the API’s responsibility or the the developer using the API?

Now that the code is up an running I see that the surfaces still aren’t transparent. Could someone with a bit more JOGL knowledge tell me whether it is an issue in Lesson 8 or an issue in JOGL?

#4

You should only need to rewind any buffer just after you’ve put the initial data into. No need to do this after every glFoo() call that uses it. JOGL doesn’t do anything with the position of the buffer internally.

Blending should work - we use it constantly. Which site are you getting the Java port from?

#5

Turns out that the blending is not enabled in the lesson code, which I found from reading:

http://today.java.net/pub/a/today/2004/03/18/jogl-2d-animation.html?page=last

Adding gl.glEnable ( GL.GL_BLEND ) in the init() section of the Renderer.java file corrects the issue.

#6

Blending is toggled by pressing ‘B’ in that demo. You can get help by pressing F1.
Currently the ports are for jogl (net.java.games.jogl.), which is the basis for JSR-231 RI (javax.media.opengl.), but is not the same. I’ll update the code for the JSR as soon as the spec is frozen.
BTW I’m not sure if the code you find at the nehe site is up to date. The most recent versions can be found at http://pepijn.fab4.be/nehe.

#7

I am surprised I didn’t notice that before. ‘B’ does indeed toggler the blending. My bad :frowning: