Page 4 of 7

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

PostPosted: Fri Dec 21, 2012 2:38 pm
by Xtyfe
Holy crap, a major addition to GZDoom? Never thought i'd see the day again

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

PostPosted: Fri Dec 21, 2012 3:08 pm
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.

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

PostPosted: Fri Dec 21, 2012 10:33 pm
by GFD
Well I'm absolutely in love with this wow

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

PostPosted: Sun Dec 23, 2012 1:23 pm
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?

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

PostPosted: Sun Dec 23, 2012 1:54 pm
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 :(.

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

PostPosted: Sun Dec 23, 2012 1:59 pm
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.

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

PostPosted: Sun Dec 23, 2012 5:42 pm
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...

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

PostPosted: Mon Dec 24, 2012 11:08 am
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...

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

PostPosted: Mon Dec 24, 2012 11:36 am
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.

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

PostPosted: Mon Dec 24, 2012 12:25 pm
by Xtyfe
Build 1496 is up, I can't tell the difference

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

PostPosted: Mon Dec 24, 2012 12:33 pm
by Enjay
No? 1496 is definitely brighter.

Screenshots taken in 1493 and 1496 with identical settings:

Image

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

PostPosted: Mon Dec 24, 2012 12:52 pm
by Xtyfe
Well, I stand corrected :D

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

PostPosted: Mon Dec 24, 2012 1:01 pm
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.)

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

PostPosted: Mon Dec 24, 2012 1:18 pm
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.

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

PostPosted: Wed Dec 26, 2012 2:56 pm
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 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;