[FIXED] new ATI 10.1 drivers don't support some GL1x functions?

[Matzon]

but what I am thinking is - why were we hit with the issue?
what about the other 438294209384092390 applications out there?

IMO, drivers shouldn't change behavior all of a sudden.

[Tobias]

Wow, you guys are fast. I got an error report about it during the night, and you have already fixed it. Thanks for your hard work. Will this warrant a new release? Any ETA on that?

[Matzon]

I am planning on releasing 2.3 as soon as this fix is confirmed working.
I was also hoping to get a new OpenAL-Soft build into this - but I am having problems getting it compiled for all platforms - so this may come in a later version.

[Notch]

If that improves openal support on mac and linux, I'd kill for it to be in.
I recently abandoned java sound (because it's HORRIBLE these days, no pan and gain controls!?) in favor of OpenAL only, but some people (mainly mac it seems) can't get that to run.

[princec]

Are you having OpenAL trouble on Mac? I had been under the impression it worked flawlessly (no support requests at any rate).

Cas

[spasi]

but what I am thinking is - why were we hit with the issue?
what about the other 438294209384092390 applications out there?

IMO, drivers shouldn't change behavior all of a sudden.

An application that never cared about OpenGL 3.1+ would never encounter this issue. All the drivers so far, from both major vendors, continue exposing the deprecated functionality, it never went away. An OpenGL app written 10 years ago would use the same context creation routine we use in LWJGL (without ContextAttribs) and would be able to retrieve the function pointers to the deprecated functions with no issues.

The problem with LWJGL has 2 parts:

a) We try to support all the new stuff, from day one. We were ready for GL 3.1 (that drops the deprecated functionality) when GL 3.0 was released. We even introduced the pseudo-forward-compatible mode, for people to test how GL would feel like without the deprecated functions.
b) For LWJGL to consider an extension supported, all functions in that extension should be exposed. (that's the main problem)

So, imagine that LWJGL encounters a GL31 compliant implementation that does not expose ARB_compatibility, or even a GL30 implementation with support for the forward compatible bit (this hasn't happened yet, but at the time GL30 was released it sounded like a real possibility and we had to support it). Without any changes to how we load extensions, LWJGL would suddenly fail to even start. 1 missing function from GL11 would be enough to make the whole thing unavailable, causing LWJGL to throw an early exception.

At that time there were 2 ways to enable the forward compatible path:

1) The application specifically asked for a forward compatible context (ContextAttribs.withForwardCompatible). This was even available to pre3.0 implementations (the pseudo-fc mode).
2) OpenGL 3.1 was supported and ARB_compatibility was not exposed. This was forced by LWJGL, since it had to follow the spec.

Then came OpenGL 3.2 that introduced another way to avoid forward compatible mode, the Compatibility profile. Then came ATI 10.1 that dropped ARB_compatibility. Then we had to fix LWJGL.

[Notch]

Does LWJGL really have to be clever?

The less clever it is, the lower are the odds of it tripping itself over. I don't want to release a game using 2.4 or whatever, then have it break five years down the line.

[spasi]

LWJGL doesn't do anything special tbh, I just followed the initial design (extension supported = all functions exposed) and the OpenGL spec. The only way to avoid all the above would be to have users load the extensions/functions manually, or have them manage the deprecation model manually. They'd still have to solve the same problems though, so why not centralize the solutions? The only unnecessary feature was the pseudo-fc mode, but even that you get for free, it's an implementation by-product.

You also need to realize that OpenGL is indeed drastically changing. We have a new context creation routine for the first time in 15 years, it's only normal that problems would occur. I don't think we'll have any problems down the line, this instability period should be very short. The real problem is... what happens if in 5 years ATI/NV decide to drop support for the compatibility profile? There's nothing LWJGL can do for you in that case, it's the application's responsibility to be ready for the post GL 3.0 era. At least LWJGL will be functioning properly when it happens.

On a related note, I just found another bug in LWJGL. There's some state tracking performed internally and we used GL13.GL_MAX_TEXTURE_UNITS at some point. It so happens that GL_MAX_TEXTURE_UNITS is deprecated and was causing an INVALID ENUM error during context initialization if a forward compatible context was used. I changed it so that GL20.GL_MAX_TEXTURE_IMAGE_UNITS is used when available and we're also now catching+logging any OpenGL errors during context init, instead of throwing an (unrecoverable) exception. What I previously thought was an error caused by no support for the core profile, ended up being a stupid LWJGL bug.

The good news is that ATI actually supports the core profile. ContextAttribs.withForwardCompatible and ContextAttribs.withDebug also work.

[Matzon]

from my POV, if LWJGL doesn't do this work - it would be up to the individual developer. So I see this as a Good Thing (TM). But sometimes it just gets a bit bumpy

[Matzon]

If that improves openal support on mac and linux, I'd kill for it to be in.
I recently abandoned java sound (because it's HORRIBLE these days, no pan and gain controls!?) in favor of OpenAL only, but some people (mainly mac it seems) can't get that to run.

we're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft: http://repo.or.cz/w/openal-soft.git/tree/HEAD:/Alc

[elias4444]

Out of curiosity, what's the proper way to create a display context now? I've just been using Display.create(PixelFormat) and Display.create(). Has this changed?

we're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft

Does this mean no more sound support on Mac? It seemed to work fine before (as far as I could tell).

[Matzon]

we're not supporting openal-soft for mac, since no one has done a CoreAudio backend for openal-soft

Does this mean no more sound support on Mac? It seemed to work fine before (as far as I could tell).

No it means that we dont supply openal-soft - we use the platform provided openal on macs.

[spasi]

Out of curiosity, what's the proper way to create a display context now? I've just been using Display.create(PixelFormat) and Display.create(). Has this changed?

No, it hasn't changed. Using Windows as an example, calling Display.create without passing any ContextAttribs will use wglCreateContext(hdc) under the hood. On a GL implementation that supports GL30 or newer, wglCreateContext(hdc) is equivalent to wglCreateContextAttribsARB(hdc, 0, NULL). What happens at this point depends on the implementation (see wgl_create_context for details), but you can be sure that:

The legacy context creation routines can only return OpenGL 3.1 contexts if the GL_ARB_compatibility extension is supported, and can only return OpenGL 3.2 or greater contexts implementing the compatibility profile. This ensures compatibility for existing applications. However, 3.0-aware applications are encouraged to use wglCreateContextAttribsARB instead of the legacy routines.

ContextAttribs is simply LWJGL's wrapper of the WGL/GLX ARB_create_context extensions. Passing a ContextAttribs instance to Display.create gives you control of what happens in CreateContextAttribsARB, which is mostly useful for creating a Core profile/forward compatible context.

[Tobias]

Have you got an ETA on the next release with this fix?

Dare I distribute the nightly build instead?

[Matzon]

You can use nightly. I plan on releasing 2.3 this weekend. I was waiting for notch's confirmation tho ... - but I think its all good.