Page 1 of 7

Software renderer's lighting in GZDoom (and Zandronum)

PostPosted: Sat Dec 15, 2012 3:39 pm
by Korshun
Hello, it may seem strange to make this my first post. The secret is that I have been dooming for 4 years and wansn't here because of laziness, etc... whatever...

Ever since discovering GZDoom, I was disappointed with its lighting. It doesn't bright up close areas, far areas looks uniform and contrastless and too dark compared to software renderer, making maps look dull. And no configuration in GZDoom can fix that (except making everything fullbright, heh). Yet OpenGL renderer is better than software renderer at everything else. I had to choose between "good lighting" and "good everything else but bad lighting". But now I don't have to!

I have modified GZDoom's OpenGL renderer to have lighting exactly like in software renderer! Big thanks to EDGE developers for actually caring about lighting and providing a ready-to-use doom lighting formula.

Spoiler: Technical info


WARNING: needs good OpenGL shader support to work.

Official page with screenshots and downloads:
http://submarine.homeunix7.org/doku.php ... _in_opengl

Download links:


Zandronum Windows
Zandronum Source code
(linux binaries coming soon, they are not made by me but by Monsterovich)

GZDoom downloads (obsolete, it is added to GZDoom 1.7.0 :)):
GZDoom Windows
GZDoom Linux
GZDoom Source code

Spoiler: User Guide


Version list (using totally internal and unrelated versioning scheme):

Zandronum V2.4:
  • Fixed liteamp not affecting sprites.
Zandronum V2.3: first released version.

GZDoom V2.4:
  • Lighting was not bright enough, fixed that, now light bands in blocky mode match the ones in software renderer .
  • Fixed weapons not getting brighter when firing.
  • Fixed objects becoming pitch-black when the camera is too close.
GZDoom V2.3: first released version.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 4:12 pm
by Gez
This looks interesting; however aren't there license issues with that? Did you clear it with Andrew Apted? EDGE is a GPL port and GZDoom contains code under licenses legally incompatible with the GPL.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 4:20 pm
by Blox
Screenies for the lazy (The quality is messed up, but we're talking about general lighting so it's OK.)

But yeah, this definitely looks interesting.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 5:14 pm
by SFJake
My my, I would LOVE if this was part of GZDoom officially (and properly)

I always wanted this, but figured it just was not (easily) possible.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 6:35 pm
by BouncyTEM
The possible licensing issues on this concern me, but I really, really love that it's been done.
Nice first post, sir, though I do feel we might need a clean-room reverse engineering via Gez + Blzut3 or something.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 6:37 pm
by ibm5155
isn´t the same as normal opengl render with doom fog and not dark fog?

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 6:52 pm
by Gez
So the EDGE code apparently is only in the shader code itself (main.fp), not in the C++ code. That means it doesn't get in gzdoom.exe, but in gzdoom.pk3. It probably doesn't change anything on the licensing point, though.

However, it seems said code is ultimately derived from the Doom utilities formula to generate the COLORMAP.


As for the C++ code, it does feature some problems, mostly enforcing this lighting mode by disabling all others, regardless of user and map settings. This is not acceptable in GZDoom itself. Do keep in mind that some levels have actually been designed for GZDoom rather than vanilla, and require a lighting mode other than "Doom".

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 7:41 pm
by BouncyTEM
Also worth noting this instantly crashes Gzdoom if you use the R_Visibility console command. Not good.

Re: Software renderer's lighting in GZDoom

PostPosted: Sat Dec 15, 2012 11:54 pm
by Nash
Looks close... but it's still not 1:1. Good job though! Would love to see the software lighting banding recreated in OpenGL.

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 5:33 am
by Korshun
Gez wrote:So the EDGE code apparently is only in the shader code itself (main.fp), not in the C++ code.

Actually there's a small bit that changes hud weapon's light level so it is like in software renderer. Also rendering of sprites lit by dynamic lights should use software light calculation for best results. BTW: how do I get distance from camera to currently rendered sprite?

Gez wrote:As for the C++ code, it does feature some problems, mostly enforcing this lighting mode by disabling all others, regardless of user and map settings.

I didn't know how to recompile shaders on lightmode change :(. As for general dirtiness, I just wanted it to work ASAP.

ibm5155 wrote:isn´t the same as normal opengl render with doom fog and not dark fog?

No. It's impossible to recreate software renderer's lighting using GZDoom's options.

Bouncy wrote:Also worth noting this instantly crashes Gzdoom if you use the R_Visibility console command. Not good.

Wait... what? r_visibility worked in OpenGL? I thought it only affects software renderer... *checks*
Vanilla GZDoom 1.5.6: nothing happens.
Vanilla GZDoom 1.6.0: crash.
Modified GZDoom 1.6.0: crash.

Looks like it is not my fault but my fault is that I don't know how to make r_visibility behave like in software rendeder. But if anything is too dark, you still have OpenGL renderer's ambient light level.

Nash wrote:Looks close... but it's still not 1:1. Good job though! Would love to see the software lighting banding recreated in OpenGL.

Just replace gzdoom.pk3 with gzdoom-blocky.pk3.

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 5:44 am
by Gez
You should have based your code on the latest SVN and you wouldn't get the r_visibility crash. I fixed that bug back in July.

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 5:49 am
by Enjay
This does actually look very nice. I hope things can be cleaned up so that it can be added to GZDoom proper. I really don't like the "blocky" version though. That's one of the things that I am happy to leave in the past.

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 8:22 am
by Nash
The "blocky" option should be built into the game and switchable in-game somehow, as opposed to using a separate base PK3. I wonder if it's possible to switch between the 2 different fragment shaders while the game is running?

Anyway, just tried it in-game running around the vanilla levels. Nice stuff! Keep it up. :D The experience of running around with banding in an OpenGL renderer is surreal. Considering it has been said so many times in the past that it was "impossible". :O

Would love to see this merged into GZDoom officially.

(And yeah you should be working off the trunk on the SVN :D)

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 9:30 am
by shoober
Blox wrote:Screenies for the lazy (The quality is messed up, but we're talking about general lighting so it's OK.)


Based on those screenshots, I think i'll stick with the software render. You can still tell that software mode renders lightning in its own special way that OpenGL just can't emulate. Nice effort though. Maybe it in the future it will be closer.

I went through the same dilemma when I was choosing between ZDoom and GZDoom, but I went with ZDoom because its a more authentic experience visually.

Re: Software renderer's lighting in GZDoom

PostPosted: Sun Dec 16, 2012 11:15 am
by Korshun
A small update
  • Lighting was not bright enough, fixed that, now light bands in blocky mode match the ones in software renderer :D.
  • Fixed weapons not getting brighter when firing.
  • Fixed objects becoming pitch-black when the camera is too close.

Enjay wrote:I really don't like the "blocky" version though. That's one of the things that I am happy to leave in the past.

Same :).

Enjay wrote:The "blocky" option should be built into the game and switchable in-game somehow, as opposed to using a separate base PK3. I wonder if it's possible to switch between the 2 different fragment shaders while the game is running?

100% sure it is. I just don't know GZDoom's code well enough and I all want is to play with software lighting in OpenGL. Of course, the proper way would be to make 2 new lightmodes, etc... For now it is okay for me to keep both GZDooms.

shoober wrote:Based on those screenshots, I think i'll stick with the software render. You can still tell that software mode renders lightning in its own special way that OpenGL just can't emulate. Nice effort though. Maybe it in the future it will be closer.

What exactly are you talking about? I still see nothing in software lighting what can't be emulated in OpenGL. Also, the previous version was not bright enough. Try it out again. Gotta retake screenshots...