Software renderer's lighting in GZDoom (and Zandronum)
- 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)
Holy crap, a major addition to GZDoom? Never thought i'd see the day again
- 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)
This is why you think of what your game will look like and what colors it will use before you start.Korshun wrote:Conclusion: palettes are good for art style but palettes suck when they become technical limitations.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).
- 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)
Well I'm absolutely in love with this wow
- 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)
Were any of these fixed for the official release?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.
Re: Software renderer's lighting in GZDoom (and Zandronum)
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 .
- Graf Zahl
- 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)
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.
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.
Re: Software renderer's lighting in GZDoom (and Zandronum)
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.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...).
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...
Re: Software renderer's lighting in GZDoom (and Zandronum)
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 .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...
Also, turned out that Zandronum downloads still point to the old version with liteamp bug . Damn, fixing the links...
Re: Software renderer's lighting in GZDoom (and Zandronum)
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.
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.
- 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)
Build 1496 is up, I can't tell the difference
Re: Software renderer's lighting in GZDoom (and Zandronum)
No? 1496 is definitely brighter.
Screenshots taken in 1493 and 1496 with identical settings:
Screenshots taken in 1493 and 1496 with identical settings:
- 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)
Well, I stand corrected
- 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)
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.)
(Not to mention your eyes don't see color well in the dark.)
Re: Software renderer's lighting in GZDoom (and Zandronum)
Probably the best way to tell the difference between different light constants is the start of MAP04 without textures:
Correct constant (232):
Incorrect constant (192):
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.
Correct constant (232):
Incorrect constant (192):
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.
Re: Software renderer's lighting in GZDoom (and Zandronum)
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.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.
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;