Problems on certain systems.

kevglass · July 30, 2003, 2:44pm

I’ve ported my 2D app over to JOGL. But I’m getting reports of it failing on a selection of graphics cards. Also, on my work machine I have no 3d card and had assumed software OpenGL would take over. However, I find all my textures come back as pure red…

Is there a list of problematic systems? Is this likely to be my code or are these known OpenGL problems? Could it problem with colour depth or something?

Do I need to set GLCapabilities up, or will the defaults suffice?

Going slightly insane now

Kev

tortoise · July 30, 2003, 3:10pm

I’m interested in seeing if the software GL problem is solvable too. On 4 out of 4 machines that only have software GL, all polys come up a maroonish, dark red. Maybe I should try it out on Linux with Mesa and see what happens.

divzero · July 30, 2003, 9:01pm

I have a similar problem when trying JOGL on a Laptop which has a 3D card - but it’s a pretty pathetic one. “SiS Integrated”, 32MB (shared).

Using Linux/JOGL, The Gears demo works, but none others do. My card is reported as:

GL_VENDOR: VA Linux Systems, Inc.
GL_RENDERER: Mesa GLX Indirect
GL_VERSION: 1.2 Mesa 3.4.2

Using Windows/JOGL, the gears demo will run a little faster, and the InfiniteShadowVolumes demo will also run - but no others.

Running the Xith3D demo with Linux/JOGL also fails (after modifying the shell script and uncommenting/recompiling a line of code.

Running the Infinite Shadows demo gets this from linux:

[divzero@localhost jogl-demos]$ java -Djava.library.path=/usr/java/j2sdk1.4.0/jre/lib/ext/ -cp jogl-demos.jar:jogl-demos-util.jar:jogl-demos-data.jar   demos.infiniteShadowVolumes.InfiniteShadowVolumes
net.java.games.jogl.GLException: Error making context current
        at net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:141)
        at net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:111)
        at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:162)
        at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:196)
        at net.java.games.jogl.GLCanvas.display(GLCanvas.java:91)
        at net.java.games.jogl.Animator$1.run(Animator.java:104)
        at java.lang.Thread.run(Thread.java:536)
net.java.games.jogl.GLException: Error making context current
        at net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:141)
        at net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:111)
        at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:162)
        at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:196)
        at net.java.games.jogl.GLCanvas.display(GLCanvas.java:91)
        at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:102)
        at sun.awt.RepaintArea.paint(RepaintArea.java:180)
        at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:339)
        at java.awt.Component.dispatchEventImpl(Component.java:3586)
        at java.awt.Component.dispatchEvent(Component.java:3367)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)        at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)
net.java.games.jogl.GLException: Error making context current
        at net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:141)
        at net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:111)
        at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:162)
        at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:196)
        at net.java.games.jogl.GLCanvas.display(GLCanvas.java:91)
        at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:102)
        at sun.awt.RepaintArea.paint(RepaintArea.java:180)
        at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:339)
        at java.awt.Component.dispatchEventImpl(Component.java:3586)
        at java.awt.Component.dispatchEvent(Component.java:3367)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)        at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

Does this just mean my card is crap? Do I have any hope of getting linux drivers or should I just give up now? I have a PC with a better card but havn’t the chance to test it yet.

Cheers,

Will.

pepijnve · July 31, 2003, 6:28am

GL_RENDERER: Mesa GLX Indirect

This means that Mesa is running in software mode. I checked quickly in the 2.4.x kernel and it says that it has some SiS chip support. You would have to find out which chip it is exactly to be sure whether it’s suported or not. If it’s supported you’ll need to compile a kernel that has SiS support builtin or as a module (it’s called ‘Generic SiS support’) to get proper 3d hardware acceleration.

dotandcross · July 31, 2003, 12:14pm

Yes, I think we know that it is running in software mode. And getting proper 3D hardware acceleration does not actually solve the problem.

