SDL2 and 3: Impossible to create OpenGL ES 1.0 context via wgl

[edo9300]

Currently, SDL always forces the use of EGL when creating a GL ES 1.x context on windows, ignoring entirely the usage of wgl,

SDL/src/video/windows/SDL_windowsopengl.c

Line 703 in d16371b

return SDL_GetHintBoolean(SDL_HINT_OPENGL_ES_DRIVER, false) || _this->gl_config.major_version == 1 || _this->gl_config.major_version > _this->gl_data->es_profile_max_supported_version.major || (_this->gl_config.major_version == _this->gl_data->es_profile_max_supported_version.major && _this->gl_config.minor_version > _this->gl_data->es_profile_max_supported_version.minor); // No WGL extension for OpenGL ES 1.x profiles.

The comment here No WGL extension for OpenGL ES 1.x profiles is incorrect, as wgl supports creating them, and I've been using it without problems outside of sdl on both nvidia and amd gpus.
In fact forcing a context creation via wgl by stubbing out that check, will make it be properly created

[icculus]

So, wgl doesn't support this directly, but rather your GL implementations expose the WGL_EXT_create_context_es_profile extension.

We could check for that extension and avoid using EGL if available, but, in that extension spec is this text (emphasis mine)...

Is implementation of an OpenGL ES 2.0 profile mandatory for a desktop OpenGL implementation?

RESOLVED: NO. The ARB considered making support for an ES 2.0 profile mandatory for an OpenGL 4.1 implementation, but decided against it. Most ARB members would prefer that people use EGL to access OpenGL ES 2.0, whether on the desktop or on mobile devices.

We don't care what the ARB members prefer, but it does raise an important question: is there a problem with using EGL? You make the same SDL calls and still get the same GLES context for it, right? Is there a benefit to using the wgl path over EGL?

[slouken]

We shouldn’t change anything for SDL2, but at this point I think we can use EGL for all platforms.

[slouken]

We should double check that some of the special things we do with WGL are possible with EGL, but I think they’re all for desktop GL anyway.

[edo9300]

it does raise an important question: is there a problem with using EGL? You make the same SDL calls and still get the same GLES context for it, right? Is there a benefit to using the wgl path over EGL?

To use EGL, you need to ship an egl implementation with your binary, which on windows is basically ANGLE (there was a time where the ati driver on windows had an egl implementation bundled in its dll, but it wasn't that good and it has not been present for a long time) but with the wgl path the driver is already taking care of it, and you need no extra layers on top of the GLES context.

We could check for that extension and avoid using EGL if available, but, in that extension spec is this text (emphasis mine)...

The code is already trying wgl when requesting a GLES2 context and already checking the extension being present

SDL/src/video/windows/SDL_windowsopengl.c

Line 492 in ed6a72a

if (HasExtension("WGL_EXT_create_context_es2_profile", extensions)) {

so the change would be to actually just try that path with a GLES1 context as well

[slouken]

Hmm, I thought NVIDIA and AMD drivers included an EGL implementation, never mind!

[edo9300]

Hmm, I thought NVIDIA and AMD drivers included an EGL implementation, never mind!

Returning to this, I rechecked things again, and at least for amd I could confirm that it is indeed still shipping an egl implementation (I don't remember exactly where I did check back then when I investigated this the first time), but from where it's located, it seems to be only for internal use by the driver.
More specifically, it's provided in atioglxx.dll for x86 and atio6axx.dll for x64, but at least from my tests, since they're located under the DriverStore folder (earlier drivers instead put them in System32/SysWOW64), they aren't loadable directly by LoadLibrary (manually copying the dlls to the program folder works as usual).
Still, this is the library that ends up being loaded indirectly by windows' Opengl32.dll.
Can't say anything regarding nvidia, just investigated this for completeness because I wasn't entirely sure if I recalled properly what I said earlier.

[icculus]

Okay, that EGL might not be present changes things. I'll poke at this.

[icculus]

Okay, you should be good to go now!