[HL25] "Failed to create SDL Window, unsupported video mode. A 16-bit color depth desktop is required and a supported GL driver."

[TrueMorph]

After the anniversary update, OpenGL mode stopped working on my laptop. I get this message when trying to launch the game: "Failed to create SDL Window, unsupported video mode. A 16-bit color depth desktop is required and a supported GL driver."

Software mode works as such, but the errors that appear have already been reported.

Specs: Asus UX31E Intel Core i5 2467M @ 1.60GHz 4 GB Ram Intel HD Graphics 3000 Windows 7 Pro

[SamVanheer]

This error means your graphics card doesn't support the minimum requirements for the OpenGL renderer.

But looking at the logic that triggers the error there might be a configuration issue in the engine regarding OpenGL properties.

The error shows if GL_RED, GL_GREEN and/or GL_BLUE have <= 4 bits, or if GL_DEPTH has < 16 bits or if the renderer is GDI Generic.

The problem is that the red, green and blue bit settings are configured to be 4 bits to begin with, so it's possible the wrong pixel format is being selected by SDL under the hood. There's also a fallback attempt that configures the bit values to 3.

It is also possible that your graphics card doesn't support the required properties.

For reference for my graphics card (GTX 4070) SDL2 selects a pixel format that has 8 bits for red, green and blue and 24 bits for depth.

[SamVanheer]

The update that just released changed the checks i mentioned above to <= 2 bits. Try running it now and see what happens.

[TrueMorph]

The update that just released changed the checks i mentioned above to <= 2 bits. Try running it now and see what happens.

There is a good chance that the graphics or drivers are already severely outdated and certain functions do not work. As far as I know, this chip supports OpenGL 3.1 and there are sometimes problems with it. Intel didn't necessarily put a lot of care into its drivers.

After installing the update you mentioned, the situation is the same. It continues to pop up this message. I also tried running the game in windowed mode with the same result.

[SamVanheer]

Try using GLView to see which renderer is reported by OpenGL: https://www.realtech-vr.com/home/?page_id=142

If it reports GDI Generic then it's probably falling back to a software driver implementation instead of one that uses the GPU. That's the renderer that isn't supported and is the most likely reason why it's not working.

[TrueMorph]

I have installed the program from your link and I think everything looks ok, although I am not that technical when it comes to these things. glview-Intel(R) HD Graphics 3000-4.zip

[SamVanheer]

If i'm not mistaken this game still requires a compatibility context to function. Forward contexts and Core contexts don't have support for the deprecated immediate mode API so it's possible that Windows is falling back to GDI Generic as a result by selecting the "No Acceleration" renderer (no hardware acceleration).

To be more specific, Intel integrated cards support a specific range of OpenGL features and the older ones needed by this game are not supported.

I don't know if there is a workaround for this but you can try looking around online.

[pyasetskyostap]

I have the same problem. But after the message about unsupported video mode, I get this message:

Before the 25th update, everything worked fine.

My specs:

HP Probook 4540s Intel Core i3-2370M @ 2.40GHz Intel HD 3000 16GB RAM Windows 10 Pro

[SamVanheer]

I think what's happening here is the window and context creation logic in CGame::CreateGameWindow fails to account for an implementation detail in SDL2.

The engine first creates a window, adjusting the OpenGL attributes if the first attempt fails. Then it tries to create a context, resetting the attributes if the first attempt fails.

However (at least on Windows) the OpenGL attributes are used to choose a pixel format when the window is created, not when the context is created: https://github.com/libsdl-org/SDL/blob/f184dea16ce38cad7c8c25cf4f917c6825f20e71/src/video/SDL_video.c#L2103-L2116 https://github.com/libsdl-org/SDL/blob/f184dea16ce38cad7c8c25cf4f917c6825f20e71/src/video/windows/SDL_windowswindow.c#L566-L695 https://github.com/libsdl-org/SDL/blob/f184dea16ce38cad7c8c25cf4f917c6825f20e71/src/video/windows/SDL_windowsopengl.c#L687-L695 https://github.com/libsdl-org/SDL/blob/f184dea16ce38cad7c8c25cf4f917c6825f20e71/src/video/windows/SDL_windowsopengl.c#L567-L685

Chain of calls:

SDL_CreateWindow -> WIN_CreateWindow -> WIN_GL_SetupWindow -> WIN_GL_SetupWindowInternal

The context major and minor version are checked when the context is created so those can be changed later on: https://github.com/libsdl-org/SDL/blob/f184dea16ce38cad7c8c25cf4f917c6825f20e71/src/video/windows/SDL_windowsopengl.c#L705-L828

Before the anniversary update the OpenGL attributes are not changed after the window has been created. Perhaps this discrepancy is causing the wrong driver to be used which triggers the GDI Generic check?

