I just read the post about this in the speedmapping pack, and was about to start mine. sucks. 

Awesome. 

Speeds made a map too.
http://speedq1.leveldesign.org/images/sm139_spd.jpg

Moderators: Please add his name and the link to the top post. Thanks. 

Awesome map, Speedy!

Excuse the poor looks of mine, I spent most of the time on the gameplay. Plus QuArK with Wine has a lot of annoying quirks.

This was a nice session. We should do it like this regularly. :) 

great pack :\ just wait for me next time, or i will shoot someone next time :| you bitches dont love me :\

http://trinca.quaddicted.com/temp/sm139.dz

two first runs

and spd second run fucking Spawns :\ 

Next weeks theme should be "Include Trinca". 

was nice. I even managed to die the first time. 

to whoever is taking the screenshots -- try running in 32-bit mode. The sky colors will look better. 

Fitzquake sometimes screws around with its resolution. I probably forgot to set it back to 32.

Btw. Why is lighting handled differently in Fitzquake (ostensibly also DP) and regular GLQuake-based engines: http://speeds.quaddicted.com/q1light.jpg 

just curious (i.e. top screenshot, bottom screenshot)? 

top - fitz
bottom - almost any other (in that case I used bengt`s)
no ID gamma used

AFAIK only fitz and DarkPlaces do nice overbright effect (not counting QW engines)
In other gl engines the light is like 50% range of what it should be :(

thx for comments demos are wellcome 

Spd
You can't expect too much contrast with
minlight 15 and a small 70 light 

Could you use a higher light value (not worldspawn I mean, but individual light ents) but a 'fade distance multiplier' value greater than 1 (i'm using an fgd file with that on worldcrafts 'smart edit' feature, cant remember the actual key name (anyone?)). I believe this would give a brighter inner light, but without the light spreading too far. 

yes I can. with inverse square fall off (= delay 2) its 100% bright in the center 

Btw. Why is lighting handled differently in Fitzquake (ostensibly also DP) and regular GLQuake-based engines

The original quake (software) engine used overbright lighting, which means the lightmap brightness can go up to 200%. So, light.exe creates BSP files with lightmaps that go up to 200%.

In glquake, since it was such a rush-job (I think carmack said he wrote it in a weekend) there is no overbright lighting, so every part of the lightmap that goes above 100% is flattened to equal 100%. This is why glquake looks just fine in darker rooms, but in bright areas the lighting looks very flat.

Fitzquake and darkplaces restore the overbright feature of the software renderer, so that lighting hot-spots will actually be as bright as intended. 

...and the same thing Trinca said :D 

God damn. Didn't know that. That's why GL looks so crap. 

It's always interesting (and devastating) to find out it was no placebo after all. I guess MHQuake uses "proper" lighting too as I always felt that engine to have the best look of the glquake engines. 

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?