Changes: Window support has been greatly enhanced, this includes the ability to move the window (!), along with api support for testing whether or not the user has minimized or is requesting that the window should be closed.

I have a problem when upgrading Nehe01 from Chman website to 0.5. It seems to fail on Display.getAvailableDisplayModes. I recompiled every class against 0.5 and included the good libraries on

An unexpected exception has been detected in native code outside the VM.Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x114F0529Function=Java_org_lwjgl_opengl_GLU_quadricCallback__IILjava_lang_Object_2Ljava_lang_String_2+0x4D9Library=C:\workspace\projects\unversioned\gametime\lwjgl\lwjgl-0.5\lwjgl.dll

Current Java thread: at org.lwjgl.Display.nGetAvailableDisplayModes(Native Method) at org.lwjgl.Display.getAvailableDisplayModes(Unknown Source) at Nehe01.run(Nehe01.java:113) at Nehe01.main(Nehe01.java:314)

heh - I have my installation at home, so I can only build when I get back from work... I'll send you a new version ~ 18:00 which contains some debug stuff, in the meantime try to do debug test (java -ea).

With regards to email and other non board stuff, lets take that to the personal messaging thingy also available on this board.

I guess I need to do a "proper" DisplayMode-setting loop now then? I currently can't manually find a single DisplayMode that works with that res and bitdepth that has an alpha channel. Oh, I'm still getting 0Hz refresh rates - this is expected, no?

All these modes have 0-bit stencil, naturally. I don't know what modes greater than 1024x768 will do, as I thought that was the limit of my screen! Must play later...

The problem, you may note, is that there are NO modes available that have any alpha bits. Any idea what's going on there? I was able to ask for one (and got one) under 0.4, but they fail to instantiate under 0.5. Hrm. Any thoughts?

I was about to point out that the list isn't sorted any more, but decided against it. For whatever reason it's no longer visibly in any sensible order, it means people can't rely on that fact...

No we don't, at least not on win32. win32 is still guessing the pixel format combos, as is seen by the little printf in cfmdobbie's output:

"This application requires a greater alpha depth.", which means that the mode is in the list of available modes (and should be as we're guessing it), but cannot be created, as it fails inside Display.create().

We need pixel format queries. In the meantime, have you tried both 16 and 24/32 bit color depth on your desktop, cfmdobbie?

As said display mode rutine has been changed a bit to allow multiple display devices (read: my Radeon 9700 ).Apparently, this is causing some problems - although we devs haven't had any problems with it...

Could you send a message with your email, so that I may send you a debug dll too ?

Digging in the sources showed that the test for alpha bits wasn't present in the 0.4 version. So a question remains, did alpha work correctly when using 0.4 on your laptop? If so, we need to investigate if we're not trying hard enough to create a good enough mode, or if the driver is simply lying to us. If not, then nothing has to be done about it (other than you not using alpha on the laptop:/ ). It seems unlikely that alpha support is missing on a hw opengl card though...

I'm now scamming every DisplayMode returned by getAvailableDisplayModes() and trying every single one. If a mode fails, I log it. If it suceeds, I proceed to a GL context and pull what GL thinks the display capabilities are. While executing, I get a load of these kind of messages on stdout:

Gonna have to post this message and follow up to it in a few minutes. I just ran a full test on 16-bit desktop depth, and WinME has gone kaput. The commandline window filled up with "no window handle" messages and the window control buttons don't have icons anymore but the characters 0, 2 and square. The checkboxes have turned into candles...

Okay, I'm back. That was fun. All due respect to the thousands of man hours that went into developing and testing WinME, but it's the worst piece of software I've ever had the misfortune to use. Oh, apart from my Win98SE box upstairs, that's worse. I often wonder why I have terrible problems with Windows and noone else does... although recently I showed an annoying feature to a friend whereby the active window was not the one whose button was depressed in the task bar - since I pointed it out he's noticed it too...

Anyway. Okay, the "16-bit desktop depth" run worked the second time and a cursory compare with the 32-bit run shows me they both worked and failed on the same modes. I *believe* they are the same, but this god-forsaken OS has no file compare utility.

Here is the (32-bit) output; every successful mode change is followed by a report pulled from GL:

1. Your card can't do alpha - the most unlikely option2. The driver is lying and can do alpha but doesn't report it3. We are doing something wrong when selecting modes

to rule out 1. you have to find a demo doing alpha blending - maybe a nehe dome in C++? Ruling out the other is not that easy - if the native demo can do alpha you might want to find out how it created the modes. Or dump the GL info like you did for the succesful lwjgl modes to see if the driver still reports no alpha.

To rule out 3 we have to use an opengl extension to query the supported pixel formats, but noone has implemented it yet :/. I might do it myself someday, but that's not going to help you now.

Okay, I've just added a few 50% transparent quads to a test application, and they work fine. This is with requesting a 640x480, 0Hz, 32bpp, 8-bit depth, 0-bit alpha and 0-bit stencil DisplayMode. There was a drop in frame rate from about 150fps to 110fps, although I guess this is just my dodgy graphics card?

I'm afraid S3 are ("allegedly") terrible at providing OpenGL support, and their chipsets never perform well in OpenGL apps. I've noticed them bending the OpenGL spec in such a way that the driver I'm currently running won't even pass OpenGL 1.0 certification due to a deficiency in subpixel precision.

Anyone got a clue what may be going on? Once again I'm beginning to suspect not LWJGL but S3 - it looks like LWJGL is just doing the best it can with what's available. However, it remains to be seen how I can ensure I have an alpha-buffer if both the driver and the hardware deny its existence.

Weird, I'd think it was the other way round, that is a requested feature is advertised but either broken or implemented in software or something. Doing alpha but lying about it is simply stupid, IMHO. But yes, it sounds more and more like the driver is pulling your nose. Are your drivers the most current?

Hmmm... I thought that the "alpha" indicates presence of alpha component in framebuffer' pixel format and it does nothing with the blending capability. You can do regular blending operations without having alpha in the framebuffer...

Edit: Hi Alex, I think you're right. I'm going around in circles here... The presence of alpha-bits in the DisplayMode should only affect the presence of an alpha-channel on the display surface, not the ability to perform blending operations themselves.

Thought I was going mad there for a moment!

So my code was working before because 0.4 didn't check alpha values, and doesn't work now because 0.5 does but my hardware doesn't support them. Okay, I'm happy now!

Elias, I'm running pretty much the latest display drivers. They were last updated mid-2001 and I've got drivers from somewhere about that period. S3's ("allegedly") dodgy OpenGL support coupled with Toshiba's ("allegedly") snail-like driver release cycle is a force to be reckoned with.

And I think his wrong, the framebuffer alpha is exactly used to blend the incoming pixel with the one already stored in the framebuffer. If not for blending, what's the use for alpha in the pixel format of the framebuffer?

Everything works fine here...i just had to change the call to Display.create() to make jPCT work again. Even the performance is around 10% higher for me. The window-support is much better now, albeit i can't move the LWJGL-window around!? (Windows XP Home, Radeon 9700pro, Catalyst 3.2)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org