Answering my own question. :)
I found in tdfx_driver.c,
TDFXLoadPalette16() is functionally equivalent to
I looked into how TDFXLoadPalette16() is called, and I soon discovered
xgamma(1) which I believe will solve my problems (I'm away from my desktop
at the moment).
I'll follow up if it does not work, otherwise I think its fixed - run
xgamma before and after Quake2, and the Glide SST* env. hack shouldn't be
needed at all.
On Thu, 15 Nov 2001, Jamie Guinan wrote:
> System: ABIT BP-6 dual Celeron/466
> GPU: 3dfx Voodoo3 3000, PCI, 16MB
> OS: Stock Red Hat 7.1 (XFree 4.1)
> Most everything works great out of the box. Quake3 runs smooth
> (30-40fps is plenty for me), and gears churns out about 500 fps.
> But good old Quake2 is just too dark.
> So, I tried the SSTH3_xGAMMA (x=R,G,B) environment variable Glide hack.
> I found the code that does the gamma table loading in
> (from the XFree86 SRPM)
> The function is hwcGammaTable(), which ends up living in
> It looks like it has mmapped access to the 3dfx regsiter
> space and sets the gamma tables via address/offset poking.
> I know it *works*, because I can see the whole screen go darker or
> lighter depending on the SST* env. settings, but only for a
> split-second, then it reverts to whatever it was before.
> I tried debugging a copy of gears, and I found that the gamma
> tables get reset in this code path in libglut,
> The reset happens right at the XFlush(), so its as if the X Server
> is setting the gamma tables back to default values. All the SST*
> processing of course happens in the client app.
> So what I'm looking to do is track down where in the X server
> this might be happening, and I'm not sure where to look.
> Any pointers?
> I realize SSTH3_* is a hack, and Quake2 is probably slightly
> broken since it can't properly set brightness, but this
> is a fun little hack project to see if I can get it working.
> Dri-devel mailing list