Closed Phraqzy closed 5 years ago
Something is seriously wrong with your display settings. I have no idea what it is but a setting on your system is changing gamma before the image is displayed.
vkQuake uses the same shader tone mapping as QuakeSpasm with the GL2 path. Literally the same shader. It looks identical on Windows on Linux for me.
Note: QuakeSpasm also supports changing display gamma. I'm not going to add this. It's a terrible hack. Very likely QuakeSpasm looks "correct" because it's overriding your way too bright gamma.
I'd like to bump this thread, as I have exactly the same issue. I also use the mesa drivers with RX 570 on Arch Linux. I use the build from AUR(https://aur.archlinux.org/packages/vkquake/). I doubt that it' system-wide, as vkquake is literally the only program suffering from the issue. But if you are right, how can I troubleshoot it?
If i can offer some advice. Make sure the vulkan sdk and runtime are updated with the newest drivers when building them. And if you dont build, try building it also try vice versa.
@Phraqzy @brzegorz Could you resolve this issue in the meantime? I have the same issue with Arch Linux and vkquake or vkquake-git from AUR. However, I use the Intel vulkan drivers.
I am also experiencing this issue; my Vulkan libs are up-to-date, using RX590.
One interesting thing I noticed; on stdout vkQuake reports:
Using A2B10G10R10 color buffer format
Using D32 depth buffer format
But in-game settings it says: "color depth: 24"
@vkQuake devs if you are not willing to fix this bug, can you at least leave a tip where to start looking?
[edit]
Simply changing gamma
to 1.5
made the experience much better; any particular reason why gamma defaults to 1? It's impossible to set gamma to 1.5 using in-game "brightness" slider - the value range is 1.0 .. 0.5
Looks like this is at least a valid workaround. If I set gamma
to 2
, then it looks similar to quakespasm. However, if I change the brightness slider in the game it resets immediately and the display is too bright again.
I have a slightly different output:
Using A2B10G10R10 color buffer format
Using X8_D24 depth buffer format
I've tested that on two computers (both with Arch and pretty much the same configuration other than the GPU, drivers and some installed software such as WM/DE).
Here's how it looks at my RX 580 with Mesa (Mesa 19.2.0-devel (git-a0a7fa7531) with ACO)
And here's how it looks on Nvidia 960 (nvidia 430.40)
I don't think that incorrect display settings cause the problem because Quakespasm is not too bright as vkQuake.
Quakespasm without sRGB color space (original code)
However, the modified Quakespasm with sRGB output enabled can reproduce the same issue.
Quakespasm with sRGB color space enabled (modified code)
So, the root cause of the problem is that sRGB pixel format will convert the outputs of fragment shaders by y = pow(x, 1/2.2)
to preserve more details on dark areas. However, original Quake and GLQuake do rendering on sRGB space already (there was no idea about gamma correction...) so it will result in over-bright views due to unnecessary encoding operations on sRGB.
To fix the problem on vkQuake is easy:
Set the format of swap chain images and image views to VK_FORMAT_B8G8R8A8_UNORM
to avoid sRGB encoding operation.
The problem disappeared!!
I will submit a pull request to fix the problem
I can't lower contrast and brightness, the lowest values looks like this This problem does not occour with Quakespasm, the colors are smooth: I'm using Radeon with Mesa drivers