InsideQC Forums

mh wrote:If you're getting that kind of drop with shader-based gamma via glCopyTexSubImage, then you're either doing something else wrong or your driver has a very poor implementation of glCopyTexSubImage.

I'm using RMQe's (your code), using the r_waterwarp, and vertex arrays, getting 445fps with waterwarp 0 and 325fps with r_waterwarp 1 so costs about 120fps for that feature. I can live with that as, my normal maxfps is 125 so r_waterwarp will never affect that minimum; and i suspect r_glsl_gamma will also only cost 120fps. (testing on a 550TI, 1440x900x32)

dimman wrote:a drop from say 2000fps to 1000fps wouldn't be accepted.

This is basically why people say "don't measure frames per second, measure milliseconds per frame".

The Quake community really needs to get wrong ideas out of it's head. A drop from 2000fps to 1000fps is perfectly acceptable, because it's only an increase in frame time of 0.5 milliseconds. That's the kind of scale at which a transient condition on your PC could cause a similar increase. It's nothing.

Playing at 500fps is a great way to flood a server and impact on gameplay for others too. Quake is it's own denial-of-service.

20k fps is more fun... yay threads.
thankfully most clients have been fixed to avoid spamming servers with 2000 packets per second, despite the hilarity of doing so.
said clients getting kicked because of it may be why they got fixed.

ericw wrote:Running id1 content at very high resolutions and uncapped FPS is sort of a crazy border case, I think.

I personally don't think it is a border case. Resolution even on laptops is getting insane --- and in 2-3 years it might even be the new normal.

Devil's Advocate: You invest a ton of time to increase FPS. Then you have this which shreds fps. Per frame application of gamma is going to be expensive. Why apply the gamma each frame?

Isn't doing a massive calculation each frame the definition of insanity and waste?

Apply the gamma to the textures, reupload them and keep 700 fps! FitzQuake's texture manager has the "reload all textures" mechanism built in so most of it is already written. Quake's textures are low resolution, small and 256 colors.

