Unknown blend mode 'gl_src_color' leads to black menu screen with the PadMod

[kai-li-wop]

The original PadMod (World of PADMAN as a mod for Q3A) turns 20 years this year so for testing purposes I installed the last available ioquake3 build from the website and fired up the PadMod resulting in a black screen after passing the key request screen. This is probably due to an error in PadMod's menu shader where an unknown blend mode is used:

WARNING: unknown blend mode 'gl_src_color' in shader 'menushader', substituting GL_ONE

The full black screen appears only with OpenGL2 renderer. Switching back to OpenGL1 renderer, the menu is visible properly but simply the menu and console background shader do not work. With vanilla Q3A the warning also appears but without any further issues. Q3A seems to simply ignore any shader issues and draws menu bg shader and console shader.

Why this different behavior? Probably I should work on a fix for the PadMod to make it work properly with current ioquake3.

PadMod with ioquake3 - OpenGL2:

PadMod with ioquake3 - OpenGL1:

PadMod with vanilla Quake 3 Arena:

[kai-li-wop]

A little more information on the menu shader and the OpenGL2 renderer:

menushader
{
	nomipmaps
	{
		map menu/main/BgShader.tga
		rgbGen wave sin 1 0.01 0 0.2 
		tcMod rotate 20
		tcMod turb 0.1 0.2 0.1 0.1
		alphaGen Vertex
	}
	{
		map menu/main/padwater5.tga
		rgbGen lightingDiffuse
		blendfunc gl_dst_color gl_dst_alpha
		tcMod turb 0.6 0.1 0.1 0.8
		tcMod scale 1.5 1.5
		tcMod scroll 0.2 0.1
	}
	{
		map menu/main/padwater2.tga
		rgbGen lightingDiffuse
		blendfunc gl_src_color gl_src_alpha
		tcMod turb 0.3 0.2 1 0.5
		tcMod scroll 0.6 0.3
		tcMod scale 2.2 2.2
	}
	{
		map menu/main/padwater1.tga
		blendfunc gl_dst_color gl_src_color
		tcMod turb 0.6 0.1 1 0.5
		tcMod scale 2.1 2.1
		tcMod scroll 0.2 0.4
	}
}

2nd AND 3rd stage seem to cause issues. The 2nd stage leads to overall black menu screen WITHOUT the given shader warning from above. The 3rd stage leads to overall black menu screen WITH the given shader warning from above. Deleting both stages leads to the shader be drawn normally. So this might be a quick solution.

I still cannot understand why console shader in wop directory does not overrule the console shader in baseq3 directory with ioquake3 but it totally does with vQ3A.

[zturtleman]

It sounds like OpenGL2 needs to treat rgbGen lightingDiffuse as rgbGen identityLighting on shaders using LIGHTMAP_2D. lightingDiffuse is only meant to be valid on 3D models, not 2D or world surfaces. (Should compare with opengl1 behavior / code for this. World surfaces end up black in opengl1 if I remember correctly.)

Regarding the console shader: The shader file load order is—as far as I know—unintentionally different (reversed?) in ioquake3 compared to vanilla Quake 3. developer 1 prints loading each shader file to the console and may show this. In the current situation, the only guaranteed way to replace a shader in both vq3 and ioq3 is to replace the whole original baseq3 .shader file.

[Chomenor]

I believe ioquake3 and vanilla Q3 do use the same shader load order in general, but there is an exception if the shader is the first one defined in the .shader file, in which case vanilla Q3 has some weird behavior different from ioquake3 (generally giving such shaders elevated priority). Note that "console" is the first and only shader defined in pad_console.shader so this behavior could be relevant here.

I don't remember exactly but it has to do with some buggy code around https://github.com/id-Software/Quake-III-Arena/blob/dbe4ddb10315479fc00086f08e25d968b4b43c49/code/renderer/tr_shader.c#L2935 which was changed in ioquake3.