Software renderer's lighting in GZDoom (and Zandronum)

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

Software renderer's lighting in GZDoom (and Zandronum)

Post 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.
Last edited by Korshun on Mon Dec 24, 2012 11:41 am, edited 14 times in total.
Gez
 
 
Posts: 17652
Joined: Fri Jul 06, 2007 3:22 pm

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
Blox
Posts: 3728
Joined: Wed Sep 22, 2010 9:35 am
Location: Apathetic Limbo

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
SFJake
Posts: 530
Joined: Sat Nov 03, 2007 11:28 am

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
BouncyTEM
Posts: 3814
Joined: Sun Aug 24, 2003 5:42 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: 2280 Lol Street: The Calamitous Carnival (formerly Senators Prison)

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
ibm5155
Posts: 1268
Joined: Wed Jul 20, 2011 4:24 pm

Re: Software renderer's lighting in GZDoom

Post by ibm5155 »

isn´t the same as normal opengl render with doom fog and not dark fog?
Gez
 
 
Posts: 17652
Joined: Fri Jul 06, 2007 3:22 pm

Re: Software renderer's lighting in GZDoom

Post 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".
User avatar
BouncyTEM
Posts: 3814
Joined: Sun Aug 24, 2003 5:42 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: 2280 Lol Street: The Calamitous Carnival (formerly Senators Prison)

Re: Software renderer's lighting in GZDoom

Post by BouncyTEM »

Also worth noting this instantly crashes Gzdoom if you use the R_Visibility console command. Not good.
User avatar
Nash
 
 
Posts: 17296
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: Software renderer's lighting in GZDoom

Post 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.
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

Re: Software renderer's lighting in GZDoom

Post 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.
Gez
 
 
Posts: 17652
Joined: Fri Jul 06, 2007 3:22 pm

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
Enjay
 
 
Posts: 26410
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: Software renderer's lighting in GZDoom

Post 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.
User avatar
Nash
 
 
Posts: 17296
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: Software renderer's lighting in GZDoom

Post 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)
User avatar
shoober
Posts: 61
Joined: Sat Dec 01, 2012 12:08 am

Re: Software renderer's lighting in GZDoom

Post 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.
Korshun
Posts: 52
Joined: Thu Dec 13, 2012 1:32 pm

Re: Software renderer's lighting in GZDoom

Post 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...

Return to “General”