UDMF's Sidedef Light is Ignored without Fake Contrast

[NeuralStunner]

Posted in the hope that this is simple enough something can actually be done.

Load up the included map in GZDoom and observe the opposite wall. A large patch of the center should be brighter than the rest. This wall has its "light" property set to add 128 to its light level.

Now, go into Options -> Display options -> OpenGL Options -> Preferences, and switch "Fake Contrast" on and off. You should notice nothing change, except that the wall is no longer bright.

Note that the other walls remain the same regardless, because a MapInfo is included which turns on EvenLighting for this map. It will work perfectly in software, as there is no Fake Contrast option.

Since EvenLighting and vid_contrast=0 do basically the same thing, I and others figured it was a bug. Note that I tested this as far back as 1.3.3 (r566) and had the same problem.

[Gez]

Posted in the hope that this is simple enough something can actually be done.

Yeah, I think even I can solve that one.

Since EvenLighting and vid_contrast=0 do basically the same thing

Not really. Vid_contrast affects the entire screen even in windowed mode (try it, it's freaky).


Please report in case any problem arises from the change in r790.

[NeuralStunner]

Thank you, glad it wasn't too far into the GL code. (That's all I meant, sorry if I sounded a little insulting back there.)

Not really. Vid_contrast affects the entire screen even in windowed mode (try it, it's freaky).

I meant "gl_fakecontrast", sorry.

Please report in case any problem arises from the change in r790.

Will do.

[Gez]

No offense taken, I was just commenting on why I would try fixing that despite having repeatedly declared I would not change GL code.

Here it was a simple affair. It works when gl_fakecontrast is on, and doesn't when it's false. There is only one function which references that CVAR in the code, so the issue happens there. Then just a couple of minute to find out where the sidedef's light value is referenced in that function and change it to refer to it even if gl_fakecontrast is off. It's a simple question of logic, rather than actual rendering code, since it's just computing some values for light level, not drawing anything anywhere.

There are still potential issues though because, for example, if the sector brightness is 255 and the light value is negative (is it even allowed? I think it is but I'm not sure), this won't show. I think it will not work either in fog, if I understand the code correctly. But these other two conditions are true whether or not fake contrast is on, so I'm more reluctant to change that.

[NeuralStunner]

There are still potential issues though because, for example, if the sector brightness is 255 and the light value is negative (is it even allowed? I think it is but I'm not sure), this won't show.

Yes, negative light is fine, unless sector light is 255 (Fake contrast or no). However, it will work with light 254, which is pretty much as good as 255. So... is there special light handling for full bright sectors?

[Graf Zahl]

Yes, there is. And Gez's fix wasn't done right.
A proper fix can only be done in the underlying side_t::GetLightLevel function. The GL related code was just a hack to work around some lighting issues - but it no longer works with user settable relative wall lighting unless some changes are made.

[Gez]

One idea I had was to change precisely that, in this way:

Code: Select all

int side_t::GetLightLevel (bool foggy, int baselight) const
{
	if (Flags & WALLF_ABSLIGHTING) 
	{
		baselight = (BYTE)Light;
	}
	else
	{
		baselight += this->Light;
	}

	if (!foggy) // Don't do relative lighting in foggy sectors
	{
		if (!(Flags & WALLF_NOFAKECONTRAST))
		{
			if (((level.flags2 & LEVEL2_SMOOTHLIGHTING) || (Flags & WALLF_SMOOTHLIGHTING) || r_smoothlighting) &&
				linedef->dx != 0)
			{
				baselight += int // OMG LEE KILLOUGH LIVES! :/
					(
						(float(level.WallHorizLight)
						+abs(atan(float(linedef->dy)/float(linedef->dx))/float(1.57079))
						*float(level.WallVertLight - level.WallHorizLight))
					);
			}
			else
			{
				baselight += linedef->dx==0? level.WallVertLight : 
							 linedef->dy==0? level.WallHorizLight : 0;
			}
		}
	}
	return clamp(baselight, 0, 255);
}

However, I didn't because it's a change that would also affect the ZDoom-side of things (i.e., if that's what should be done, then it should also be done in ZDoom) and I don't understand fully that function (why the cast to BYTE for example; is it truly needed even though there is a clamp at the end?). So I preferred to be conservative and just hack the OpenGL hack, so all the hackery remains in just one place. :p

[Graf Zahl]

Don't worry, I have already done what's needed. I'll just need to test it first.