I've not seen this messing with the colors, but then I don't use the latest and greatest Windows version either (Win10 20H2) and my PC is 14 years old at this point (GPU is 9 years old though). For WON version of Half-Life, I used -32bpp command-line parameter along with my patch that also makes it work for menus, the stock game always triggers 16-bit color mode even with that parameter when in menu screens, which is actually conventional interface like normal graphical programs would use with fancy skinning. Unknown if DWM8And16BitMitigation does anything while in 32bpp mode.

UCyborg wrote on 2023-08-31, 19:04:

Unknown if DWM8And16BitMitigation does anything while in 32bpp mode.

The shim is pretty confusing, as well as the game behaviour. With the shim removed, the GDI menu starts at a corner. Without the -32bpp parameter and without the mitigation, the game has no video mode enumerated.

However missions start up, at the lowest resolution possible, in 32-bit colors. I switched to SW mode (needed the DisableMaxWindowedMode SetAppCompat tool) and the game would show the same pink color that appears when you use the -32bpp parameter and run in SW mode. Either Windows is doing an on-the-fly color conversion (that's what I read but with no proof) or the game is asked to be switched to 32bpp (the same thing happens with the mitigation as well, makes me believe the claim that the shim does color conversion is FALSE).

The only broken link here is, even though there's 32-bit in-mission colors, the game still behaves as helpless as the GDI menu is (shrinked, cornerer, etc.). Probably some GDI/user32 call that fullscreens application is also dependant on the mitigation.

UCyborg wrote on 2023-08-31, 19:04:

I've not seen this messing with the colors, but then I don't use the latest and greatest Windows version either (Win10 20H2) and my PC is 14 years old at this point (GPU is 9 years old though).

Afaik that shouldn't cause a color issue. And also Nvidia hasn't yet switched to D3D9On12 so that's out of the equation.

UCyborg wrote on 2023-08-31, 19:04:

For WON version of Half-Life, I used -32bpp command-line parameter along with my patch that also makes it work for menus, the stock game always triggers 16-bit color mode even with that parameter when in menu screens, which is actually conventional interface like normal graphical programs would use with fancy skinning.

In the meantime DxWnd seems to have fixed the problem. The shim isn't created. Not sure if its Windows intentionally acting weird or DxWnd color emulation makes it believe mitigation isn't necessary.

No idea about DxWnd, might have its own tricks that may avoid Windows' mitigation, but without knowing further technical details, that shim's basic function seems to be simply making 16-bit and 8-bit color modes available and making them appear correctly in supposedly 32bpp only environment as they're not normally supported since Windows 8. Old Half-Life has what I'd call preferred color mode for gameplay (16bpp by default) and hardcoded 16bpp mode for menus, so if they're not available, it can't switch to 640x480x16 while in menus and it doesn't enumerate any resolution for gameplay since system doesn't return any with 16bpp colors. Menu window stays in upper-left corner as that's where you position any fullscreen window, it simply fails to cover the whole screen since switching resolution failed.

I know about garbled colors in SW mode with -32bpp parameter, I suppose it just wasn't coded right to work in that mode back then (OpenGL and Direct3D modes are fine), they must have fixed in later versions released through Steam. I don't think there's anything for Windows to fix here as it just provides 16bpp or 8bpp environment as necessary, but with the shim off, game is forced in 32bpp in any case that its software renderer wasn't coded to handle right. You'll see the same effect in legacy Windows versions as well if you try -32bpp parameter.

BTW, maybe a special character before "DWM8And16BitMitigation" word in the registry value turns it off for application? I know I've seen "$" and "~" used in those entries, but haven't looked into their meaning. Obviously you only do that when you know what you're doing since this shim is triggered by application asking for lower color mode. 😀

UCyborg wrote on 2023-08-31, 21:03:

BTW, maybe a special character before "DWM8And16BitMitigation" word in the registry value turns it off for application? I know I've seen "$" and "~" used in those entries, but haven't looked into their meaning. Obviously you only do that when you know what you're doing since this shim is triggered by application asking for lower color mode. 😀

They get used interchangeably. But none of them disables it.

UCyborg wrote on 2023-08-31, 21:03:

it simply fails to cover the whole screen since switching resolution failed.

The render resolution, 400x300 is a valid enumerated resolution in my driver. With the mitigation enabled, the game scales to 4:3, fullscreen on that resolution. What I can assume is without the mitigation, the window handle fails to scale due to an unspecified mode, plus the game tries to run at whatever lowest it possesses due to unspecified mode again.

UCyborg wrote on 2023-08-31, 21:03:

that shim's basic function seems to be simply making 16-bit and 8-bit color modes available and making them appear correctly in supposedly 32bpp only environment as they're not normally supported since Windows 8.

UCyborg wrote on 2023-08-31, 21:03:

I don't think there's anything for Windows to fix here as it just provides 16bpp or 8bpp environment as necessary, but with the shim off, game is forced in 32bpp in any case that its software renderer wasn't coded to handle right.

The results are contradicting:

I tested frame by frame screenshots. On D3D mode on Windows 11 22H2, the shim just makes video modes containing 8/16-bit color to be enumerated. Except the output color, other characteristics of the appearance is identical, regardless of having the shim enabled or disabled.

16bpp, DWM OFF

16bpp, DWM ON

32bpp, DWM OFF

32bpp, DWM ON

This gives the conclusion that 8/16-bit colours will get converted to 32-bit no matter the shim is present or not... right?

Things take a turn in Software mode. In Software mode, enabling the shim gives a proper 16-bit look to the color. But it doesn't in D3D mode. Cannot say why.

On D3D, I tested the game with DxWnd's 16bpp color emulation, as well as on VMware Windows XP and the colour is clearly differentiable. Plus the screenshot file size also speaks on it. Half-Life D3D doesn't obey the shim:

WinXP, DxWnd 16bpp:

Followup:

WinXP, DxWnd 32bpp