Open RPicster opened 1 month ago
This is a critical issue for us, because it affects many thousands of (dome keeper) players. To be clear, their HDR in windows is messed up after closing the game. This is an issue beyond just a godot game not using HDR or not displaying correctly. Is is a godot game messing with the OS of the player even when the game does not run. This looks bad for Godot too, as from the player reports this is not an issue they encounter with other games.
I don't remember being able to reproduce this here, on Godot or any other OpenGL app that uses exclusive fullscreen. I have HDR enabled at all times as well as RTX HDR enabled.
Can you ask players to try setting the OpenGL/Vulkan present mode to Prefer layered over DXGI swapchain on the Dome Keeper executable in the NVIDIA Control Panel?
Also, can you ask players the following information:
winver
.)Knowing this information should make it easier to troubleshoot this.
Edit: @bruvzg mentioned that forcing DXGI swapchain resolves the issue on their end. There's a linked PR you can try out: https://github.com/godotengine/godot/pull/94503
If the PR resolves the issue, then implementing https://github.com/godotengine/godot-proposals/issues/10242 will likely resolve this bug for everyone (or all NVIDIA users at least).
Hey @Calinou ! The issue is reproducable in the MRP on my machine, so I can at least give you feedback about my setup. Asking anything from our players in that scenario is a bit difficult, we have a large playerbase and 99.9% of the people do not wand to fiddle around in the NVidia Control panel ... most don't even know what it is ;)
Here are my system specs:
I will try building the PR, unfortunately the build artifacts are already gone 🙈 Have you tried reproducing the issue with the attached MRP? Just out of curiousity?
Some info from my testing: Tested on Windows 11 (22631.4317) / RTX 2070 SUPER
Auto HDR is a Windows 11 feature, this setting seems to have no effect on the issue. No idea what's RTX HDR (probably not supported on 20xx series).
@bruvzg Thanks for testing! I have the same setup: HDR display as the main, running the app. I also tested it with the #94503 PR and can confirm that it fixed the issue for me 👍
You may also force the use of ANGLE to work around the issue.
You may also force the use of ANGLE to work around the issue.
Can you give me some more details on you suggestion? I honestly have no clue what you mean.
Can you give me some more details on you suggestion?
Run the project with --rendering-driver opengl3_angle
command line argument (to test) or set rendering/gl_compatibility/driver.windows
project setting to opengl3_angle
.
If you are using a custom build, check this part of build guide - Compiling with ANGLE support, there are some extra build flags and external libraries required.
In case of Godot, we use ANGLE as OpenGL over D3D11 emulation, intended for old GPU with low quality OpenGL support (most of the older Intel integrated GPUs). It will use DXIL swapchain as well, but since it's emulation layer it's usually significantly slower than native OpenGL.
Can you give me some more details on you suggestion?
Run the project with
--rendering-driver opengl3_angle
command line argument (to test) or setrendering/gl_compatibility/driver.windows
project setting toopengl3_angle
.If you are using a custom build, check this part of build guide - Compiling with ANGLE support, there are some extra build flags and external libraries required.
In case of Godot, we use ANGLE as OpenGL over D3D11 emulation, intended for old GPU with low quality OpenGL support (most of the older Intel integrated GPUs). It will use DXIL swapchain as well, but since it's emulation layer it's usually significantly slower than native OpenGL.
Thank you for the details!
If it is significantly slower, it's not an option as the default for us. Many players are already having performance problems since we switched to Godot 4.
I will try it out tho.
This is a critical issue for us, because it affects many thousands of (dome keeper) players. To be clear, their HDR in windows is messed up after closing the game. This is an issue beyond just a godot game not using HDR or not displaying correctly. Is is a godot game messing with the OS of the player even when the game does not run. This looks bad for Godot too, as from the player reports this is not an issue they encounter with other games.
Fixed by both aforementioned PR and forcing DXGI swap chain in the NVIDIA Control Panel (3D Settings → Manage 3D Setting → Last item on the list, do not forget to click Apply on the bottom of the page. It seems to stay fixed until reboot, even if setting is reverted). Auto HDR is a Windows 11 feature, this setting seems to have no effect on the issue. No idea what's RTX HDR (probably not supported on 20xx series).
@ReneHabermann For any Dome Keeper players on Windows 11 with NVIDIA and HDR, you may want to recommend to your players that they change this setting as a matter of course. Not only does it fix (work around?) the issue, layering on the DXGI swap chain also means Windows 11 is now able to use its built-in Auto HDR on the game. Auto HDR can be hit-and-miss, but to my eye, the results in Dome Keeper are beautiful.
Thank you, that's great to know! I'll recommend that.
Tested versions
Reproducable in:
System information
Godot v4.3.stable - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.6094) - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)
Issue description
When an Compatibility application is switched do exclusive fullscreen and exited afterwards, Windows HDR will look washed out and is "broken" until it is switched off and on again in the Windows settings.
Steps to reproduce
Minimal reproduction project (MRP)
HDR.zip