Hope the above guide is useful to other fans of Quake II. Here's some background on how I discovered this approach.

I love Quake II to death and have played it a zillion times, but I've always struggled to get the brightness right. Fresh installs of the game are way too dark on most systems, and the built-in brightness controls have nasty trade-offs discussed below. I also have not had much luck with driver-level gamma controls. (Drivers vary in the level of control they provide, and some old cards don't support gamma correction at all, so I don't see this as a viable solution.)

I've never understood why Quake II is so dark and murky to begin with. Quake III Arena doesn't have this problem! My guess is that Quake II was developed and tested on old video cards and drivers that rendered textures very differently. Maybe someone more familiar with Quake II's engine technology can shed more light on this (pun intended).

Anyway, I recently embarked on a fresh playthrough of the game and arrived once again at this scene:

Something is clearly wrong here. Look at the lava. See how washed out the texture is? There's no way it's supposed to look like that.

I tried messing with the three console variables I knew about: vid_gamma, gl_modulate, and intensity. The only way I could fix the lava was by setting intensity to 1.0:

Now the lava looks right, but the rest of the scene is waaaaay too dark. What about the other two variables? Here's what different values of vid_gamma look like with intensity set back to 1.0:

(left to right: 1.0, 0.8, 0.6, 0.4, 0.2)

UI elements start to look washed out at any value below 1.0, so this doesn't help us much.

What about gl_modulate? Here's what different values look like for that variable:

(left to right: 1.0, 2.0, 3.0, 4.0)

This seems like a good solution at first, but it turns out that high gl_modulate values severely compress the lightmap's dynamic range. There's a good write-up here that explains how the variable works and why it sucks. The loss of dynamic range is most apparent for objects (including the gun model) that are placed in dark areas:

So, another no-go. I propose that the optimal values for these three console variables are as follows:

vid_gamma 1.0
gl_modulate 1.0
intensity 1.0

So, how do we get the game to look right? As in, not too dark and not too bright? This is where Q2Gamma comes in. This is basically the Quake II equivalent of idGamma, a must-have gamma correction tool for GLQuake which is also way too dark out of the box (and also lacks in-game brightness controls of any kind).

I don't know exactly what Q2Gamma does. It doesn't touch the game's existing PAK files, so it must make the game apply brightness and contrast filters to the textures at runtime. Here's what the game looks like with Q2Gamma's built-in TNT preset:

Nice and colorful, but way too bright for me. Quake II is a gritty game: some areas are supposed to be dark. Q2Gamma makes the whole thing bright. Part of the problem is that it automatically sets gl_modulate to 4.0 (!). It also sets intensity to 1.0, though, which is telling. I think it's pretty clear at this point that the default intensity value of 2.0 is straight wrong; wonder how this got to be the default.

This is good, though. We now have a tool that can make Quake II brighter without blowing out the UI elements. What happens if we dial back the settings in Q2Gamma? I played around with this a bit, and finally arrived at the values listed in my first post.

Much better! I think this is about as close to the intended Quake II look as we are likely to get, at least without resorting to a source port. The lava looks right, the UI elements are nice and vibrant and not washed out, the lightmap has its full dynamic range, and the overall brightness level seems natural. The only drawback I've noticed is a loss of detail on some bright textures (e.g., Bitterman's arms and hands), but this is pretty minor and I think I can live with it. I'll definitely be using this fix from now on.

The right way is ripping GL_LightScaleTexture out of the GL renderer's GL_Upload32 function and putting in actual color control. Something q2-and-kin source ports don't do enough of. The old haphazard nogammacontrolsowechangetexturesonupload-workarounds of '97 (plus 3dfx MiniGL's forced 1.7 gamma) have created ages of misinformation on how the whole idtech2 family of games "should look", etc. Ask one community and they'll tell you it should look like no texture detail with all the models washed out, etc. Ask another and they'll say "Look Best On VooDoo GLide !" with the smudgy high gamma, etc.

Modifying the textures like that with config altering interfaces are all poor outdated pre-source 'fixes'. Your shots show the liquids completely wrecked by it

Another alternative to fix Q2's visuals is setting vid_gamma to 1.0 (which is OFF) and intensity 1 (also off) which shouldn't alter textures, and THEN manually adjusting your video card's gamma control. It'll be brighter, look as visually correct as it can get and there will be no visual loss from poor texture/lightmap compensating. There's a small setgamma program out there in which you could try to stick in a batch to do this on the fly if desired; and don't touch any misleading, busted 20+year old self-absorbed visual basic widget factories

Also id opted for no overbrights for Quake2. The overbrights in the software renderer are from reusing old Quake software renderer code with a 64 row colormap, and all the lightmap data's converted from RGB on load with the intensities approximated. They've even clamped the model shading to not go into any overbright ranges. Trying to push Q2's GL to have similar overbright with its dark saturated lightmaps would lead to a lot of garish bandedness from the color precision loss.

leileilol wrote on 2020-03-01, 03:26:

and don't touch any misleading, busted 20+year old self-absorbed visual basic widget factories

That's a little uncalled for. I'd say the creator of Q2Gamma did the best he could with the tools he had. The results may not be perfect, but they're a lot better than the default look, which you admit is flawed.

I tried the hardware gamma correction approach again. I got better results this time by using RivaTuner. The Nvidia control panel's gamma controls are too imprecise, at least with ForceWare 93.71. The changes don't show up in screenshots, but I'd say the game looks... acceptable. Some textures still look a little washed out, but I guess the overall brightness is closer to the original promotional screenshots.

I don't see anything wrong with modifying Quake II's textures to achieve a better picture, especially since they probably have adjustments baked in to compensate for 3dfx's high gamma. It would be nice if Q2Gamma was a little more flexible. If it could make UI elements a little darker while making environmental textures a little brighter, and do it in a way that doesn't reduce texture detail, that would be awesome. Too bad it's not open source 🙁

You might notice only some of those shots is a 3dfx card (which does 1.7 gamma) and the rest of the earlier shots are on an Intergraph without any colored lights implemented at all at the time, apparently carrying GLQuake's old shifted lightmap load from earlier (which GLQ did to restore some lighting balance with the overbrights clamped out - gl_modulate 2 could do this)