From 78eef43d506b4468beb45248e97be4a335fd3955 Mon Sep 17 00:00:00 2001 From: Daniel Gibson Date: Tue, 17 Aug 2021 19:43:01 +0200 Subject: [PATCH] Fix rendering of mars globe in main menu with some drivers The problem was that negative values (from dhewm3tmpres.xyz) were passed to POW, and POW doesn't have to support negative bases, according to ARB_fragment_program.txt, and Intels Linux drive apparently doesn't, see also https://gitlab.freedesktop.org/mesa/mesa/-/issues/5131 Using MUL_SAT instead of MUL to clamp the value that gets passed to POW afterwards to [0, 1] fixes the problem without any disadvantages. --- neo/renderer/draw_arb2.cpp | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/neo/renderer/draw_arb2.cpp b/neo/renderer/draw_arb2.cpp index f2a6420c..f55aeb02 100644 --- a/neo/renderer/draw_arb2.cpp +++ b/neo/renderer/draw_arb2.cpp @@ -464,7 +464,11 @@ void R_LoadARBProgram( int progIndex ) { // outColor.a = dhewm3tmpres.a; const char* extraLines = "# gamma correction in shader, injected by dhewm3 \n" - "MUL dhewm3tmpres.xyz, program.env[4], dhewm3tmpres;\n" // first multiply with brightness + // MUL_SAT clamps the result to [0, 1] - it must not be negative because + // POW might not work with a negative base (it looks wrong with intel's Linux driver) + // and clamping values >1 to 1 is ok because when writing to result.color + // it's clamped anyway and pow(base, exp) is always >= 1 for base >= 1 + "MUL_SAT dhewm3tmpres.xyz, program.env[4], dhewm3tmpres;\n" // first multiply with brightness "POW result.color.x, dhewm3tmpres.x, program.env[4].w;\n" // then do pow(dhewm3tmpres.xyz, vec3(1/gamma)) "POW result.color.y, dhewm3tmpres.y, program.env[4].w;\n" // (apparently POW only supports scalars, not whole vectors) "POW result.color.z, dhewm3tmpres.z, program.env[4].w;\n"