JOGL Blue Screen Of Death

OpenGL Development JOGL Development
#1

I am running a laptop that I have previously done C++ OpenGL programming on, and I was trying to make JOGL work (at first I had the same problem that William Denniss noted, but when I deleted everything and made sure I had 1.1b3 I got rid of that problem.)

I can run the JGears off Web Start (though it flashes like nothing I’ve ever seen - like it’s unbuffered or something) and I can download and run JOGL2DBasics from one of the pages I found linked from this website, but when I try to run the JGears that I downloaded with 1.1b3 I get a bluescreen of death with error message KMODE_EXCEPTION_NOT_HANDLED and other dying-computer gibberish.

I’m running Windows 2000, and apparently have an S3 Graphics Savage/IX 1014 card [IBM T-22]. I’ve never had the flashing or the blue death screen-ing problems using OpenGL with C++… my computer pretty clearly sucks, and as a hardware-ish question there may not be much ya’ll can do, but if anyone has any thoughts or ideas then I’d appreciate it.

#2

Well, so I was a little bit nervous to run other demos after the one kept killing my computer, but when I run “java demos.gears.Gears” instead of “java demos.jgears.JGears”, I don’t bluescreen and die, I just get that annoying flashyness that I got before that wasn’t present in anything I’ve done before.

So: 1) Any ideas what JGears is doing that I should (apparently) avoid at all costs?
2) Any ideas why things are flashing so horribly?

Thanks, guys.

Here’s the output from demos.gears.Gears:

CANVAS GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
GL_VENDOR: Microsoft Corporation
GL_RENDERER: GDI Generic
GL_VERSION: 1.1.0

glLoadTransposeMatrixfARB() supported: false

#3

The “GL_RENDERER: GDI Generic” part clearly shows that you got software rendering instead of hardware. This must be related to the recent changes in GLCapabilitiesChooser but since I still use an older version I can’t tell for sure.

You could try the nightly build instead of a release, maybe the bug is corrected. If it isn’t, you may have to write your own GLCapabilitiesChooser to get hardware acceleration. :frowning:

#4

Thanks a ton for pointing me in the right directon, overnhet.

I turned debugging off in DefaultCapabilitiesChooser, and it gave the this enlightening information:

Choosing window system’s recommended choice of 2
GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false, DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ]

So then I disabled listening to what the window system was telling me (commeted out the first if statement in chooseCapabilities) it spat out 37 options, two of which were hardware accelerated and 7 of which were double buffered, with an intersection of 1, and so obviously it chose that one:

Scores: [ 1048, 48, 2168, 2168, 1168, 1168, 2472, 2472, 1472, 1472, 2120, 2120, 1120, 1120, 2168, 2168, 2472, 2472, 2120, 2120, -2476, -2476, -2188, -2188, -2444, -24
44, -2728, -2728, -2440, -2440, -2696, -2696, -2892, -2892, -2604, -2604, -2876, -2876 ]
Chosen index: 1
Chosen capabilities:
GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 16, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Gree
n Accum: 0, Blue Accum: 0, Alpha Accum: 0 ]

So basically, the problem doesn’t seem to be with the DefaultCapabilitiesChooser but with my operating system giving really stupid advice. I considered that maybe launching java from Cygwin was causing this, but launcing from Command Prompt does the same thing.

What is the reasoning behind allowing the operating system to make a forced choice, and what might coax the operating system into making not-the-absolutely-stupidest-possible choice?

#5

[quote]What is the reasoning behind allowing the operating system to make a forced choice, and what might coax the operating system into making not-the-absolutely-stupidest-possible choice?
[/quote]
Dunno, but the DefaultCapabilitiesChooser is nothing more than “default” ;D If you want something that suits you needs, you’ll have to write yours. From what I’ve read, it seems quite hard to pick the right configuration for integrated graphic chipsets and “exotic” cards…

However I thought the score-based algorithm was supposed to solve most problems. Comments anyone ?

#6

[quote]From what I’ve read, it seems quite hard to pick the right configuration for integrated graphic chipsets and “exotic” cards… However I thought the score-based algorithm was supposed to solve most problems.
[/quote]
But that’s (perhaps nearly almost) exactly my point. The score-based algorithm works perfectly, picking the configuration I would, without a doubt, choose if I was choosing my own. It’s no trouble (thankfully due to the system architecture that ya’ll worked up) to write my own chooser and stick it in there - it’s more a curiosity that, while I understand the reason why you would want to have the option to specifiy a the option that “If a valid windowSystemRecommendedChoice parameter is supplied, chooses that instead of using the cross-platform code”… the cross-platform code appears to be making the right choice, but the default chooser deferrs to the (bad) windowSystemRecommendedChoice.

Where is the windowSystemRecommendedChoice being made? Maybe I’m confused because I guess I imagined the operating system making that choice, but if it’s being made somewhere in the depths of the Windows JOGL implementation I might understand this better if I knew where to find that.

#7

The DefaultGLCapabilitiesChooser’s use of the window system-recommended pixel format or visual was a recent addition in the JOGL 1.1 release. It was added for full-scene antialiasing support, where pixel format selection gets a little more complicated than before. Rather than trying to upgrade the pure-Java visual selection algorithm, we decided to try relying on the underlying window system’s choice, from ChoosePixelFormat / wglChoosePixelFormatARB / glXChooseVisual. There have been several problems reported from this change which is pretty unfortunate. I personally haven’t had time recently to try tracking all of them down, but if others are motivated to try to figure out what is happening on some of these graphics card configurations that would be great. We’ve also been thinking about changing the DefaultGLCapabilitiesChooser’s scoring algorithm based on code contributed by Mojang. See JOGL Issue 81 on java.net.

One suggestion: try turning down the requested red, green and blue bits in your GLCapabilities object to 5, 5, and 5 from 8, 8, 8 and see what happens. If this changes the behavior (and in particular makes it work) please post.

#8

Haha - alright, I’ll try playing with it this weekend after I’ve gotten past this deadline.

Also having a really weird problem wherein when I say frame.show() the program (apparently) hangs, but only most of the time, sometime the program will start just fine… I’m getting around it, quite honestly, by running my programs on a mac instead of my win2000 machine because I don’t quite have the luxury at this point of tracking down the bug myself until this project is due.

#9

Are you using the Animator class? If so, do you show your top-level frame before you start the Animator?

If so, could you hit Ctrl-Break the next time you launch your app and post the resulting stack backtraces?

#10

Aah. If I show the top level frame before starting the animator, all is right with the world. Right then.