Software renderer's lighting in GZDoom (and Zandronum)

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Software renderer's lighting in GZDoom (and Zandronum)

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Kate » Tue Jan 29, 2013 9:38 am

also, found a genuine bug here:
Spoiler:
Shaded sprites aren't being rendered with their colors at all.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Gez » Wed Jan 23, 2013 4:39 am

Speaking of maths, here's how the colormaps are generated:

Code: Select all

#define	NUMLIGHTS		32
/*
=====================
=
= RF_BuildLights
=
= 0 is full palette
= NUMLIGHTS	and NUMLIGHTS+1 are all black
=
=====================
*/

void	RF_BuildLights (void)
{
	int		l,c;
	int		red,green,blue, ri, gi, bi;
	byte	*palsrc;
	short	color12,color15;

	for (l=0;l<NUMLIGHTS;l++)
	{
//printf ("%i.",NUMLIGHTS-l);
		palsrc = palette;
		for (c=0;c<256;c++)
		{
			red = *palsrc++;
			green = *palsrc++;
			blue = *palsrc++;

			red = (red*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;
			green = (green*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;
			blue = (blue*(NUMLIGHTS-l)+NUMLIGHTS/2)/NUMLIGHTS;

			lightpalette[l][c] = BestColor(red,green,blue,palette,0,255);
		}

		memcpy (screen,lightpalette[l],256);
		screen+=320;
		memcpy (screen,lightpalette[l],256);
		screen+=320;
		memcpy (screen,lightpalette[l],256);
		screen+=320;
	}
}
(I snipped out the unused code for Doom Alpha's highcolor modes.)

So the formula for the darkest colormap range is (where l = 31, so NUMLIGHTS - l is 1) is:

Code: Select all

(intensity + 16) / 32
So an intensity of 0 yields 0.5, and an intensity of 255 yields 8.46875.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Enjay » Tue Jan 22, 2013 2:25 pm

Gez wrote:If you want some place to be fully dark, you can give it black textures
Heh, I have actually done that in the past. It's not as convenient or as flexible as being able to do it just with sector light levels though.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Gez » Tue Jan 22, 2013 2:11 pm

If you want some place to be fully dark, you can give it black textures in addition to 0 light. Add a #000001 fog color (absurdly dark blue) if so you want.

You can also modify the COLORMAP, but that'll only affect software.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Enjay » Tue Jan 22, 2013 1:51 pm

I agree. That's why I said I don't like it from a mapping PoV. Existing maps that rely on you being able to see something at 0 light would be hampered by being in genuine 100% darkness. However, from an editing perspective, not being able to create somewhere that has absolutely no light even if that's exactly what you want and what would work in a particular situation is a limitation - albeit not one that has a huge implication most of the time. In fact, Doom's overall non-linear light-to-dark progression is pretty wacky too.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Kate » Tue Jan 22, 2013 1:08 pm

yeah it is, I missed a 0 in there, should be 0.05882.

And one of the serious problems with making the darkest lightmap total darkness is that doom2 actually *relies* on you being able to see in the dark in quite a few areas, for example the dark rooms on map10 refueling base wind up becoming "fumbling around in the dark searching for doors" rooms, and on map12 the factory you would *never* be able to find the BFG in the far corner. So for gameplay purposes, having total blackness is *really* a bad idea since it means you have NO clue where you're going or what is shooting at you until it's literally in front of your face.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Enjay » Tue Jan 22, 2013 11:11 am

I have to admit, it always bugged me that 0 darkness in Doom wasn't really 0. Not saying that an emulation of the original lighting shouldn't try to have the Doom behaviour. It's just that I personally find it unwelcome from a mapping POV.

Oh, and
Kate wrote:Actually, I decided to do a little more experimentation, and I found that 0.5882 is a lot closer to what software probably used as a lower cap.
...
we find that 7 / 119 = 0.05882352941176470588235294117647, or 0.05882 rounded. so the lowest colormap is about 5.8% as bright as the fullbright colormap.
I assume that the 0.5882 is a typo.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Kate » Tue Jan 22, 2013 9:52 am

Actually, I decided to do a little more experimentation, and I found that 0.5882 is a lot closer to what software probably used as a lower cap. I figured this one out by looking at the colormap itself and doing some math.

So index 8 (dark grey) turns to index 0 (black) between indexes 98 and 99, so around 119 RGB. So now the math. Index 8 is 7 RGB, so doing some color difference to figure out the difference in scale, we find that 7 / 119 = 0.05882352941176470588235294117647, or 0.05882 rounded. so the lowest colormap is about 5.8% as bright as the fullbright colormap.

Trying those values on a texture, it seems to match more closely:
Spoiler:

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Kate » Tue Jan 22, 2013 8:55 am

Yeah, I mean index 8, because that's what shows up when you use the lowest colormap entry. For reference:
Spoiler:
This is with an Oblige level loaded, so no crazy colormaps, just vanilla doom 2. I set R_Visibility to 0 to force the use of the darkest colormap, to simulate absolute 0 lights so you can see the effect better.

Here, you can clearly see the outlines of a medikit, a zombieman, a bunch of the brighter textures like STARTAN panels, the UAC door, and the GREY* trimmings, and even a blue health bonus to my left using the darker shades of blue.

The solid black textures are METAL and the blue carpet, so of course due to palette limitations they turn solid black since there's not that many dark colors in the palette to begin with, but with GL they would be more visible since the shades can go that low.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Gez » Tue Jan 22, 2013 7:24 am

Kate wrote:In specific, I changed the 0.0 in the final clamp to 0.03125, which is 8/256, or the shade that is closest to black in the doom palette.
Do you mean "closest to black without being black"? Palette indices 0 and 247 are both pure #000000. #070707 is index 8.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Kate » Tue Jan 22, 2013 6:01 am

Bumping this because I noticed a problem with the shader in the current GZDoom SVN:

Code: Select all

[06:25:26] «@Kate» okay found a problem with the new software lighting mode
[06:26:04] «@Kate» unlike software, the gl-software implies that 0 light level literally means “solid inky blackness” which makes it literally impossible to fight in
[06:26:39] «@Kate» in software you still had very faint outlines of enemies, so you could see them coming at you
I fixed this problem by changing how the clamping is applied in vec4 getLightColor in main.fp:

Code: Select all

	#ifdef SOFTLIGHT
		float newlightlevel = 1.0 - R_DoomLightingEquation(lightlevel, gl_FragCoord.z);
		color.rgb *= clamp(vec3(newlightlevel) + dlightcolor, 0.03125, 1.0);
	#endif
In specific, I changed the 0.0 in the final clamp to 0.03125, which is 8/256, or the shade that is closest to black in the doom palette. Well, it's actually (7,7,7), but I figured what they were going for is to have 8 be the lowest shade of color you can see, which is why you get spotted grey/black instead of just black. Changing this makes it possible to see in absolute darkness, so you actually have a fighting chance against enemies like you do in software mode.

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Nash » Wed Jan 02, 2013 4:45 pm

From an end-user perspetive, it's no different than having to restart GZDoom to switch between OpenGL and software. I don't see the issue here.

So umm... I appreciate the patch but you are going to merge it into GZDoom aren't you? That's why you even raised the topic in the first place right?

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Gez » Wed Jan 02, 2013 4:28 pm

Nash wrote:
Gez wrote:I could make the banded/smooth softlight togglable by CVAR, but you still have to quit and restart GZDoom because there doesn't seem to be a simple way to recompile the shaders from a CUSTOM_CVAR.
YES PLEASE!!! :D
Here you go then.

Since there is no simple, non-hacky way of getting shaders to recompile when the CVARs are changed (and the only way to force recompilation is to quit and restart), I find this kinda useless, to be honest.
Attachments
shadercvars.zip
(1.34 KiB) Downloaded 59 times

Re: Software renderer's lighting in GZDoom (and Zandronum)

by Nash » Tue Jan 01, 2013 1:46 pm

The banding changes with your view pitch. Think of it as a really low-res version of GZDoom's default fog.

Top