the brightness slider works in quakespasm. and fitzquake too, afaik? 

Yes, but not necessarily on Linux. 

hmmm... i've never seen the gamma slider fail. Maybe X or SDL isn't set up somehow? Stab in the dark though. 

Interesting, SDL Fitz's brightness slider does the same like "gamma". I never knew. 

oh, sorry than, i didn't read the part where you said the slider doesn't work. :S 

What slider now? 

frib's posted about this a few times, I find a difference in colour intensity as well as brightness. Quake looks washed out without it to me. 

does it work with the likes of quakespasm?

interested in trying it out if so 

though i have never used idgamma, i think i've heard that it lets you mess with contrast and stuff too... so it's not really an exact replacement for gamma.

Personally i just use regular gamma, which works in fitzquake (in windows at least) the same as in software quake.

But, a nice wishlist feature for fitzquake (or any other engine) would be to emulate idgamma settings using extra cvars. This could probably all be done using the same hardware gamma ramps that the gamma cvar uses. 

So does the gamma^h^h^h^h^hbrightness slider not work for anyone else ?

@Than.. If your X is misconfigured , you can read about X's config file with "man xorg.conf", and edit it manually (usually in /etc/X11/xorg.conf) if you're feeling brave. After any changes, you'll have to restart the X server to see effects. Keep backups of xorg.conf in case you screw up (which is pretty damn easy), and use "Control+Alt+F1" to get to a terminal in case X gets messed up. 

yes, I've found it to work with everything. 

Any kind of palette hacking doesn't play nice with external textures; another good reason to not do it. 

do you mean other wad files for maps using quake textures. Havent had any problems with that.

IF you mean high quality external textures, I only have starbuck's base set and havent had any issues with those either. 

yeah, that's why it seems like an improvement to do it in hardware instead of the palette. 

palette hacking won't modify external textures.
i think mostly mh was talking about how if someone makes a custom texture, there's now no guarantee it will look the same on a client with a hacked palette.
a good example is the ikwhite set that was modified from the ikblue set. i've seen screenshots of it where the textures look nearly all white or with bits of bright yellow in them. 

where should I install stuff in ubuntu/linux? Currently I just have Quake in my home dir, but it feels all wrong to have it there - like putting it in my documents in windows.

Programs installed via packages extract to various places, with the executable generally going to usr/bin from what I have read, but if I download an app, like Quake, where is a good place to dump it? Should I create a games folder in my home dir or put games (all the data etc. not just the executable) in usr somewhere? 

I put games that I cannot install from my distribution's repositories into a directory inside my home.

Quake is in ~/stuff/games/quake . That way I can also easily use Wine to run Windows engines. Otherwise you would also need superuser permissions to install maps (unless your engine supports the data being somewhere else, I am not really sure quakespasm does this). 

Home dir support is in the making for QS. Does anyone know what exactly idgamma does to the Quake palette? It would be nice to add it to QS too. 

where should I install stuff
/usr/local/games/quake

Most linux installs leave /usr/local fairly empty (unlike shitty FreeBSD). If system is only for yourself, using /usr/local/ for everything allows for easy system upgrades. That way, any 'proper' software you install yourself you just use "./configure --prefix=/usr/local" and stuff gets put in /usr/local/bin and /usr/local/lib. This allows for easily copying /usr/local with system upgrades, or if you have two linux varieties on the one box, you can share the one local filesystem with something like -

If installing Fedora on another partition to Ubuntu, from Fedora:

mkdir /mnt/ubuntu
mount /dev/sda2 /mnt/ubuntu
mount -o bind /mnt/ubuntu/usr/local /usr/local

Using $HOME like Spirit says is ok, but doesn't accomodate 'proper' software installs using "configure", and you generally cannot always just mount Ubuntu/$HOME over the top of fedora/$HOME because of OS vageries with config files in $HOME, especially KDE and GNOME.

Mp3s and the like could go into
/usr/local/share/mp3 ... but many times generic data like this
will go onto another windows partition so you can easily access it from Linux and Windows. 

where should I install stuff
/usr/local/games/quake

But that would mean no easy read/write access to those files and directories, or am I thinking wrong? Where would you recommend to keep the maps and mods then?

Same for music files. I would keep my photos and documents in my home, as well as anything related to "projects". Music are just another form of frequently changing data the user needs easy access to.


SleepwalkR: Check the idgamma readme http://www.quaketerminus.com/nqexes/idgamma.zip
As I understand it, idgamma simply hardcodes some gamma change into the palette.

aguirRe's readme suggests that the original glquake had no hardware gamma support. http://user.tninet.se/~xir870k/readmegl.txt
So that might be why it was needed. I don't see any reason to use it if your engine supports proper gamma. Maybe some supporters of it could take screenshots to show what they feel is different? 

But that would mean no easy read/write access to those files and directories, or am I thinking wrong? Where would you recommend to keep the maps and mods then?

Yeah... permissions do complicate things with Quake. There are two issues: installing game data, and running the game.

Putting game data into /usr/local/games requires "root" privilidges - but any way you look at it - running Linux means becoming familiar with the "su" (superuser) and "sudo" (superuser do) commands.

Re running the game:
Darkplaces, TyrQuake, all Q3 projects and virtually every other piece of Linux software put their user data into $HOME/.APPNAME when the game is run. The fact Quakespasm doesn't have home directory support means you'll also have to
1) "sudo quakespasm" when starting the game (probably easiest), or
2) "sudo chmod -R a+rwx /usr/local/games/quake" (allowing all users read/write/exe access to the quake directory)

Either solution is fine imho. Personally, i'm quite happy using "root" as my login shell, and only running untrusted apps such as firefox as an unprivilidged user, but i can't recommend doing this for Linux noobs because you *will* break your operating system sooner or later.

Quakespasm does have a HOMEDIR patch (game saves, configs + screenshots are stored in $HOME/.quakespasm) but it doesn't apply cleanly at the moment. Someone SHOULD properly test and add this feature for the next release. 

Thanks, it seems to do more than just change the gamma though. I'll look into it, maybe we can add it to QS if the others agree. 

> aguirRe's readme suggests that the original glquake had no hardware gamma support. http://user.tninet.se/~xir870k/rea...

That's correct, no hardware gamma in the original GLQuake. There's evidence of an attempt to do it in gl_vidnt.c (I don't know about other platforms) but nothing seems to have come from it.

It should be straightforward enough to compare the before and after palettes and reverse engineer a pretty close approximation of the algorithms used by idgamma, but you'll need to be aware that in some cases it can clamp palette entries at 255 (which is presumably the cause of the "makes q2 lava look like vomit" comment in the readme) so an idgamma hacked palette may have lost some colour range (similar to the effects of Q2 and Q3A's "intensity" cvar). 

@Than , Ha ha... so maybe Spirit's right.
@Sleep , hmmm. I don't think Oz is keen to code anything unless brightness is broken (which neither of us have ever seen i think) 

I would code it myself out of curiosity.