[Yes, skyboxes and external textures would be be slightly harder but even then those are typically 512x512 and occassionally 1024x1024 or 2048 x 2048. And Quakespasm has the advantage of not supporting external textures on models even though it is the year 2015 (I'm kidding around. Mostly! Although about no one uses external textures in FQ/QS even for maps.)]

If you are going to do all that work and planning for animation lerping, why wouldn't doing this right and efficiently be worthy of such. (Compared to animation lerping, this is easy.)

One opinion, probably wrong.

Hm, maybe you're right, Baker. At least, it could be better to go that route for an engine like Quakespasm which has no fancy visual effects.

I just would just want to make some comparison images with transparent water, fog, etc., to see the difference between doing gamma on the finished frame vs the textures.

Correct me if I am wrong, but here goes:

Mathematically on paper, the blending of 2 gamma corrected textures should yield the same texture as 2 non-gamma corrected textures which then have the gamma applied because the mixing is of the color components (R, G, B) which have individual gamma correction. On a computer it will be slightly different as with any floating point calculation. (Or am I missing something here, which is possible like a low blue value and a high blue value can't interpolate.)

So transparent water and alpha blended textures aren't a problem because you aren't apply the gamma to application of the texture (cumulative) but only once. Which is why GLQuake 0.98 which has a -gamma command line parameter, renders transparent water just fine.

The real issue would be that you would need to apply gamma correction to fog color, especially since fog tends to hit opaque.

The real issue is colours that don't come from the Quake palette (or from textures).

Personally I'm in two minds about this. Gamma is one of those settings that you're not going to be changing every frame. You'll change it once, maybe tweak it a little to find a value you like, then you'll leave it be for the rest of eternity. That argues against real time control. On the other hand the big advantage of being able to do it in real time (and with instantaneous feedback - not having to wait for textures to reload!) is to be able to see and compare the effect of different values.

I'll content that even having to wait 0.5 seconds to see the effect of a gamma change is a barrier to most players. They'll get pissed at you for it.

Regarding FPS, a drop from 700 to 300 isn't "shredding FPS".

700 FPS = 1.42 milliseconds per frame.
300 FPS = 3.33 milliseconds per frame.

Gamma therefore takes (3.33 - 1.42 =) ~2 milliseconds to apply.

Compare that to a case where your normal FPS is 200. That's 5 milliseconds per frame. Add gamma and you run at 7 milliseconds per frame, or 142 FPS.

The whole idea that dropping from some-huge-number to some-other-huge-number is somehow catastrophic is just bogus. But that's something else that players will get pissed at you for, unfortunately.

mh wrote:I'll content that even having to wait 0.5 seconds to see the effect of a gamma change is a barrier to most players. They'll get pissed at you for it.

Miscellaenous stuff:
In FitzQuake (and probably Quakespasm), when you have the menu up, it draws a 50% or 75% black poly across the entire screen. So you have to exit the menu to see what you've done. An average player has no idea what the valid gamma values are and wouldn't know they go from 1 to 0.5 backwards so 99% of players aren't even capable of doing it from the command line.

Some maps have like DM6, literally have 10 textures. Few id1 maps have more than 70 and a lot of Quake textures are buttons and such that are 16x16.

For an id1 map without a skybox or external textures, reuploading all textures in a single frame would be easy. (Then again, you have Roman1 with 1024+ textures +/-.)

Now, here is a hybrid. You play with gamma in the menu in real-time using a shader. When you exit the menu, that's when it officially "commits" the value and does the convert. No delay to the user. No loss of run-time performance. A couple of quirks exist to work around.

In some ways, none of this is a "serious issue" and most NQ engines (and no Quakeworld ones) experience physics malfunction with fps > 72.

mh wrote:I'll content that even having to wait 0.5 seconds to see the effect of a gamma change is a barrier to most players. They'll get pissed at you for it.

I believe the FitzQuake texture manager actually knows the frame # a texture was last bound (and if it doesn't, that is one new variable to add to the struct and probably 3 lines of code in GL_BIND).

You could reupload those immediately and queue the other ones. It would be real hard to generate scenarios where that would cause delay (noclipping on Roman1 would be an example, since being in void causes the entire map to be visible less culling).

Mathematically on paper, the blending of 2 gamma corrected textures should yield the same texture as 2 non-gamma corrected textures which then have the gamma applied because the mixing is of the color components (R, G, B) which have individual gamma correction. On a computer it will be slightly different as with any floating point calculation. (Or am I missing something here, which is possible like a low blue value and a high blue value can't interpolate.)

I think it actually doesn't quite work; say you mix 50% black (0.0) and 50% white (1.0). If you gamma correct the colours before mixing, they stay the same, since 1^gamma = 1 and 0^gamma = 0, so the blend result is 0.5 regardless of gamma.
If you gamma correct after blending, you get a result of 0.5^gamma, which could be far from 0.5.

How noticeable it is will depend on the colours being blended and the gamma, I guess.

Devil's Advocate: You invest a ton of time to increase FPS. Then you have this which shreds fps. Per frame application of gamma is going to be expensive. Why apply the gamma each frame?

Well to argue the other side, doing gamma in a way that's non-invasive to the codebase may be worth some FPS loss. You just drop it in, and if it works at all, there's no possibility of causing subtle changes to the rendering, everything is going to look the same as with hardware gamma.

I did take a shot at implementing the texture gamma today, and couldn't figure out how to get it working with overbright lighting. I didn't attempt to get mdl lighting gamma corrected, but at first glance, it will never be quite right unless it's done in a fragment shader, since OpenGL linearly interpolating between two vertex colour values that have been gamma-corrected won't be same as gamma correcting after.

And Quakespasm has the advantage of not supporting external textures on models even though it is the year 2015 (I'm kidding around.

Haha, it's on my list of stuff to grab from MarkV sometime

ericw wrote:Well to argue the other side, doing gamma in a way that's non-invasive to the codebase may be worth some FPS loss.

Quake is about the only game anyone would ever care about this. Most games are played full-screen and that's that. But that is because Quake engines generally are so nice and cater to users.

ericw wrote:

And Quakespasm has the advantage of not supporting external textures on models even though it is the year 2015 (I'm kidding around.

Haha, it's on my list of stuff to grab from MarkV sometime

I have a long list of almost completed features for the last Mark V, which was part of the reason I quit working on it (at least for a while).

One example, I figured out how to enable intermap travel (which requires saving the state of any exited level) and have it save to a single file (a holy grail to me, I cannot accept a save game being more than 1 file under any circumstances --- you can share a single file, for example), instead of a sloppy directory of several save game files. The trick --- write a pak file save game file. Which requires the ability to write files easily to a pak and even replace, which I did.

And I figured out how to do this in a way that does not require a special progs at all.

But completing the wiring and having numerous other outstanding prototypes (I tried, amongst other things to acquire DirectQ's independent physics, which are 99% awesome but I found a perplexing dilemma when using the keyboard to move --- I also had a texture gamma prototype) eventually overwhelmed me.

So really, the "front-loaded gamma correction" concept has been described with the quirks (overbright, possibly additive, etc), but is quite a bit of tedium for something that ultimately probably doesn't matter one bit.

There is something to be said for having a feature "done" and "good enough". Beats 10 "ideas" of perfect that aren't done, any day of the week!

Baker wrote: One example, I figured out how to enable intermap travel (which requires saving the state of any exited level) and have it save to a single file (a holy grail to me, I cannot accept a save game being more than 1 file under any circumstances --- you can share a single file, for example), instead of a sloppy directory of several save game files. The trick --- write a pak file save game file. Which requires the ability to write files easily to a pak and even replace, which I did.

thanks for making me feel bad. its a shame q2 actually requires directories though.

ericw wrote: I think it actually doesn't quite work; say you mix 50% black (0.0) and 50% white (1.0). If you gamma correct the colours before mixing, they stay the same, since 1^gamma = 1 and 0^gamma = 0, so the blend result is 0.5 regardless of gamma.
If you gamma correct after blending, you get a result of 0.5^gamma, which could be far from 0.5.

correct.
note that lightmaps+textures are traditionally linearly blended onto the framebuffer, which is thus subject to about 2.2 gamma (0.45 if you're using quake's gamma).
this makes the lighting ALL WRONG!
but people don't seem to care that much. oh well.

typically you can get away with not actually implementing gamma at all, but rather using a contrast shader. really its just an extra fullscreen pass that uses some weird blendfunc to double the framebuffer's values a few times (or less). this not only avoids the ugly whitening thing, but also avoids needing to use glCopyTexImage.
or you can do contrast stuff with glClampColorARB(GL_CLAMP_VERTEX_COLOR_ARB, GL_FALSE); and scaling up your glColor values beyond 1 (or use glsl+attributes instead). hurah, no post processing needed at all.


2ms is significant
700fps dropping to 300fps is a serious drop.
yes, its only 1.91ms, but that's more than 1.42 and thus means you're spending MORE time just drawing gamma than you are updating+networking+drawing the scene in the first place!
the whole framerate timing thing revolves around counting drops of 20fps, and how they're insignificant compared to 700fps and absolutely decimating when compared to 200 fps (hah! the REAL meaning of decimate! read 60fps if you want a more serious example).
800->400fps is the same loss as 80->40fps. ie: ratios of rates are accurate, and those are what was referred to earlier in the topic by dimman.
a >50% drop is only acceptable if you consider the complexity and overdraw of the various shaders. on one hand you have all the game overhead combined with sampling two textures with a multiplication. on the other hand you have a single texture read with an exponent.
obviously with complex scenes, quake tends to get cpu-bound instead, leaving the gpu idle enough to do its highly expensive pow operations... so yeah, it doesn't really matter because of this, but only because of this.
the big problem with ezquake's situation is that time spent processing gamma is time spent before the driver can do its buffer swap, and is thus extra latency.
its hard to please a quakeworld player.

on a side not isnt it possible to mimic the gamma 'colors' kinda in the way that overbright does? would only be done once at map load, or realtime, yet only once.

r00k wrote:on a side not isnt it possible to mimic the gamma 'colors' kinda in the way that overbright does? would only be done once at map load, or realtime, yet only once.

What would be ideal --> lookup table like software renderer uses. Except instead of 256 rows, you need 256*256*256 rows, which is 64 MB (16.7 M x 4 bytes per row.)