Software renderer's lighting in GZDoom (and Zandronum)

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
User avatar
Xtyfe
Posts: 1480
Joined: Fri Dec 14, 2007 6:29 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support

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

Post by Xtyfe »

Holy crap, a major addition to GZDoom? Never thought i'd see the day again
User avatar
Woolie Wool
Posts: 1713
Joined: Mon Dec 15, 2003 3:36 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Arch Linux, Windows 11
Graphics Processor: nVidia with Vulkan support
Contact:

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

Post by Woolie Wool »

Korshun wrote:
Woolie Wool wrote: I think palettes can be a very powerful tool if you are conscious of your palette and preferably design it specifically for your mod. For Operation Serpent I made a new palette and every color was carefully chosen. A well-done palette that all your graphics adhere to is a great way to unify the art style of your project.

(my colormap kind of sucks though and it seems like it's not going to be possible to fix it without hand-tuning because the RGB algorithms that SLADE3 and XWE use are pretty dodgy and the CIE ones are worse).
Conclusion: palettes are good for art style but palettes suck when they become technical limitations.
This is why you think of what your game will look like and what colors it will use before you start.
User avatar
GFD
Posts: 347
Joined: Mon May 31, 2010 7:42 pm
Preferred Pronouns: He/Him
Location: Canada
Contact:

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

Post by GFD »

Well I'm absolutely in love with this wow
User avatar
Xtyfe
Posts: 1480
Joined: Fri Dec 14, 2007 6:29 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support

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

Post by Xtyfe »

Korshun wrote: A list of bugs you may already know about:
  • Textured automap is fullbright in "Software" lightmode.
  • Weapon sprite is always fullbright in "Software" lightmode.
  • The constant to correct depth in the shader should be 232 instead of 192. I changed it to 232 in the newer versions of gzdoom-swlight but SVN has 192 so the lighting is too dark.
  • Dynamic lights make sprites fullbright in "Software" lightmode.
Were any of these fixed for the official release?
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

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

Post by Korshun »

The automap got fixed and dynamic lighting of sprites is now done how it was meant to be done (much better than in my GZDoom version). But weapon sprite's light level is the same as in other lightmodes and worst of all, the lighting constant is still 192, so the lighting is too dark compared to software renderer :(.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

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

Post by Graf Zahl »

Damn, I had to revert the shader changes once yesterday evening and the constant got reverted with it.

Concerning the weapon lighting. What needs to be done there? I have to admit that this was the one part I was unable to figure out so I just switched back to the old code for it. I thought it's better like this than not working at all.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

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

Post by Gez »

Korshun wrote: Also, I didn't report this back in the day but I think I should report it now: the lines on textured automap in OpenGL renderer are misaligned with the textured polygons.This bug was introduced with the textured automap. In swlight I hackfixed it by simply offseting all lines by one pixel (maybe it should be half...).
This approach is not acceptable because the function you've hacked is not used only by the automap; and it would make more sense to change the values at their source rather than in the drawing routine.

Also who says the lines are what is at fault here? It's equally possible that it is the polygons that are misaligned and that should be shifted a bit...
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

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

Post by Korshun »

Gez wrote: This approach is not acceptable because the function you've hacked is not used only by the automap; and it would make more sense to change the values at their source rather than in the drawing routine.

Also who says the lines are what is at fault here? It's equally possible that it is the polygons that are misaligned and that should be shifted a bit...
I thought about all this... Especially about polygons being offset instead of lines. That's why it is a hackfix ;). Also now my GZDoom version is useless so no harm caused by hackfixing this ;).

Also, turned out that Zandronum downloads still point to the old version with liteamp bug :shock: . Damn, fixing the links...
User avatar
Blox
Posts: 3728
Joined: Wed Sep 22, 2010 9:35 am
Location: Apathetic Limbo

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

Post by Blox »

If you're talking about 2.3 being the fixed version, then I can tell you that the fog completely disregards ambient lighting settings.

And as something to think about, it'd be nice if there was a sector brightness multiplier. Because the current ambient light setting is kind of a Min(x,y) thing, which can look pretty terrible from map to map.
User avatar
Xtyfe
Posts: 1480
Joined: Fri Dec 14, 2007 6:29 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support

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

Post by Xtyfe »

Build 1496 is up, I can't tell the difference
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

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

Post by Enjay »

No? 1496 is definitely brighter.

Screenshots taken in 1493 and 1496 with identical settings:

Image
User avatar
Xtyfe
Posts: 1480
Joined: Fri Dec 14, 2007 6:29 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support

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

Post by Xtyfe »

Well, I stand corrected :D
User avatar
Woolie Wool
Posts: 1713
Joined: Mon Dec 15, 2003 3:36 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Arch Linux, Windows 11
Graphics Processor: nVidia with Vulkan support
Contact:

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

Post by Woolie Wool »

I really like this new feature, but I was thinking it might be even better with an optional setting to desaturate colors as it gets darker and darker, to bring in even more of a "software" look.

(Not to mention your eyes don't see color well in the dark.)
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

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

Post by Korshun »

Probably the best way to tell the difference between different light constants is the start of MAP04 without textures:

Correct constant (232):
Image

Incorrect constant (192):
Image

Notice that with correct constant the nearest wall has uniform max light level yet the door is a gradient. With incorrect constant the nearest wall is darkened. In software renderer/blocky swlight the nearest wall has only one light band on the very last pixel of texture and this light band is invisible in software renderer because of palette.
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

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

Post by Korshun »

Graf Zahl wrote:Damn, I had to revert the shader changes once yesterday evening and the constant got reverted with it.

Concerning the weapon lighting. What needs to be done there? I have to admit that this was the one part I was unable to figure out so I just switched back to the old code for it. I thought it's better like this than not working at all.
I have figured it out. The fix is very simple. Instead of switching to "Doom" lightmode for the whole weapon rendering function, only switch to it when actually rendering the sprites. This way all weapon light levels calculate correctly in software lightmode and gl_SetSpriteLighting is still unmodified.

Code: Select all

// There are no hacks before this line.

	// hack alert! Rather than changing everything in the underlying lighting code let's just temporarily change
	// light mode here to draw the weapon sprite.
	int oldlightmode = glset.lightmode;
	if (glset.lightmode == 8) glset.lightmode = 2;

	for (i=0, psp=player->psprites; i<=ps_flash; i++,psp++)
	{
		if (psp->state) 
		{
			FColormap cmc = cm;
			if (statebright[i]) 
			{
				if (fakesec == viewsector || in_area != area_below)	
					// under water areas keep most of their color for fullbright objects
				{
					cmc.LightColor.r=
					cmc.LightColor.g=
					cmc.LightColor.b=0xff;
				}
				else
				{
					cmc.LightColor.r = (3*cmc.LightColor.r + 0xff)/4;
					cmc.LightColor.g = (3*cmc.LightColor.g + 0xff)/4;
					cmc.LightColor.b = (3*cmc.LightColor.b + 0xff)/4;
				}
			}

			

			// set the lighting parameters (only calls glColor and glAlphaFunc)
			gl_SetSpriteLighting(vis.RenderStyle, playermo, statebright[i]? 255 : lightlevel, 
				0, &cmc, 0xffffff, trans, statebright[i], true);
			DrawPSprite (player,psp,psp->sx+ofsx, psp->sy+ofsy, cm.colormap, hudModelStep, OverrideShader);

			
		}
	}
	gl_RenderState.EnableBrightmap(false);

	glset.lightmode = oldlightmode;
Post Reply

Return to “General”