InsideQC Forums

gl_brightness and gl_contrast are supposed to exist in fte, but whether they're identical to the gamma+contrast cvars is a different matter. If it ain't exact, it ain't gamma.

reckless wrote:Hmm an interresting non shader based gamma function i have from one of mh's older engines.

Code: Select all

/*
===================
SCR_SetBrightness

Enables setting of brightness without having to do any mondo fancy shite.
It's assumed that we're in the 2D view for this...

Basically, what it does is multiply framebuffer colours by an incoming constant between 0 and 2
===================
*/
void SCR_SetBrightness (float brightfactor)
{
    // divide by 2 cos the blendfunc will sum src and dst
    const GLfloat brightblendcolour[4] = {0, 0, 0, 0.5f * brightfactor};
    const GLfloat constantwhite[4] = {1, 1, 1, 1};

    // don't trust == with floats, don;t bother if it's 1 cos it does nothing to the end result!!!
    if (brightfactor > 0.99 && brightfactor < 1.01)
    {
        return;
    }

    glColor4fv (constantwhite);
    glEnable (GL_BLEND);
    glDisable (GL_ALPHA_TEST);
    glBlendFunc (GL_DST_COLOR, GL_SRC_COLOR);

    // combine hack...
    // this is weird cos it uses a texture but actually doesn't - the parameters of the
    // combiner function only use the incoming fragment colour and a constant colour...
    // you could actually bind any texture you care to mention and get the very same result...
    // i've decided not to bind any at all...
    glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
    glTexEnvf (GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE);
    glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_CONSTANT);
    glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_ALPHA);
    glTexEnvf (GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PRIMARY_COLOR);
    glTexEnvf (GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR);
    glTexEnvfv (GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, brightblendcolour);

    glBegin (GL_QUADS);

    glTexCoord2f (0, 0);
    glVertex2f (0, 0);

    glTexCoord2f (0, 1);
    glVertex2f (0, GL_State.OrthoHeight);

    glTexCoord2f (1, 1);
    glVertex2f (GL_State.OrthoWidth, GL_State.OrthoHeight);

    glTexCoord2f (1, 0);
    glVertex2f (GL_State.OrthoWidth, 0);

    glEnd ();

    // restore combiner function colour to white so as not to mess up texture state
    glTexEnvfv (GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, constantwhite);

    glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
    glDisable (GL_BLEND);
    glEnable (GL_ALPHA_TEST);
    glColor4fv (constantwhite);
}

uses opengl's combine extention so will not Work for the software client.

Reckless, I don't think that does real gamma. But if It really does real gamma, feel free to smack me upside the head and point out how it does.

To me that looks similar to the "draw a brightness poly over the whole 2D surface" method.

Indeed what it does is a bit like doing overbright but it emulates gamma amazingly well though
Also easy to use as it uses the v_gamma cvar directly.

Barnes wrote:ahh yes!!!
photoshop math on glsl and hlsl (im use some things)
http://mouaif.wordpress.com/2009/01/05/ ... l-shaders/

Hey, my coworker wrote those! Small world.



As for the GL_COMBINE stuff, that effectively just multiplies the output. It's actually pretty useful when blending lightmaps with textures, as it's effectively a "free" way to brighten things up. I use this in Paintball2 (gl_overbright is the cvar to enable/disable it). If that's not bright enough, I've also got the method posted above, where it draws a quad over the whole screen to brighten it (gl_brightness cvar). Downside to that is it's a pretty big fillrate hit, since it has to make another pass over the whole screen. I'm not sure if that's more or less expensive than a shader (I would imagine less), but it will be compatible with more video cards. It does not, however, behave like gamma. It just scales the brightness of everything up.

GL_RGB_SCALE does scale the output, yes (overbrights etc). Activate it when drawing everything else and you can double the contrast of the screen, but you have to be really careful with blend modes.
contrast is easy to implement - just double the colour values.
brightness is also easy - just add to the colour values.
actual gamma requires exponents, however. luckily, it should be possible to just multiply the values enough times. the down side is that doing that will loose precision. a lot of precision.

jitspoe wrote:

Barnes wrote:ahh yes!!!
photoshop math on glsl and hlsl (im use some things)
http://mouaif.wordpress.com/2009/01/05/ ... l-shaders/

Hey, my coworker wrote those! Small world.

Damn! Real small world!

Aye its not true gamma but if someone can use it for whatever its easy to implement call the function from the same place as the old gamma and give it a cvar as argument for the bright factor.
Small note it uses negative values so if you want to use it with the standard quake menu you have to invert the menu scales. Maybe nice for a scalable overbright setting hmm ?.

reckless wrote:Aye its not true gamma but if someone can use it for whatever its easy to implement call the function from the same place as the old gamma and give it a cvar as argument for the bright factor.
Small note it uses negative values so if you want to use it with the standard quake menu you have to invert the menu scales. Maybe nice for a scalable overbright setting hmm ?.

Shockingly enough, I'm only getting a 4 FPS hit off this and it works pretty well.

Now I'm trying to debate what to do. Damn you reckless!

Sat on fence then went with this.

Reasons:
1. Loss of 4 fps 223 fps to 219 fps on my $300 windows laptop (this $300 laptop is incredible ... it's terrific and I'm picky)
2. No need for gamma and contrast. Just brightness. Winner.
3. No more platform specific hardware gamma code.
4. Screenshots don't need gamma correction applied (not that I did that). Neither does video capture.
5. Affects only the Window itself.

Drawbacks:
1. Slightly narrower capabilities of brightening the screen. Hardware gamma has more brightening power.
2. Slight loss of FPS and fps matters (within reason). But 1%-2% loss is nothing.

I had rewritten all the Windows hardware gamma code really nice and orderly. And now I'm throwing it away. A bit ironic, but I'll take this total solution over hardware gamma every day.

Since "gamma" is a standard Quake cvar (some mods even use it for brightness effects like flash grenades ... although they shouldn't have used the cvar) I internally call it scr_brightness but keeps same external cvar name.

Happy that it found a use fps hit is as you say minimal and it Works rather well so i thought someone might find it interresting even though its not real gamma .
Heh funny i use the same cvar name small World indeed.

In a lot of cases, we don't actually want gamma - we just want things brighter, so it's ideal for that. If things are simply too dark, using gamma to brighten them can result in washed-out visuals (loss of contrast and saturation). If you want brightness in the standard case, you can use this when combining the lightmap and textures to avoid the 4fps hit, though it would require modifying a lot more code.

Burial ... Hardware gamma code: I can't imagine ever using it again and am removing it, but some of it I touched up sensibly.
And

Kill'em, kill'em!!!!
Seriously I have already killed the hardware gamma ramps. A terrible thing has been

Definatly worth it sifting through mh's older OpenGL engine sources, lots of non standard but amazingly well working ideas His Q2 sources are also worth having a look at, many nice ideas in them.

Btw try replacing tenebraes old gamma code with the code posted i think your going to like it.