dual monitor gamma issues

[Spike]

or in other words, you mean tl;dr ?

#define GL_FRAMEBUFFER_SRGB 0x8DB9
glEnable(GL_FRAMEBUFFER_SRGB);
The output of your fragment program will be scaled up by about 2.2 gamma (remember that quake's gamma cvar is backwards, about .45 iiuc).
(basically, this works around the issue that ericw pointed out).



When uploading textures, if you specify GL_SRGB_EXT for your internalformat argument, then your image is treated as though its already gamma corrected, and will be 'linearised' as part of sampling, such that it won't get brightened.

Using both at the same time can reduce banding in low-light areas, supposedly.

Edit:
Regarding documentation, the microsoft docs are outdated to the point of pointlessness. They don't document *ANYTHING* beyond gl 1.1. its all fixed function stuff - stuff that has been deprectated for quite some time now.
On the plus side, when it doesn't support anything, there's not much that is needed to be documented - which makes it muuuch more readable I guess.
Either way, if you're depending upon microsoft for documentation then you're basically handicapping yourself to whatever the latest thing microsoft thinks it can get away with pushing.
Its ironic really, their rediculously-outdated documentation for opengl is far more readable than thier documentation for d3d... Or would be, if searches for gl stuff on msdn didn't get drowned out by people talking about comparisons between gl+d3d... by citing microsoft.
Also, http://www.gamedev.net/topic/198541-glv ... ion-error/
The nice thing about official documentation of opengl is that its both complete and definitive. Other sites simply don't offer that (unless they're just copy+paste, making them a bit pointless except as mirrors).
But yes, you do have to actually know what you're looking for first.

[Baker]

[Spike]

[Baker]

[Spike]

[Baker]

[r00k]

ok more off topic but steering back to RTT/GLSL

from what ericw mentioned, using RMQe as a guide to setting up RTT and GLSL i added the r_waterwarp. I'm hoping that i can use the same code for blur and gamma too

but once all is said and done im getting this...


now, the grey areas are using gl_clear 1, otherwise i get 'hall of mirrors' effect in those areas.
without posting all relative code, am i forgetting something? The ACTUAL render/warp code is 100% from RMQe, maybe im not clearing a buffer or something?


EDIT: NEVERMIND!! I WAS CALLING R_DrawUnderwaterWarp FROM THE WRONG PLACE! doh!

[dimman]

I did a quick hack to port the code to ezQuake and I'm seeing about 50-70% performance drop when gamma != 1.

Is this reasonable by using the shader/implementation ericw presented?? (I haven't managed to get quakespasm running here yet otherwise it seems like a fairly easy test to do by toggling it on/off on cmdline)

[ericw]

I didn't realize it was that much of a perf hit, at least on id1 maps, but in e1m1 I go from 770fps with gamma 1 to 290fps with gamma != 1.
I tried that at 2880x1800 to maximize the performance hit, w/ geforce 650gt 1024mb, OS X.

On the other hand if I try one of the heaviest quake maps I know of, jam3_tronyn.bsp, I get about 130fps regardless of gamma.

(Btw, we did some cleanup last week to the quakespasm build system for VisualStudio, CodeBlocks, and XCode; with any luck it will build out of the box if you checkout the latest svn.)

[dimman]

[mh]

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'd be surprised if it was the latter; Doom 3 extensively uses glCopyTex(Sub)Image for it's post-processing effects, and FQ/QS itself uses glCopyTex(Sub)Image for it's r_oldwater 0. Perhaps you could try a comparative benchmark with r_oldwater 0?

It's possible that while glCopyTexSubImage may be sub-optimal on some drivers, glCopyTexImage is not. One possible reason for that might be that glCopyTexImage will respecify the texture, so it may be better able to handle cases where a previous frame's drawing using the same texture is still queued up. A 50% to 70% perf drop certainly does suggest some kind of synchronization is going on.

So I also suggest trying a switch to glCopyTexImage instead and see if that improves things.

You should specify GL_NEAREST for the filtering modes when applying gamma this way, by the way, otherwise you will drop some image quality.

[ericw]

Booting into Windows, I tried dipping under water in e1m1 with RMQEngine and DirectQ, and both of those also show a ~50% fps drop when the render-to-texture screen warp kicks in. But again, 2880x1800 resolution, and the drop was ~700 to ~300fps. This is a laptop, too, and the gfx card isn't that great, so maybe it just doesn't have the horsepower to copy that large of a framebuffer at 700fps?

r_oldwater: I tried Quakespasm, gamma 1, in the water in e1m1, and got 448fps with r_oldwater 0, 487fps with r_oldwater 1, so a bit of a boost from disabling RTT. But the warp image is only 512x512, and the 2880x1800 framebuffer is almost 20 times bigger.

Taking out the redundant glClear in my RTT code Spike pointed out, and change to GL_NEAREST, I'm up to 330fps with the RTT gamma which is a bit better.
I tried a switch to glCopyTexImage but it didn't make any difference.

Thanks for the tips!

[mh]

I missed the 2880x1800 part.

Yeah, that's gonna be a performance drag whatever way you slice it. DirectQ, by the way, should do a "real" render to texture (i.e using D3D's equivalent of FBOs: ) so that should establish that switching to FBOs in GL isn't going to help much. At this stage I'd be willing to bet that you get a similar performance drop when the polyblend is on (do an impulse 255 and test it; it won't be as large but it should be in the same kinda ballpark), so it seems that it's just drawing over such a large resolution viewport that's primarily to blame.

[ericw]

Ah Yup, the framerate hit from impulse 255 at that resolution is about 40% (770->440fps).

Anyhow, I'm pretty happy with this gamma implementation. From what I've seen I doubt it will ever get in the way of hitting 60fps (or even 120fps) on Quake maps. Running id1 content at very high resolutions and uncapped FPS is sort of a crazy border case, I think.

[dimman]

Hehe, yeah if 60-120fps were good enough for the old an dirty ezQuake engine and its users I come from the QW community and the requirements there are a bit higher I assume. People play with framerates of atleast ~500fps and a drop from say 2000fps to 1000fps wouldn't be accepted.

Anyway, thanks a lot guys for looking into it, I'll see if I can do anything about it on my side (Btw, I was testing @ 1680x1050 and could see some drops from 2900fps to 1200fps or so. The engine is a big hack and currently uses OpenGL 1.x.. Hopefully I'll be able to fix and clean things up around it at first and then look into the renderer. Oh and yeah I did test commenting out the gl_clear calls and changed LINEAR to NEAREST, and also changed to glCopyTexImage2D but no big changes really.)