Software renderer's lighting in GZDoom (and Zandronum)

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

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

Postby Xtyfe » Fri Dec 21, 2012 2:38 pm

Holy crap, a major addition to GZDoom? Never thought i'd see the day again
User avatar
Xtyfe
Neque Deos, Neque Dominos
 
Joined: 15 Dec 2007
Location: The Intertubes

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

Postby Woolie Wool » Fri Dec 21, 2012 3:08 pm

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
Woolie Wool
Call Apogee Say "Snappity!"
 
Joined: 15 Dec 2003
Discord: Woolie Wool#9878
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby GFD » Fri Dec 21, 2012 10:33 pm

Well I'm absolutely in love with this wow
User avatar
GFD
My brain's probably worth a lot of money!
 
Joined: 01 Jun 2010
Location: Canada

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

Postby Xtyfe » Sun Dec 23, 2012 1:23 pm

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?
User avatar
Xtyfe
Neque Deos, Neque Dominos
 
Joined: 15 Dec 2007
Location: The Intertubes

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

Postby Korshun » Sun Dec 23, 2012 1:54 pm

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 :(.
Korshun
 
Joined: 13 Dec 2012

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

Postby Graf Zahl » Sun Dec 23, 2012 1:59 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Gez » Sun Dec 23, 2012 5:42 pm

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...
Gez
 
 
 
Joined: 06 Jul 2007

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

Postby Korshun » Mon Dec 24, 2012 11:08 am

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...
Korshun
 
Joined: 13 Dec 2012

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

Postby Blox » Mon Dec 24, 2012 11:36 am

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
Blox
I am Laziness Incarnate!
 
Joined: 22 Sep 2010
Location: Apathetic Limbo

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

Postby Xtyfe » Mon Dec 24, 2012 12:25 pm

Build 1496 is up, I can't tell the difference
User avatar
Xtyfe
Neque Deos, Neque Dominos
 
Joined: 15 Dec 2007
Location: The Intertubes

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

Postby Enjay » Mon Dec 24, 2012 12:33 pm

No? 1496 is definitely brighter.

Screenshots taken in 1493 and 1496 with identical settings:

Image
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby Xtyfe » Mon Dec 24, 2012 12:52 pm

Well, I stand corrected :D
User avatar
Xtyfe
Neque Deos, Neque Dominos
 
Joined: 15 Dec 2007
Location: The Intertubes

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

Postby Woolie Wool » Mon Dec 24, 2012 1:01 pm

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.)
User avatar
Woolie Wool
Call Apogee Say "Snappity!"
 
Joined: 15 Dec 2003
Discord: Woolie Wool#9878
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Korshun » Mon Dec 24, 2012 1:18 pm

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
 
Joined: 13 Dec 2012

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

Postby Korshun » Wed Dec 26, 2012 2:56 pm

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 allExpand view
// 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;
Korshun
 
Joined: 13 Dec 2012

PreviousNext

Return to General

Who is online

Users browsing this forum: No registered users and 3 guests