GZDoom 1.7.0 released

Downloading. Yeah baby, yeah! /Austin Powers

Daaaamn. The lighting constant is still 192 in the release so the lighting is too dark :(. It should be 232 to match the software renderer exactly!

(actually it is my fault, I should have tested my hack more before first release with wrong constant :( )

YAY, GZDoom independent progress!

The source code can’t be downloaded.

Manc disabled the WebSVN feature used to generate tarballs of the source code because it kinda killed the whole server somehow. Apparently, WebSVN is full of memory leaks everywhere.

Quick hack of glboom-plus for support of new lighting mode by Andrew Apted/Korshun ("shaders" sector lighting mode in settings)
http://prboom-plus.sourceforge.net/test.zip

Korshun said:

Daaaamn. The lighting constant is still 192 in the release so the lighting is too dark :(. It should be 232 to match the software renderer exactly!

What is lighting constant? Do you mean this?
float index = (59.0/31.0 - L) - (scale * 232.0/31.0 - 232.0/31.0);

Korshun said:

Daaaamn. The lighting constant is still 192 in the release so the lighting is too dark :(. It should be 232 to match the software renderer exactly!

(actually it is my fault, I should have tested my hack more before first release with wrong constant :( )

You're my hero sir. I was in pretty much the same state as you, I missed so much the "dark fog", yet I just couldn't go back to software rendering.

entryway said:

Quick hack of glboom-plus for support of new lighting mode by Andrew Apted/Korshun ("shaders" sector lighting mode in settings)
http://prboom-plus.sourceforge.net/test.zip

Will check this out in a bit. (Any chance of getting the spectre/fuzz rendering shaders too?)

Edit: Very cool, tried it out in both GZDoom and GLBoom. Nice work Korshun, this really improves the look of the hardware renderers. (I wonder if I can make more faithful lighting for the PSX TC by modifying this?)

So, can I download the source code without downloading it file by file?

svn co http://mancubus.net/svn/hosted/gzdoom/tags/1.7.00/ path\where\you\want\it\

Thank you.
Are the warnings stored somewhere?

Ha, make stopped:

[ 75%] Building CXX object src/CMakeFiles/zdoom.dir/gl/data/gl_data.o
In file included from gzdoom.1.7.0/src/gl/renderer/gl_lightdata.h:6:0,
                 from gzdoom.1.7.0/src/gl/data/gl_data.cpp:56:
gzdoom.1.7.0/src/gl/renderer/gl_colormap.h: In member function ‘void FColormap::GetFixedColormap()’:
gzdoom.1.7.0/src/gl/renderer/gl_colormap.h:57:56: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
gzdoom.1.7.0/src/gl/data/gl_data.cpp: At global scope:
gzdoom.1.7.0/src/gl/data/gl_data.cpp:339:1: error: ‘boolean’ does not name a type
gzdoom.1.7.0/src/gl/data/gl_data.cpp: In function ‘void InitGLRMapinfoData()’:
gzdoom.1.7.0/src/gl/data/gl_data.cpp:370:24: error: ‘IsLightmodeValid’ was not declared in this scope
gzdoom.1.7.0/src/gl/data/gl_data.cpp: In function ‘void Cmd_gl_resetmap(FCommandLine&, APlayerPawn*, int)’:
gzdoom.1.7.0/src/gl/data/gl_data.cpp:382:24: error: ‘IsLightmodeValid’ was not declared in this scope
make[2]: *** [src/CMakeFiles/zdoom.dir/gl/data/gl_data.o] Erreur 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Erreur 2
make: *** [all] Erreur 2

A lib is missing?

Get the latest trunk.
The 1.7.0 source only compiles on Windows.

OK, this one works.

entryway said:

Quick hack of glboom-plus for support of new lighting mode by Andrew Apted/Korshun ("shaders" sector lighting mode in settings)
http://prboom-plus.sourceforge.net/test.zip

Nice news! (but weapon flashes are way too bright for some reason)

entryway said:

What is lighting constant? Do you mean this?
float index = (59.0/31.0 - L) - (scale * 232.0/31.0 - 232.0/31.0);

Yes, exactly. In the later versions of my shader it is moved to #define DOOMLIGHTFACTOR, and changing this constant results in effects similar to changing r_visibility.

Dragonsbrethren said:

(I wonder if I can make more faithful lighting for the PSX TC by modifying this?)

With pixel shaders you can implement ANY lighting formula. Just replace R_DoomLightingEquation in the shader, it is the function that defines the dependency between distance, sector light level and on-screen light level. I am completely unaware about lighting in PSX Doom (except that PSX Doom has colored lighting unlike vanilla) but if it is not so different from vanilla doom, you may get away with modifying EDGE's formula.

PSX Doom is pretty faithful about replicating the original distance fading, but its lighting is much brighter overall. In fact, higher values actually look like overbrights in Quake:

(Jump to 1:20. Quality's low, but you can see the strong distance fading and practically glowing walls.)

entryway said:

Quick hack of glboom-plus for support of new lighting mode by Andrew Apted/Korshun ("shaders" sector lighting mode in settings)

I'm not claiming any credit for that.

While it's true that EDGE had lighting like this several years ago, the main innovation with EDGE was to store the lighting in a texture (which can be clamped), whereas Korshun's method is doing the DOOM lighting equation directly in a fragment shader.

Interestingly, Korshun went and toyed with using a texture too, but in a later version than what made its way in GZDoom. (And it's actually commented out.)

/*
GLuint CreateColormapsTexture()
{
	// Korshun: generate a "colormaps" texture.
	GLubyte colormaptex[33 * 3];
	for (int i = 0; i <= 32; i++)
	{
		float lightlevel = i * 8.0;
		float light = 192.f - (192-lightlevel)* 1.95f;
		colormaptex[i * 3] = light;
		colormaptex[i * 3 + 1] = light;
		colormaptex[i * 3 + 2] = light;
	}

	GLuint out;
	gl.GenTextures(1, &out);
	gl.BindTexture(GL_TEXTURE_1D, out);

	glTexImage1D(GL_TEXTURE_1D, 0, 3, 33, 0, GL_RGB, GL_UNSIGNED_BYTE, colormaptex);

	return out;
}
*/

(This is in gl_renderstate.cpp from gzdoom-swlight-v2.4-src.zip. This is not in any official revision of GZDoom.)

Is that anything like what EDGE uses?

Awesome.

Yay finally Doomworld works again!

Dragonsbrethren said:

PSX Doom is pretty faithful about replicating the original distance fading, but its lighting is much brighter overall. In fact, higher values actually look like overbrights in Quake

From having watched the video, I think that PSX Doom's lighting is not faithful and is simpiler than in vanilla doom.

To me it seems to work like this:
1) there's min and max light levels defined by sector's light level, max light level may be overbright (max sector light level results in 2x overbright max light level).
2) there's a gradient from max to min light level and this gradient is always at the same distance regardless of light level.

Keep in mind that I have never played PSX Doom :/.

Gez said:

Interestingly, Korshun went and toyed with using a texture too, but in a later version than what made its way in GZDoom. (And it's actually commented out.)

Is that anything like what EDGE uses?

Okay, someone found out about my abandoned plans :). I guess I should explain it properly.

Back when I was planning swlight, I thought that light levels on indivudual colormaps in the COLORMAP lump do not fade linearly (now I know they do (except for minor palette artifacts)). Also there may be custom colormaps that can be used, for example, to implement colored lighting or fog in vanilla doom and Boom. Especially Boom, because it can switch colormaps by map triggers.

My useless plan was to implement colormaps' effects in true color OpenGL in a better way than in GZDoom (for example the fog on the first map of FreeDoom doesn't look like fog at all in GZDoom, with my way it would look like fog).

For every colormap:
1) Somehow find the difference between original and remapped color.
2) Average the differencies.
3) Put the averaged value into one pixel of the special 1D texture.
Every texel of this special texture represents the color every colormap is supposed to fade to. Then just use light level as the texture coordinate and multipy the color by the color from texture.

Then I found out that all IWAD colormaps actually represent linear gradients from white to black and that light level correction is only needed when lighting is uniform and not when lighting is like in software renderer so I don't need to implement all this for the software lighting to look good :/. And why bother with implementing such a complex thing just for some very rare examples of custom colormaps in wads I don't even know about? That's too much work for too little gain.

Forget it, it is just an idea about custom colormap implementation in true color renderer. It is useless. It is not at all needed for software renderer's lighting in OpenGL. And I am absolutely sure this is not anything like what EDGE does.

Dragonsbrethren said:

I wonder if I can make more faithful lighting for the PSX TC by modifying this?

I wonder if floor and wall distance fading can differ from each other, as you'd need this for accurate PSX Doom lighting.

Gez said:

Interestingly, Korshun went and toyed with using a texture too, but in a later version than what made its way in GZDoom. (And it's actually commented out.)

(Code stuff here....)

Is that anything like what EDGE uses?

Not really.

EDGE does actually use the colors from a colormap (usually the COLORMAP lump, but it can be from one of the BOOM specials) when creating the lighting texture. Also the texture is two dimensional (distance is one axis, sector light level is the other).

Thank you VERY much, Korshun.

I will try it out tomorrow, but I'm very glad somebody took responsibility for GZDoom's AWFUL lighting - no thanks to Mr. Arrogant; Graf Zahl and friends >:

Cheers, Korshun.

edit: ick

As for the shader, sadly my performance still struggles with all the shader lighting modes, so I still resort to the -sm3 switch to get basic lighting, but this mode definitely looks cool, good job.