I've uploaded four FitzQuake 0.80 shots of the classic kjsp1 map. The first set of two shots show the map using original 8-bit textures, lighting and palette with basically no engine configs loaded. The first shot is without overbright lighting (gl_overbright 0) and the 2nd is with it enabled. Gamma is 1 in both cases.

http://user.tninet.se/~xir870k/fitz_orig_ob0.jpg
http://user.tninet.se/~xir870k/fitz_orig_ob1.jpg

The next set of two shots show the map using filtered tga textures (based off the originals), new lighting and idgamma palette (the latter being irrelevant here due to tgas, of course) with my std configs loaded. Again, the first shot is without overbright lighting and the 2nd is with it enabled. Gamma is 0.65 in both cases.

http://user.tninet.se/~xir870k/fitz_tga_ob0.jpg
http://user.tninet.se/~xir870k/fitz_tga_ob1.jpg

To me this shows terrible lighting saturation in the textures in both sets, which is also the expected result of the "overbright" lighting. The lighting is saturated already in the engine, which means that adjusting the monitor or other external tweaking is useless.

Maybe there's something wrong with my graphics card (Geforce3 Ti 200) or setup, but overbright lighting doesn't look very appealing to me. It instead reminds me of using the loudness button on HiFi equipment and claiming that the sound is then "better" ...

The above results are of course not FitzQuake specific; DarkPlaces and WinQuake has the same saturated look. 

Are you sure about that? I'm not saying you're wrong but I don't recall seeing the original Quake's lighting go beyond 100% on a texture surface. You can't get beyond the fullbright value of the textures, can you? 

True, but how to please every engine then, how to do compatiple source lights (delay 2) that still look good? 

blame kjsp textures. they looked fucked even in the standard gl quake with the ID gamma

overbright gives you 100% more light range, not just brighter colors or contrast 

Willem: Sure about what? The shots are representative of how it looks on my system. I'm also not the one claiming that 200% brightness is the "intended" look, but different engines will present different fullbright levels (i.e. having r_fullbright 1). Turning on fullbright in WinQuake is for me abominable to look at, not to mention the pixellation, light banding and other animation/movement distortions.

neg!ke: I've no simple solutions, but I'm very concerned about lighting that ruins textures/skins, being it coloured, overbright or "fullbright pixels". Just like audio, it's essential to keep the signal dynamic range reasonable without any compression artifacts. Getting it right for all preferences or setups is probably impossible.

-_-: There's nothing wrong with the kjsp1 textures, in fact they're outstanding. The problem is how to render them without saturation effects that wipe out the details. A badly configured idgamma palette will also cause problems.

And I chose this map because it illustrates the effect clearly, but it can be seen in any map to different extents. 

aguiRe

Sorry, you posted just before I did apparently. I was asking the original guy who said that Quake did overbrightening in software mode. I didn't think it did but I wanted to find out for sure.

Sorry for the confusion! 

willem: yeah, i'm sure about it. Software quake goes up to 200%. The file colormap.lmp is a lookup table of lighting values for each light level and each palette color, and this table is where overbright lighting (and fullbright pixels) are implemented.

Glquake didn't have overbright, but the creators were aware of this so to compensate they capped the top end of the dynamic range instead of making everything half as bright, so that it at least looks pretty much like quake in most cases.

aguirre: I agree with you that it looks bad in kjsp1. I disagree that kjsp1 is in any way representative of quake maps in general. Probably, killjoy was using glquake, and wanted to make the level look washed out by bright sunlight, so he made the textures extra bright, and in glquake, it looked fine.

Overbright lighting and fullbright pixels are undoubtedly part of quake as id software intended. There is a problem when you get to the era of mappers who thought glquake was the best thing ever, and didn't test their maps in winquake, so they have textures with random fullbright pixels on them, too-bright lighting near skylights, etc. In these cases, the intent of the creator is obviously NOT to have overbright and fullbrights, and luckily those are easily disabled with cvars if they turn out to ruin the level.

r_fullbright looks bad in winquake, but of course it's a developer command so it's not that important.

Side note: I need to figure out why the tgas look different than the wad textures. Seems like it would have to be a fitzquake bug? 

wait, why did you take the second two shots with a different gamma setting? 

this to turn into an argument who's right or wrong, I just wanted to point out that overbright lighting is no cure without shortcomings and to counteract simplified claims like GLQuake looks like "shit" in comparison.

I just used kjsp1 to make the shortcomings obvious, but it can be seen in any map if there are any overbright areas. This is also important; the areas where it's supposed to work, are the same areas where textures might be saturated. You can see this in the shots above; beneath the overbright area, there's a normal wall that looks the same (no saturation) in both cases.

