search

tzachshabtay / MonoAGS

AGS (Adventure Game Studio) reimagined in Mono
https://tzachshabtay.github.io/MonoAGS/
Artistic License 2.0
27 stars 8 forks source link

Brightness & Saturation #274

Closed tzachshabtay closed 6 years ago

tzachshabtay commented 6 years ago

Added brightness and saturation modifiers.

Brightness: allows to change brightness for each of the RGBA components separately. This is applied on top of the color tint, and allows to make the image brighter than it was originally.

Saturation: this comes as a separate component (as it uses a custom shader) and allows to modify the saturation of an image. It can either be applied to a specific entity or to the entire screen.

A demo where we adjust the brightness & saturation to our character from the inspector: Demo

Also added demos in the tweens panel.

Resolves #266

ghost commented 6 years ago

This looks interesting.

I have few questions. 1) Would it be too much or too difficult if this effect component could have all three HSV modifiers? 2) Why you can apply Tint and brightness in the engine code but saturation has to be applied using shaders? This question is rather of curiousity, because I do not quite understand the code behind it.

Hmmm... only now I realized that IHasImage.Tint.A and IHasImage.Opacity is the same thing...

3) So, I am trying to wrap my head around all those modifiers now, and it seems that -

tzachshabtay commented 6 years ago

Would it be too much or too difficult if this effect component could have all three HSV modifiers?

Well, I'm not sure if the saturation is calculated using the HSV model. It might be using the HSL model which has a different formula for saturation (or maybe it's using some other model). I basically found sample code with saturation modifications in GLSL and tried it out. Writing an HSV component (either instead of this one or in addition to), should be possible, it's just about finding the math/code that works (I would start from this, maybe: http://lolengine.net/blog/2013/07/27/rgb-to-hsv-in-glsl)

"Brightness" - is a way to multiply RGB values of the image. "Tint" - is a way to multiply image with particular color.

The tint and brightness are actually the same thing (a multiplier for the image color), only the brightness gives you more range (i.e to go beyond white).

Why you can apply Tint and brightness in the engine code but saturation has to be applied using shaders? This question is rather of curiousity, because I do not quite understand the code behind it.

The tint and brightness are also applied using a shader, they're just using the built-in shader. The built in shader already had support for multiplying with an input color which was the tint, and the brightness simply adjusts the tint before it's passed to the shader. Because the saturation is not a standard multiplication, I needed to either modify the built in shader or write a new one. Thinking that for #47 we'll have a model that allows combining multiple shaders it makes sense to write a different shader, and we'll probably refactor that to have "shader modules" which can be combined in some sort of shader shell, and at that point we might move the "multiply color" to its own shader module as well.

So I'm thinking about pushing this as saturation only, if you want to take a shot at doing HSV adjuster component to replace this, go for it, otherwise, this is probably something I'll tackle after doing the multiple shaders support (and possibly switching to Veldrid & ShaderGen: https://github.com/tzachshabtay/MonoAGS/issues/242) as those 2 are probably going to result in a rewrite of all existing shaders anyway). Once I've done those two, there are a lot of shader effects I want to add to the engine: HSV aside, I would also want contrast, color corrections, and effects like bloom/glow, fog, reflections, etc.

ghost commented 6 years ago

Thinking that for #47 we'll have a model that allows combining multiple shaders it makes sense to write a different shader, and we'll probably refactor that to have "shader modules" which can be combined in some sort of shader shell, and at that point we might move the "multiply color" to its own shader module as well.

Oh right, well, I was asking these questions because it looked like these properties overlap each other, so I guess this may be resolved by multiple shaders system.