glActiveTexture not found on Radeon 9200

OpenGL Development JOGL Development
#1

I’ve been trying my jogl app on a variety of friends’ machines and I’ve found that it don’t work too good on Radeon 9200s… As the topic title suggests, I’m getting exceptions from jogl telling me that there is no glActiveTexture. Now I thought that Radeon 9200 cards were reasonably uptodate and supported multitexturing and a model version of OpenGL. glActiveTexture () has been in the spec since 1.3 and AFAIU you can’t really do multittexturing without it.

So… can anyone confirm whether Radeon 9200 cards should or should not support glActiveTexture ()? (Is there a good site that records this sort of thing for gfx cards?) Could there be any issue with JOGL not binding correctly to the OpenGL drivers (I’m using 1.1.1)?

TIA,
Dave

#2

What do glGetString(GL_VENDOR) and glGetString(GL_VERSION) report? I would be very surprised if your card didn’t support multitexturing. My best guess is that you’re falling back to the Microsoft software OpenGL renderer (assuming you’re on Windows). What platform are you on? OS, driver version, etc.?

Have you tried the latest nightly build on the JOGL home page? I don’t think this will address this issue but we don’t support the 1.1.1 tree any more due to resource constraints. The new JSR-231 builds have been substantially rewritten and are more robust.

#3

Ouch! I’ve not been paying attention to the the latest developments in JOGL. I’m not sure I can switch over to the new version just like that - is there a migration guide from JOGL 1.1.1 to the JSR231?

My immediate problems are:

  • Different package names - thank the gods for Netbeans refactoring - still that’s a lot of files for me to change - anyone got a script driven update?
  • GLContext or GLDrawable or GLAutoDrawable? Which is the approved handle? As well as getGL () I used to rely on GLDrawable for getSize ()
  • No getGLU () in GLDrawable? - can I do a new GLU () at that point or should I cache it in my display context?
  • All method calls that used to take a Java array now seem to have an extra offset parameter. No easy refactoring here.
  • glDrawPixels () no longer takes a Java array at all??

Thanks,
Dave

#4

And I seem to have problems referencing GLUtesselator - I can see it there in the API but Netbeans and javac both baulk on it.

#5

I’m afraid not yet. The beginning of this thread is an attempt to document most of the changes.

Sorry, not yet.

Change GLDrawable to GLAutoDrawable. Everywhere you’ve used sharing of textures, etc. between contexts, do a getContext() on your GLAutoDrawable.

[quote]No getGLU () in GLDrawable? - can I do a new GLU () at that point or should I cache it in my display context?
[/quote]
Do a new GLU() at the beginning of your program and refer to it anywhere.

[quote]glDrawPixels () no longer takes a Java array at all??
[/quote]
All C functions which take void* now take a generic Buffer in the Java binding. Call e.g. ByteBuffer.wrap(myArray) to pass your data to glDrawPixels, or wrap it in a Buffer earlier in your program if you like.

#6

It was renamed GLUtessellator to fix a longstanding typo in the GLU headers. See the javadoc on the JOGL home page, which is up to date with respect to the current nightly build.

#7

Thanks for your replies, Ken!

Tessellator - doh! I’d been staring at it and not noticed the extra ‘l’. Quite right.

GLU - (FAOD) so that’s a singleton now and can be instantiated before any GL context exists (but obviously not usable until you have one). In which case would it not make sense for the class itself to provide a static method GLU.getGLU ()?

I’ve tried glGetString (GL_VENDOR) on jogl 1.1.1 and it came back null… Will report back when I’ve made the transition to JSR-231.

#8

It isn’t quite a singleton as the Java port has some state which makes it not multithread-safe. This is why it’s necessary for the application to manage its own GLU instances.

Are you sure you have an OpenGL context current at the time you’re calling glGetString()? You should be calling it from the init() method of your GLEventListener.

#9

[quote]Are you sure you have an OpenGL context current at the time you’re calling glGetString()? You should be calling it from the init() method of your GLEventListener.
[/quote]
Doh! Yes of course… I’ll report back when I get the strings from the failing card.