I suppose the solution is to recreate both the window and context if any OpenGL attributes need changing.

To make this easier to figure out a couple changes to the error dialog should be made:

1. Create separate dialogs to show more specific errors: one for the color and depth properties and one for the driver
2. Add the error message returned by SDL_GetError to the dialog. SDL sets an error if something goes wrong and that information can help narrow down the cause of the problem

[m1kemex]

Hi. I'm experiencing a similar issue. I'm running Windows 10 on a Thinkpad X301 (4500MHD GPU) with 8.15.10.2993 driver. The program I'm trying to run is Yamagi Quake II port which depends on SDL to setup the OpenGL environment. It fails to initialize OpenGL and currently only works in software mode:

*** refresher initialization Loading library: ref_gl1.dll Byte ordering: little endian Refresh: Yamagi Quake II OpenGL Refresher Client: 8.30 Setting mode 22: 1920x1200 (vid_fullscreen 1) Current display mode isn't requested display mode Likely SDL bug #4700, trying to work around it Can't get display mode: Couldn't find display mode match SDL SetVideoMode failed: Couldn't find display mode match Reverting to windowed r_mode 4 (640x480). Real display mode: 1440x900@60 R_InitContext(): Got an OpenGL version 1.1 context - need (at least) 1.4! ref_gl::R_SetMode() - invalid mode ref_gl::R_Init() - could not R_SetMode() ERROR: Loading ref_gl1.dll as rendering backend failed.

It is obviously handling the setup process improperly because:

1. OpenGL 2.1 is confirmed to run properly. 1a) I've run some utilities to check the OpenGL details and it reports the version and supported extensions properly. 1b) Unofficial 3.24 patch, which uses the original code of the game with some tweaks (no SDL), works perfectly fine in hardware-accelerated mode.
2. 1920x1200 is not an available mode on the X301 (max panel resolution is 1440x900).

My theory is that SDL is trying to use an unsupported pixel format, assuming it must exist, rather than checking its existence beforehand. And, at the same time, it's giving up too quickly after failing to detect a working mode once. A more sophisticated subroutine is required to interate formats until a working one is found.

Not sure if this is device-specific, or just a general limitation of Windows 10, but it seems like the video card only supports 32 bit color modes. That is probably causing Windows' opengl32.dll to fall back to the non-accelerated, generic 1.1 mode, when an unsupported format is requested. That should explain the 1920x1200 resolution.

[obiwan-bartek]

Does the executable file has a "compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1" " in it's manifest? If yes, than this is probably a problem with Windows/Intel Graphics Drivers that exposes only a GL1.1 (GDI Generic) interface to such application, not the real HW GL interface. The same problem was found by AIDA64 user many years ago https://forums.aida64.com/topic/3117-bug-in-opengl-in-550/ and there https://stackoverflow.com/questions/34676697/embedding-manifest-into-the-application-binary-breaks-opengl-2

If this is it, then maybe Valve could remove the manifest from HL executable (I have the same problem on i5-2500S)?

The other fix for this situation, is to copy all *.dll files from Intel Graphics Driver package (especially the ig4icd64.dll and ig4icd32.dll which are OpenGL DLL Drivers) to the program directory (where the EXE file is). That way, exe file is forced to use it's "local" copy of dll, instead of the one provided from system (usually from System32 directory, but could be whatever, who knows how windows is handling that). BUT, that way I had TERRIBLE performance on HL 25 Anniversary (2-3fps). Don't know why.

[s1lentq]

I've been looking into what's causing the issue, and It seems like it's more about how SDL2's SDL_GL_GetAttribute behaves in newer versions, especially on somes GPUs like the Intel HD 2500/3000/4000 series. In the newer version of SDL2, or more precisely, after this commit, sometimes it tries to query component sizes using framebuffer instead of glGetIntegerv, because these GPUs report support for OpenGL 3.0

The problem is that when request component sizes using the framebuffer glGetFramebufferAttachmentParameteriv, fail occurs with error GL_INVALID_OPERATION on Intel HD 2500/3000/4000 GPUs and returns zero values, which makes GoldSrc think that the GPUs isn't capable of supporting color depth, but in fact, this isn't the case

One of proposed fix is to support the previous way using glGetIntegerv to check component sizes when SDL_GL_GetAttribute fails or returns something odd. This should ensure that the GoldSrc gets the correct values ​​and avoids false positives for unsupported view modes.

Also note that this isn't a problem on much older the GPUs such as Intel HD 2000, as these doesn't support OpenGL 3.0, so framebuffers aren't initially requested. This shows that this is actually a compatibility issue and not a lack of support from the GPU.

I'm not sure if this issue is specific to SDL2, but it seems more like integrated GPUs, such as Intel HD Graphics, maybe don't fully implement all functions, despite claiming OpenGL 3.0 support.