Using fullbright in WQ also shows how the textures are saturated where the overbright lighting is applied, so I think it's appropriate.

Whether id actually intended to have the overbright lighting or fullbright pixels or were just forced to use these tricks due to technical constraints at the time, probably remains hidden in the past. But by the same logic, one might claim that the light banding or pixellation were intended, too ... ;)

My guess is that they wanted something better, but couldn't do it with reasonable costs or performance by the time of development. Possibly also in an attempt to counteract the then rather frequent complaints about Quake being just "dull brown and green".

Why the tgas are more saturated than the 8-bits is probably caused by the total sum of brightening, I've filtered the tgas to be brighter (without saturation in my engines) together with gamma being my normal setting 0.65. This together with overbrights probably becomes too much. Without overbrights, this map looks fabulous with external tgas.

The purpose of my two sets was to show that even in the original and default setup, overbrights cause saturation, while it's then worse with my normal setting and configs. This also shows how sensitive the lighting is, even minor changes to engine/driver/monitor settings may tip it over the edge and create horrible distortion. 

a moderate case:
http://img182.imagevenue.com/img.php?image=22977_overbrightshamb_122_12lo.jpg

Not just ikwhite textures. 

Well I'm glad to hear the tga brightness is becuase you edited them, not becuase fitzquake loads them wrong. :)

As for the rest, it's probably a matter of opinion whether it generally looks good or bad. For me, the higher dynamic range provided by overbright gives more contrast and less flat-looking lighting. The washed-out appearance of brightly lit surfaces is true to my experience in real life, and looks good to me so long as the mapper does a decent job lighting things. (example: the pentagram room in dm3 looks bad, but that is becuase it is badly lit. It also looks bad without overbright.) 

Well Fitz actually loads many tgas upside down, but I'm sure you already know about that ... ;)

Grahf: Yes, that's what I was trying to say before, but the issue probably gets worse if you also use idgamma (which I do). The combination is not nice to look at and alias model shading is basically ruined.

Again, several engines have this problem. 

Well Fitz actually loads many tgas upside down, but I'm sure you already know about that ... ;)

Oh yes, that problem. I actually fixed it recently thanks to browsing your code :) 

Grahf, that shambler has a 32 bit TGA texture that I made alot darker (+contrast, sharpen, other tweaks) but I can't tell from the shot if you had -exttex enabled?

If you did and it still looks like that then its proven what AguirRe was saying before - there's no way to account for all setups. If not then its because of a loading issue? Otherwise I'd recommend using the external skins, they look better in my opinion. 

It says dp next to the shot number - you were just making a point?

Not had the morning coffee yet. 

I think this tool has an option to enable disable overbrightening/saturation 

dont overbright models
software quake doesnt 

software quake does overbright the models too. 

I was just trying to make a quick point, though I didn't consider that warp has external model textures. I'm not sure if the external skin was loaded; whatever the default is (pretty sure they were though). I did have the gamma and contrast turned up a bit to see the darker areas better. Maybe that wasn't the best example. I didn't intend to pick on your map, ijed.

But the point was, it's not just a specific texture set of an old map that looks washed out, but any shambler in a bright room. However I can't think of or find any other maps off hand that have a shambler in a bright room, so I'm going to have to back off of that point.

Oh, Warp run in Darkplaces just fine. 

There's lots else there to pick on anyway. 

There are so many players out there each with his own system for making quake look best, and all of these different user modifications (idgamma, hardware gamma, glquake's -gamma hack, replacement textures, replacement .lit files for stock maps, realtime lighting in stock maps, etc.) don't always interact well.

As someone who runs a very stock setup (fitzquake with hardware gamma correction,) I rarely experience firsthand the problems caused by various modifications interacting with some features. People can't be expected to give up their preferred mods, like idgamma, since once they get used to them the old ways may look worse to them (for example idgamma allows for contrast increases I think, which the "gamma" cvar can't replicate.)

I think I'm safe from any serious criticism as long as I make everything cvar-controllable, though :) 

This is a really minor point, but: A while back I said overbright made kjsp1 look bad. In fact it's really only dramatically different in the two skylights shown in aguirre's screenshot.

I just ran around it today and the rest of the level looks pretty much like any other map: mostly the same as without overbright, with only a few hotspots that are moderately brighther.

So, I just wanted to retract any implication that killjoy did lighting badly :) 

I guess the thread got a bit hijacked, sorry about that ... Hopefully there are some interesting points. 

winquake
http://img216.imageshack.us/img216/9162/winquake00overgt0.jpg

fitzquake
http://img216.imageshack.us/img216/7020/fitz000overnj3.jpg 

fitzquake does look slightly brighter. I'll have to investigate that.