[4.8-d05ea19] Pink hued textures with material textures

[grahf78]

Textures have a strong pinkish hue when they have PBR materials and brightmaps associated to them. See screenshots below.

The issue does not happen in gzdoom 4.7.1, nor with the other renderers. Attached a reproducible sample.

4.8.0-pre:



4.7.1:

[Enjay]

I can't run your example. I get:

Code: Select all

**** DIED WITH FATAL ERROR:
Shader 'test' could not be linked:
ERROR: Linking fragment stage: No function definition (body) found: 
    Process(vf4;

[grahf78]

My previous sample only worked with the GLES renderer. I've updated it to also work with Vulkan/OpenGL.

[Enjay]

Ah right. I assumed from when you mentioned "other renderers" it should start in them all. With the new sample, I can confirm that on my RTX 2060, the sample is pink in GLES and white in Vulkan with g4.8pre-273-gd05ea1965 and also white in GLES in 4.7.1.

[emile_b]

OK I found the issue, the problem is gl_customshader can be true in GLES now due to this commit:
https://github.com/coelckers/gzdoom/com ... b62a9deea4

So the mShaderIndex gets set to a custom shader which the GLES backend does not know what to do with.

I suppose the question is should gl_customshader be CVAR_ARCHIVE? Does it need to be saved and is it expected to ever be used by the user?

[Rachael]

The intent was to allow the user to turn off shaders when they get too heavy for a system even on Vulkan/OpenGL. It's possible to overload shader clocks on older GL 4.x systems very easily.

[Graf Zahl]

Yeah, but you can't do it like this. There's code depending on that CVAR that may not run in GLES mode.

[Rachael]

Did two reverts then:
https://github.com/coelckers/gzdoom/com ... 0dd3bb3371
https://github.com/coelckers/gzdoom/com ... b7ffbf82ba