User talk:Glorious PC Gaming Master Race

Good day to you.

I have noticed in your recent contributions that you keep setting HDR to 'true' with the note mentioning Auto HDR.

Unfortunately, Auto HDR is *not* a native implementation of in-game HDR that would warrant the "true" value. It is a system-wide setting for Insider Windows 10 and Windows 11 users. Just because such a option exists, does not mean the game natively supports HDR. Auto HDR is a measure that at best would mean a "hackable" value, just like forcing Anti-Aliasing in the Nvidia Control Panel.

The site logged me out while submitting this discussion, so I'd like to clarify who wrote this.

That's not entirely accurate. Auto HDR is enabled only on certain games. Microsoft maintains a whitelist so not all games support the feature even if they are DirectX 11 or DirectX 12. Microsoft seems to do some testing to ensure that the games they whitelist to use the feature look fine with it turned on. And in many of the games I've tried with it turned on, it functions just as well as a native HDR implementation. It really is quite impressive.

There's no way that Microsoft didn't do some tuning to ensure that the Auto HDR feature worked flawlessly with titles like Gears, Halo: The Master Chief Collection, etc. Because of how well Auto HDR works on the Halo games it's probably why they haven't bothered adding 'official' HDR support into The Master Chief Collection's graphics menus yet.

So it should absolutely be noted on a game's page when the game supports Auto HDR, because it's basically as good as a native HDR implementation on many games, and it can be very misleading to readers to declare a game as not having any HDR support at all when it does support Auto HDR.

That's exactly my point. That it's *as* good *as* native HDR, but it's not native HDR itself. The "true" (and "always on" for that matter) value means that the game has *native* HDR support. I agree that it should be noted Auto HDR is supported, but as a note, not as a substitute for native HDR.

Hi,

To clarify some things:

1) The HDR field is to track games which have native support for HDR, or where it can be hacked because the engine supports it but the game does not expose it for some reason (see Detroit Become Human that has native HDR which isn’t enabled in the released game and requires a DLL file from the demo as an example). Tools like Auto-HDR and Special K’s HDR retrofit should not be used to populate that field since they are generic solutions that work across multiple games (thereby making the value of the field useless for tracking purposes).

2) Auto-HDR does not merely operate by an explicit whitelist. Sure, it probably has some, but it mostly gets auto-enabled in any and all games that fulfill a few basic requirements. This is why just throwing Special K’s flip model override at D3D11 games has the side-effect of enabling Auto-HDR for all those games as well.

This is also why Microsoft’s upcoming windowed optimizations feature (their own flip model override akin to Special K) is so important since it will do what SK already does and extend support for Auto-HDR to thousands of more games auto-magically.

3) The quality of Auto-HDR isn’t really relevant in the discussion. A related note here is that it’s based on multiple factors like the art style of the game, the actual display and its reported luminance values, the SDR/HDR Brightness slider, and the Auto-HDR Intensity slider, so your experience will differ from other users’ experience.

PCGW does not currently handle Auto-HDR but once we do so it’ll be handled through an automated note shown on all DX11 and DX12 games set to “false” in the HDR parameter that points to the glossary page, where a section would detail both SK HDR and Auto-HDR and the instructions on how to force their enabling (e.g. for Auto-HDR just throw SK at the game, or use the upcoming window optimizations).

Initial section on Special K's HDR Retrofit and Win11's Auto HDR feature has been documented on the glossary page under Enable HDR output in unsupported games. The plan is to basically hook up a link to that section that's automatically populated on all DirectX 11/12 games that has the HDR field set to false without any note attached to it (this follows the same design as other such automated notes we use on PCGW).

The automated population of a link to the glossary page has now been added, with the following text:

> See the glossary page for potential alternatives.

The change is live on a few pages, such as Anno 1800, but will go live across most other D3D11 and D3D12 games within the next few days as their cache is purged and the pages refreshed.

To follow the style of other automated notes, the link only appears when the HDR parameter is set to false without any custom note having been written. The reason the link does not appear for games in the "unknown" state is to encourage proper editing (so either true to indicate native HDR support, or false to indicate Auto HDR or alternative is required).

Editing Guide have been updated with a minor addition as well to indicate this.

I have expanded the glossary link to also be automatically populated to all OpenGL and DirectX 9 and 10 games where the HDR parameter is undefined or set to false/unknown, as those APIs support HDR rendering internally and HDR "retrofitting" support can be enabled through various alternate methods:

• DirectX 10 is actually supported natively by Auto HDR despite Microsoft's lack of official comments on it, and doesn't need any special tools or methods.

• DirectX 9 requires the use of dgVoodoo 2 to translate them to DirectX 11 which makes them eligible for Auto HDR.

• OpenGL requires the use of Special K as it can interop the OpenGL rendered frame over to DirectX 11 and then allow its HDR retrofitting feature for such games as well.

dgVoodoo 2 can technically be used for older APIs like DirectX 8 as well but since those older APIs lack native support for HDR rendering the end result is likely to be sub-optimal since Auto HDR was trained on games that support HDR rendering internally but merely lack the ability to output said rendered frames.