DRD Team

I'm almost done with adding the feature where the gamma can be applied by a post processing shader, but I'm wondering what the criteria should be for it being on or off.

Personally I think the most sensible setup would be that its the shader doing it in windowed mode, and the hardware doing it in fullscreen. This would give the best visuals for fullscreen users while fixing the issue that hw gamma in windowed mode affects everything and not just the gzdoom window.

According to a MSDN article on the subject (https://msdn.microsoft.com/en-us/librar ... s.85).aspx) the gamma controls used by Direct3D 11+ ( IDXGIOutput::SetGammaControl) only work for full screen, so maybe I should just hardcode the functionality in gzdoom to do this too?

I could make the whole thing a CVAR of course, but I don't think there is really a situation where you'd want hw gamma off in fullscreen - or hw gamma on in windowed.

Please make it a CVAR for the user to decide (hardware on / off / fullscreen only). There have been reported problems with gamma and multiple monitors. The D3D11 controls are not relevant because they do not get used in OpenGL. Instead it uses the desktop's version of that.

Okay, will do. The D3D11 controls part was just an illustration of what the gaming industry seem to be doing as a whole. What should the CVAR default to? hardware on or fullscreen only?

Fullscreen only, I'd say.

Pull request for this feature: https://github.com/coelckers/gzdoom/pull/63

The patch introduces a couple of classes to manage the OpenGL objects needed:

• FGLRenderBuffers is meant for textures and render buffer objects needed to do post processing after the scene rendering stage. At the moment it only holds a texture for the scene (plus depth+stencil buffer). My future patches will extend this with additional objects needed for bloom extraction, blur, tone mapping and whatever else effects might be fancy.
• FPresentShader is the shader that applies the gamma as part of the copy to back buffer operation.
• FShaderProgram is a generic compile and link class. I'm not sure if it should share code with FShader or not. Mostly because FShader takes on additional duties along with FShaderManager to do materials rendering, caching and such stuff. If anything, maybe FShader eventually could use FShaderProgram as its lower level helper class for compile and link. Ideas on how to arrange this are very welcome.

The pull request also makes the window resize work and enables the maximize button. It will letterbox the output based on the window dimensions.

dpJudas wrote:[*]FShaderProgram is a generic compile and link class. I'm not sure if it should share code with FShader or not. Mostly because FShader takes on additional duties along with FShaderManager to do materials rendering, caching and such stuff. If anything, maybe FShader eventually could use FShaderProgram as its lower level helper class for compile and link. Ideas on how to arrange this are very welcome. [/list]

I don't know if it makes much sense. At best I think FShader could use FShaderProgram instead of accessing the GL functions directly.


Also, don't you want to put your own name into these files? Credit where credit is due, I haven't written that stuff.

I mostly didn't change the copyright statements as way of saying "do with it as you'd like". I generally find file copyrights to be a bit of annoyance as they get rather inaccurate over time. Anyhow, did a commit that puts in my name instead.

I just merged it but I cleaned up the commit history a bit. Before you continue working I'd appreciate if you do a clean checkout first.

Will do. Bloom and exposure control is up next.

Is it OK that this feature completely ignores compatibility layer for OpenGL 2.x, especially with shaders and buffers?
For instance, renderbuffers can available via extension. It doesn't require OpenGL 3.3, in fact they can be used on almost any hardware with OpenGL 2.1 support.

What was the point of inventing new renderbuffer class when almost the same functionality is already available in FHardwareTexture, BindToFrameBuffer() in particular?
Yes, there is no dedicated class for that but code duplication isn't good either. Same for shaders.

Honestly it's pain in a butt to support such changes for old hardware or for Apple's crappy drivers. #version 330? But why?
By the way, a while ago I also invented a wheel with shader based gamma correction I did for macOS. But then I replaced it with already existed classes if possible. It's still some junk left there but at least it doesn't affect other platforms.

Surely this feature can be used on all supported platforms/hardware but the current implementation simply prohibits this.
Probably you are not aware of but on Apple's over-expensive hardware GZDoom is still uses OpenGL 2.1. And lots of Windows people are still using ATI or Intel graphics limited to OpenGL 3.2 or even lower.

Yeah, the 3.3 limitation is something I also wanted to ask about. Availability of framebuffers is a requirement to even run GZDoom, of course on GL 2.x-only hardware I don't think it makes much sense to do this offscreen stuff, but that's an easily detectable case. About the framebuffer stuff in FHardwareTexture, I don't think that this would have been a good place to start, that code is meant to handle camera textures only and would probably benefit from being rewritten to use the new classes.

There's no particular reason that the cut off is exactly 3.3. I picked this particular version mostly out of convenience as its the earliest version of OpenGL I know of where I don't have to resort into extension testing for features I tend to take for granted. In this case, the code also relies on the GL_RGBA16F texture format and GL_DEPTH24_STENCIL8 - both of which I'm not exactly sure when they were introduced.

It should be safe to lower the version to whenever those two things were added to OpenGL.

Why does GZDoom only use OpenGL 2.1 on Mac? My MacBook Pro (Mid 2014) reports supporting version 4.1. My old Mac Mini (5+ years old by now) also supported some version of 3.x I'm pretty sure.

I didn't choose to use the existing FShader and FHardwareTexture classes because they operate at a slightly higher level of abstraction. I think in the longer run the best solution will probably be that there's a lower level of classes (i.e. something ala FShaderProgram for shaders, some FGLTexture for textures, etc.) that they both can tap into. Keep in mind that while you could say a texture is a texture, there's a difference between how they are managed. As an example, the arguments to FHardwareTexture::Bind make no sense for the rendering passes I'm adding.

On Macs, GL 3+ only exists as core profile. GZDoom does not perform well on core profile without persistently mapped buffers, and Apple refuses to implement that feature. So since the engine needs compatibility mode it is stuck on 2.1, thanks to Apple's great foresight.

Overall, this should try to attempt to be backwards compatible, if all things fail the texture can still revert to RGB8 on older hardware, for example. It may introduce some compromised features but that's still better than flat out refusing to work.

Okay, didn't know that - makes much more sense now why its critical to use extension testing for this stuff.

You do not need to test for the framebuffer extension. GZDoom won't even start if that is not present. But I also have no idea where these texture formats were introduced.