DRD Team

https://github.com/coelckers/gzdoom/pull/108

This may be a bit OCD on my part (sorry) but I never liked how the shaders handled the vid_contrast and vid_brightness.

This does a considerable change - it removes the clamping from the contrast (which looked really ugly when combined with vid_brightness) and moves the gamma calculation to be last. (It probably could be first, instead?)

The result, I think, is a much more beautiful change when using these options, and they function a little more as they are intended (fixing renders on otherwise very dark monitors).

Note that this code needs to be in sync with the same math in OpenGLFrameBuffer::DoSetGamma (https://github.com/coelckers/gzdoom/blo ... r.cpp#L235). Otherwise the settings will produce different results depending on whether you're running windowed (shader gamma) or full screen (hardware gamma).

As for changing the math behind the gamma controls, I haven't studied the old math closely and just ported it directly over.

My gamma settings are pretty much the same as they are for all computer games the last 15 years: turn up the gamma a bit (never understood the need for such dark games) and then never touch those controls again. As a result, I have little opinion if your adjusted version is better or worse than the original.

By the way, the 'max' in the shader is needed to make sure that pow isn't using a negative value. The result of a negative value passed into pow is undefined, and due to our usage of rgba16f as render buffers we can, at least theoretically, have negative values as input to this function.

The negative clamping inadvertently killed it, in my opinion. Needless to say, if I go as far as fixing GZDoom's hardware gamma, I'll likely need to fix ZDoom's, too, which isn't a huge issue but it seems like this code could potentially be in 4 places (ZDoom might have a shader version, as well... but D3D shaders are almost the same language anyway, so shouldn't be an issue). I'm definitely going to have to play around with it. At any rate, I might just do the gamma pow first.

EDIT: Actually - ZDoom doesn't use contrast/brightness, only Gamma, so I can leave that one alone.

Fixed.

Looks good now when looking at the diff.

Thank you. I think next time I do a pull request for GZDoom, though, I am going to have to wipe and recreate my source tree. Having all that commit history, even if it's only pulls, kinda bugs me. XD

This bugs me, too. Please clean this up. In its current state it will create one huge mess because all those merges will be pulled into the permanent commit history.

Done.

Out of curiosity, how did you get rid of those commits?

I zipped my changed files, then deleted the branch, deleted my entire GZDoom repo, and cloned it again. Then unzipped the files back. Obviously I unzipped an old version of the files, but I fixed that in my next commit.

There's probably a much better way to do this. I know git allows you to change commit history - but I've never figured out how to actually do that. It's probably better the way I did it, anyway, as it ensures no unnecessary changes are made outside of the files I changed.

I had problems with Windows caching a ghost GZDoom folder but that seemed to be fixed by doing a chkdsk.

Okay, the method I might have used myself. Was hoping you had the golden nuggets on how to edit the history without me having to google it (just cba!). Interesting to know that github let you keep the pull request number even when you nuked the entire branch.

It didn't. That's my third pull request for the same feature, today. The original, 106, is too embarassing to even discuss. We don't talk about 106 here.

What you're probably noticing is a lack of edit messages on my posts. phpBB doesn't tag moderator edits unless the moderator attaches a message to it, but they still show in the MCP except when you edit your own post. I don't really know why phpBB did that this way.