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. 

TBH, I've been mostly using fitzquake with wine lately (when I've been playing Q at all), I guess I should try some of this new hotness at some point :-) 

Hmmm.. There doesn't seem concensus that the feature is good. Sorry if i'm stupid, but what are the advantages over idgamma ?

Anyway... it can always go into Misc as a patch if we don't use it. ... I'll fix up that homedir patch too, and look at including that feature. ^Sometime^! 

easy to disable/tweak if a map is insanely bright (like an ikwhite map).

Is anyone thinking about adding the ability to set up a dir that plays the quake music from sound files (ogg, mp3, hell, even wav would be cool) so we can have music without the cd in the drive and the game changes track as if it were? My cd is thousands of miles away, but I still have the mp3s :) 

Adding FOSS ogg vorbis support is a 100$ bounty from me. I originally meant the stock glquake but sdlfitz or quakespasm seems more reasonable. Someone was working on it but since I got no sign of life for more than a year now I guess it is ok to re-open it.

compatibility to the darkplaces implementation is a must. See http://www.quaddicted.com/bounties/ for details. Please mail me if someone is interested. I will make a last attempt to contact the coder. 

On the .lit support for AguirRe's tools?

Keeps coming back this one, and hmap2 isn't very robust. 

With a little incentive from Spirit... 

I would throw in a hand-job to the man who can get it done!!! 

I'm out. 

http://mhquake.blogspot.com/2010/11/light-tool-is-released.html 

make a news thread, yo! 

on second thought...

seems like the elapsed time output stuff is broken?

Light: 0.0%, Elapsed: 0:00
Light: 0.0%, Elapsed: 0:00
Light: 16.3%, Elapsed: 0:00
Light: 28.2%, Elapsed: 0:00, Left: 1:00, Total: 1:00, 24%
Light: 41.1%, Elapsed: 0:00, Left: 0:00, Total: 1:00, 39%
Light: 72.2%, Elapsed: 0:00, Left: 0:00, Total: 0:00, 81%
Light: 92.0%, Elapsed: 0:00, Left: 0:00, Total: 0:00, 92%
Light: 99.3%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 98%
Light: 100.0%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 100%


Light: 100.0%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 100%

done in 60.771000 seconds

looks like it was rounding off the numbers.

also, how do you use _color with sunlight? tried sticking that in world, but no luck. 

_color with sunlight is an exercise for the future. ;)

The time counter is no longer reliable since I multithreaded it, but it still gives a reasonable approximation. 

about the time counter, that's not what i meant. if you look, you can see that the tool is only displayed minutes and floor'ing the seconds, even on the elapsed time. 

please get rid of 'press any key...' pause at the end of light processing. it's downright annoying and serves no purpose. at the very least add a switch to disable it. even just hooking it into -nowarnings.