Desaturation for DoF

kingeric1992 wrote: Read from backbuffer instead.

And you dont have to output coc coeff to buffer unless you wish to reuse the resource later.Plain function will work fine in this case.
also the fact that you can write to backbuffer itself while read, the des effect along can be recuced to a single pass effect.

please alphabetize the tabs, they're now in random order it seems (which makes it harder to find tabs!). A better UI might be a tree on the left and the pane on the right the same as what you display now on the tab)

the sliders to change values are really small and if you want to set a specific value you can't: make them move less fast when e.g. shift is clicked so you have more control, also e.g. make them reset when double clicked

the offline preview is nice, but the picture can't be shown full screen. This is a bit of a problem if you e.g. want to finetune AA: the screenshot loaded to tweak AA is not displayed full screen so some smoothing is already taking place as the picture is slightly desampled.

Marty McFly wrote: Well you will be making great progress as you already have plenty of programming knowledge. Shader coding is different though, usual coding is mostly logic while this is mostly math. And usually you only clean code to make it, well, clean but in HLSL, performance matters.

LuciferHawk wrote:

please alphabetize the tabs, they're now in random order it seems (which makes it harder to find tabs!). A better UI might be a tree on the left and the pane on the right the same as what you display now on the tab)

I guess you mean the tabs in a suite. They could be ordered alphabetically or by some (random) logic but its a freedom of the developer to make that choice. The order of shader in the settings file defines their order in the mediator. Hence, if a suite manager/dev decides to have a alphabetical order, he changes the order in the settings file accordingly

About the tree, you noticed already that the tree is already spanned just currently with the tab design. Changing this design rather significantly is further down on the list but is indeed considered already.

the sliders to change values are really small and if you want to set a specific value you can't: make them move less fast when e.g. shift is clicked so you have more control, also e.g. make them reset when double clicked

Size is a compromise to consider usability and the amount of at once visible elements.

Not sure what you mean by speed. When using the mouse, it follows the pointer instantly, doubt that a delay or reduced mouse movement would make sense here
Using arrow keys however is currently the method to transit to accurate slider movement once the curser is set in range of the desired value.

the offline preview is nice, but the picture can't be shown full screen. This is a bit of a problem if you e.g. want to finetune AA: the screenshot loaded to tweak AA is not displayed full screen so some smoothing is already taking place as the picture is slightly desampled.

Its planned and I think it should not be a problem to be added. (fingers crossed)

On topic of the original vs backbuffer, since the Framework allows to reorder shader, a developer cannot be sure anymore about the input to its shader. To allow independence of previous effects, the initial backbuffer is stored and can be retrieved from RFX_original.
The DoF and AO source currently use the original buffer copy because it was historically meant to be the first shaders in the pipeline. It also needs to be changed in this case to RFX_backbuffer

A few comments to your uploaded code:
Suites should be seen as broad domains. I would appreciate if you could add the shader to an existing domain for now (though I admit that some of them become crowded).

From what I see, the only thing that you need to adjust for the mediator to work is your defines in the settings file:
Only one space between key terms.

#define WhiteSpace Name WhiteSpace Value WhiteSpace // WhiteSpace [StartValue:EndValue] WhiteSpace // WhiteSpace description EOL

private static readonly Regex _procMatchingMatcher = new Regex(@"((?<catalogName>\[[\w\. \$@#]+\]|\w+(?=\.)).)?(?<schemaName>\[[\w\. \$@#]+\]|\w+).(?<procName>\[[\w\. \$@#]+\])", RegexOptions.Compiled | RegexOptions.CultureInvariant | RegexOptions.IgnoreCase);

Adding ranges or [undef] for each variable.
Add the comment section //- that you can leave empty if you want.
In terms of naming conventions, a few variables should not be capitalised but I am actually not sure whether all our shader follow that already.

Anyway, I am happy once again that it seems rather unproblematic to get into the structure

Ok, though I think it's currently harder to use

You're currently parsing the .cfg files and converting what you're seeing directly into UI controls. It's in general better to split that up, as you then have more freedom.

I ran into this when copying some values over from a preset compatible with older reshade versions and I wasn't familiar with the reshade files yet.

Constructing regex's is like dropping stones on your feet all day but once you get it right, it's very easy and essential for parsing texts

Therefore, I was confident with the design which allowed me to skip the separated data structure and its redundant storage. Other than that it is behaving pretty much the same as if there was one, only swapping to another design (which I was not intending at the beginning) is the downside of that choice.