Novum / vkQuake

Vulkan Quake port based on QuakeSpasm
GNU General Public License v2.0
1.84k stars 223 forks source link

Game is too bright, even with the lowest value #161

Closed Phraqzy closed 5 years ago

Phraqzy commented 5 years ago

I can't lower contrast and brightness, the lowest values looks like this image image This problem does not occour with Quakespasm, the colors are smooth: image I'm using Radeon with Mesa drivers

Novum commented 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.

brzegorz commented 5 years ago

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?

LethalManBoob commented 5 years ago

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.

ckotte commented 5 years ago

@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.

dreamer commented 5 years ago

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

ckotte commented 5 years ago

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
Faalagorn commented 5 years ago

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) Screenshot from 2019-08-16 19-51-18 Screenshot from 2019-08-16 19-51-12

And here's how it looks on Nvidia 960 (nvidia 430.40) quake_max quake_min

davll commented 4 years ago

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) 2020-02-11-004616_1920x1080_scrot

However, the modified Quakespasm with sRGB output enabled can reproduce the same issue.

Quakespasm with sRGB color space enabled (modified code) 2020-02-11-010602_1920x1080_scrot

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!! 2020-02-11-013100_1920x1080_scrot

I will submit a pull request to fix the problem