Korshun
Newbie
Posts: 9
Registered: 06-12 |
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.
Last edited by Korshun on 12-26-12 at 15:44
|
12-23-12 17:46 
