Changing OpenGL Version In LWJGL

Question

So i\'ve been wondering how to change the openGL version in lwjgl.. I know i can change the version with PixelFormat and ContextAttribs as being said on the wiki http://lwjgl.or

Answer 1

Well, the logic behind OpenGL context versions can be a bit confusing. But it does make sense when seeing it in the historical context:

Back in the day, there were no special "context version" hints. There was just one way to create a context, and you would get the highest version that the particular implementation you run it on does support. You could query the version string and the extension string, and check if all of the features your code actually needs are available. Getting a higher version than you really needed was a never a problem since every new GL version was 100% backward compatible to the previous versions. (Well, in theory, at least). It stayed that way till OpenGL 2.1.

However, with OpenGL 3.0, the "deprecation model" was introduced. For the first time, features were marked "deprecated" and planned to be actually removed. And for the first time in the history of OpenGL, backwards compatibility was not guaranteed any more. Subsequently, a new context creation mechanism was introduced: The ARB_create_context functionality (see the extension specs for the wgl version or the glX version), which includes the possibility to request a "context version". Now you have the situation that old applications, which know nothing about GL3 and the new context creation mechanism should still function as before. So what the old method gives is something which will be compatible to GL 2.1 (or, if you have a really old or limited implementation, it gives you just some GL 1.x version, when the more modern GL 2.x features are not supported).

With OpenGL 3.2, context profiles where introduced. This is basically the solution the ARB finally came up with, to deal with these compatibility issues. Beginnning with GL3.2 there are two profiles defined: core and compatibility. In core profiles, deprecated stuff is removed, while in compatibility profiles, you get something which is going back to support everything which ever was in GL from 1.0 on.

Things could be that simple, but they aren't. Implementors are only required to support the core profile, the compatibility profile is optional. This lead to the situation we now have: depending on the implementation and the platform, the options for GL context will vary:

• All major desktop platforms (Windows, Unix/Linux, OSX) support "legacy" GL with the old context creation method.

• On windows, using modern GPUs and drivers, you will still typically get the highest compatibility profile which is supported by the GPU when you use the legacy context creation/don't request a specific version/request a version < GL3. So you can end up with 4.4 when you asked for 1.0 there.

• On OSX, there is a sharp cut. Legacy GL creation will give you at most GL2.1. If you need modern GL, you have to ask for a 3.2 core profile.

• On Linux, it depends on the GPU driver you are using. AMD's and NVidia's proprietary drivers behave similiar to the windows case. However, the open source mesa3D implementation (which is also used by the official intel GPU drivers) does handle it more like OSX does: only core profiles are supported.

For a GL developer, there are a few things to consider:

• You can not reliably mix modern (GL >= 3) and deprecated legacy features in the same application, since this will not be available on all platforms (and is not required by the spec). If you want to go the "modern" route, request a core profile for somehting >=GL 3.2.

• If you want to use "legacy" GL, you should limit yourself to the GL2.1 feature set. You still might end up with some compatibiity profile of a much higher version, but you can never rely on that - at least, if you don't target a specific platform. But as the GL spec does not require compatibility profiles to be implemented at all, this isn't something I would recommend. This also means that requesting a compatibility profile is quite useless in practice.

What you can rely on: if you requested a specific GL version (and maybe profile) and you actually get a context, it might not be exactly the version you asked for, but it will be a version which supports every feature of the version you asked for. (But the reverse conclusion is not valid in the general case.)