Does this mean people running Linux without 3D hardware acceleration will have proplems with JOGL? Is there like a minimun specs for JOGL?

I guess i can cut development on my laptop, tats for sure I have only 8mb of graphics ram!

tortoise · July 31, 2003, 2:10pm

[quote]Does this mean people running Linux without 3D hardware acceleration will have proplems with JOGL?
[/quote]
That restriction is not limited to just Linux. Although I wonder if this is really at the JOGL level or the OpenGL level.

Yup, dang that sucks. I so prefer to work on my laptop over my desktop. On the other hand, a new laptop might be nice…

pepijnve · July 31, 2003, 2:43pm

In an attemt to be more helpful I tried to trace what’s actually going wrong. The difference between the Gears and InfiniteShadowVolumes demo is that the shadows one tries to use a stencil buffer. If I comment the line

caps.setStencilBits(16)

out in InfiniteShadowVolumes.java, the demo runs in Mesa indirect mode. Of course then there are no visible shadows
I don’t think the microsoft opengl software implementation has stencil buffer support and apparantly neither does mesa. Maybe in a more recent version than 3.4.2.
Given these facts, it might be a good idea to have jogl detect this type of failure earlier and report the error instead of generating an exception deep in the code. I’m not sure if this is possible in the first place though.

kbr · August 1, 2003, 3:04am

It looks like this is a problem with JOGL’s pixel format selection algorithm. The DefaultGLCapabilitiesChooser defines how the library selects the window’s pixel format from the list of those available, though you can customize this by implementing the GLCapabilitiesChooser interface. glXChooseVisual and Windows’ ChoosePixelFormat have different enough semantics that it was necessary to write an algorithm to span platforms. The current algorithm was written without looking at the GLX implementation and required some modifications along the way to get all of the demos ported. If anyone wants to redo it to have closer behavior to glXChooseVisual, but to always return some valid format as ChoosePixelFormat does, please do so and make the code available. In the meantime I’ve put this on the list of things to do in the “high priority” section.

kbr · August 1, 2003, 3:09am

[quote]I don’t think the microsoft opengl software implementation has stencil buffer support and apparantly neither does mesa.
[/quote]
I’m pretty sure the MS software implementation does have stencil buffers because the demo runs on my non-hardware-accelerated, four-year-old notebook. The wall texture is missing, though I’ve seen this happen on hardware-accelerated systems as well.

[quote]Given these facts, it might be a good idea to have jogl detect this type of failure earlier and report the error instead of generating an exception deep in the code. I’m not sure if this is possible in the first place though.
[/quote]
Agreed. I’ll check in a new todo.txt later that has this as a high priority item (as mentioned above).

divzero · August 1, 2003, 3:35am

Great to hear, detecting which features to use and which features not to use is a pretty important task as then you can support both the high and low end systems and won’t get as many bug reports from end users.

Will.

kevglass · August 1, 2003, 4:26am

Ken,

I’d been meaning to ask about this. The GLCapabilitiesChooser, where would I get the array of available capabilities to pass in?

Currently, I just create by JOGL Canvas using the default constructor fro GLCapabilities(). Could this be causing my pure red textures?

Kev

kbr · August 2, 2003, 1:09am

[quote]I’d been meaning to ask about this. The GLCapabilitiesChooser, where would I get the array of available capabilities to pass in?
[/quote]
If you implement the GLCapabilitiesChooser interface and use the GLDrawableFactory method which takes a GLCapabilitiesChooser, you’ll get the ability to select the pixel format yourself.

[quote]Currently, I just create by JOGL Canvas using the default constructor fro GLCapabilities(). Could this be causing my pure red textures?
[/quote]
Probably JOGL is choosing the wrong pixel format. I saw this kind of behavior on Linux early in the X11 port. Try printing out the GLCapabilities objects that are passed in to your chooser and seeing if you can find a better fit than the one the DefaultGLCapabilitiesChooser is selecting.