on re-reading, my posts sound rather negative.
sorry about that, the multithreading is going to be a great time saver and i'm quite excited about that. :) 

This is 'coloured lighting in AguirRe's light tool'. 

good job mh. 

I think someone deserves the bounty now. 

This tool applied coloured lighting to one of my current projects which has 104 lightmaps, and over 60'000 vertexes and marksurfaces. Its a benchmark in Quake1 lighting tools. Coloured lighting on massive maps with extra4 etc. It auto-detects if you are using RGB "1.0 1.0 1.0" or "255 255 255" colourscales, too, which is cool. 

what does it all have to do with fitzquake sdl version beta? ;) 

what does it all have to do with fitzquake sdl version beta? ;)
Hmmm... something or another ;>

I got another report of brightness failing too.. So the gamma feature is probably worthwhile. But in my experience, a gamma slider shouldn't be placed beside the brightness one. I'd like to have a GL Options menu (just above the Video Options menu), and put the Gamma slider in this sub menu. Any extra GL menu items can also be placed here. 

if it's a GL option or not. To them, it's all video related, so that's where it should go. Maybe split the video menu into resolution / bpp options and other options like brightness / gamma / etc 

but the quake brightness slider IS gamma. It has always been directly linked to the gamma cvar, way back to dos quake, and the gamma cvar has always controlled basically the same gamma ramp function that we are doing with hardware gamma in fitzquake/etc.

"idgamma" is different, i only assume that it implements additional contrast/saturation controls since people who use it complain about how things look without it. 

Here's some link for a recent tyrquake fix.
http://www.disenchant.net/git/?p=tyrquake;a=commitdiff;h=ed46d97c106471672c571eebd51dedc0508e1225

@Than .. do you have intel video ? 

nope, I've got a radeon HD4850 1gb ram and the latest ati drivers. 

This seems to work for some people.

Download the source and patch
tar xzf SDL-1.2.14.tar.gz
cd SDL-1.2.14
patch -p1 <libsdl-new_gamma_ramp_support.patch
Remove your old libSDL somehow, or "configure --prefix=/usr" will overwrite libs in /usr/lib
configure && sudo make install
sudo ldconfig
quakespasm 

Does FitzQuake SDL automatically properly keymap a keyboard ... like if someone is using a US-101 keyboard versus, say, a German keyboard user?

From the code, I am guessing it does but I don't have an easy way to verify this. 

EN/US layout 

do that, but it would have required replacing Quake's own keyboard codes with SDL codes throughout the entire codebase, and I didn't want to do that way back.

I do think it should be done though, and maybe I'll convince the QS guys to let me fix this in QS. 

I was trying to determine why the Key_Map function was converting the key code whenever the Key_Event function was called.

Ok ... I was reading too much into it. 

Apart from the umlauts QuakeForge does it, if you need a starting point. 

Almost 3 years ago, I added international keyboard support into ProQuake with a cvar (with a keypad bug I keep forgetting to fix) on Windows, but it is dependent on Windows messaging stuffs so it is totally non-portable.

I was just looking to understand the FitzQuake 0.80 implementation of the SDL build and the Key_Map thing threw me off. I thought some non-obvious keymapping was going on using libsdl somehow. 

It just maps SDL key codes to Quake key codes IIRC. 

I don't know if other people have this problem, but I find that the more immersed I am in playing a Quake map, the less likely I am to remember to quicksave. When I die, having to replay several minutes really breaks the immersion :-(

To fix this problem, I'm working on a patch which adds autosave/load to QuakeSpasm. Here's a snapshot:

http://github.com/downloads/ericwa/Quakespasm-Autosave/quakespasm.zip

Here's how it works: at regular intervals (no more frequently than every 30 seconds), it automatically creates a save called auto_{mapname}. When you die, the most recent save is loaded - regardless of whether it's an autosave, quicksave or normal save.

If you want to start a map from the beginning, you can use the "restart" command, or "map mapname".

It needs more testing - there are heuristics for deciding when to autosave which need to be tweaked - but check it out!

the code is here:
http://github.com/ericwa/Quakespasm-Autosave 

Great feature ericw!