Gamma Adjustment not working correctly??

[Rovastar]

Now is this a bug I do not know.

It is to do with the gamma adjust. This is used to control the brightness and as we know the more gamma a preset has the slow it is. Now I have no problem with that but what is very strange is the way it slows down.

Gamma = 1 = Normal
Gamma 1.001 to 2 = 15% slower (we will say for arguments sake)
Gamma = 2.001 to 2.999 = 30% slower or whatever.

Now what confuses me is that I expect this to be incrementally slower.

ie. Gamma = 1.5 = 7.5% slower. not 15%

Try it yourself it is very strange.
I think some code is not optimised enough. Maybe some odd int command in there somewhere.

It should not work that way should it?

If this is the case then most of the presets will have a boost in speed and that will make many people happy.

If not if we want the presets brighter at say 2.01 then you may as well have a brightness of 2.0 as you will not notice the difference and get a load of extra speed.

And the read_me should be updated.

If anyone else can raise any light on this let me know.

Off to email Ryan again for an explanation- I bet he is getting really pissed off with me. :)

Where on earth find out such bugs these things up.

Rovastar

[geiss]

Rova,

about the gamma... it's not a bug... that's just how it works. DirectX won't let you draw something with a color > (1,1,1), so if you want to draw it brighter than that, you have to first draw it at (1,1,1) overwriting whatever's in the framebuffer, then draw a second (or third, or fourth) pass, in an additive mode (where it adds to the color values in the framebuffer). So whether your gamma setting is 1.01 or 1.999, it still has to do two passes instead of just one, so you get that slowdown.

I recommend taking any presets that have a gamma in the range of N.0 - N.3 and taking them down to (N-1).99. (where N is some integer). (i.e. if a preset has a gamma in the range 2.0-2.3, try knocking it down to 1.99)

I'm not aware of any other way to do it... there is an optimization I've been considering that would take log2(N) passes instead of N passes... but since the vast majority of presets have gamma<=2, the savings would be minor, and this effect would have some speed & memory overhead anyway, so unless gammas of 4,5,+ become popular, I doubt I'll do it.

Anyway... hope this clears it up...

geissomatik

[Rovastar]

Ryan,

I sort have got you there but it still feels a little strange.

Maybe I am way off here but can you not reduce the 'blocks' eg. integer 'blocks' at the moment - gamma 1 - 2. make those 'block' 0.1 so you can get a more smoother effect. Blocks of 1 , 1.1,1.2,1.3,1.4, etc. 'Blocks' of 1 to 2 are really huge 'blocks'.

To me these 'gamma' 'blocks' are defined by you. A 'huge' block seems impractical.

PS I understand the 'workaround' of reducing 2.3 to 1.99, etc. If this really is the only way than can we not update the documentation and the on-screen help to say 'for increased performance only use the integer values' , etc

If this is the case then you should really update your old presets (many are below 1) so that they are at least brighter.

But I am sure you can have a better solution. I have faith in you.:)

:) It is unlikely that gammas of 4 or 5 will become popular.:)

John