Thank you, now it works!
I’d like to solve that at shader level instead of relying on presets/wildcards.
However, fixing this may be too complex to be made before release.
Yeah… I’m a bit concerned that any internal changes might break compatability with my presets and method. 
I’m keeping that in mind, and will submit for review, no worries 
I just made the change, it can be reverted easilly.
The bezel reflective area now has a single color in the png, and the shader changes it’s brightness.
Left right side have the same brightness; the up side is slightly darker, and the lower side is slightly brighter.
Doing that allowed it to be adapted when the content is rotated:
Brightness values are now hardcoded, but could be configured via parameters if needed, eventually.
@Duimon @estefan3112 @Starman99x
Since it only touches the internal frame area it should not interfree with any outer frame image, but please, do your testing.
Sounds elegant. I have no problem with updating my source and generating new bezel images.
If it works well it will clean things up a lot.
Ah, because you crafted your own monitor frame with rgba channel layers?
I think I missed or forgot about that.
If you need different kind of shades for the inner sides, then I can turn the hardcoded values into params, let me know.
Wrong scanline direction
Speaking of 1942 - I am truly puzzled: Why is the reflection in my preset not mirrored upside down? I have no clue how to achieve the same result as in the referenced setting, where it is correctly upside down. Many thanks for some hint, @kokoko3k!
EDIT: Nevermind, I started all over, the preset was a mess anyway. Now all fine again.
I don’t think so. What RGB, or HEX value did you use for your inside RED color?
In the end this will simplify my presets, and make my job a lot easier.
Such a simple question requires a not so simple answer!
Speaking of bezel reflective area, png now is all flat 116/256.
Shader now modifes the brightness that comes from the red by adding -28 up, -10 left/right and +5 down.
tl:dr:
Long story short, the color brightness of the reflective area is the same as the previous implementation only for a value of bezel contrast = 0.0.
Why:
When it comes to the contrast parameter in the bezel section, it used to modify the contrast as you would expect from a gfx program, but it was flawed in the sense that it blindly operated on the r component (brightness), which included the “hardcoded” shades in the png.
Now that the shader draws them by itself, my choice was to let them untouched, so if the shade is set to subtract 5 from the underlying color, it will subtract 5 even if contrast is set to 2.0, not 10.
I meant the hex color value of the image in GIMP. Did you choose the value that was previously on the sides?
I am unfamiliar with this syntax.
The non reflective area was left untouched if you meant that, the inner area, the reflective one, is roughly the same as it was on the bottom.
edit: 116/256 means 116 in a scale from 1 to 256, almost half gray.
Beautiful work! Can this be also used to workaround the glcore flipping issue?
Edit: unfortunately the new solution did not work with pacman:
While it worked fine with 1943, as each game rotates differently (90° vs 270°).
Ah… I get it, 116,0,0 in RGB. (The 740000 will give me what I need. Thanks for the screenshot!)
I will get a chance to take it for a spin tonight and tomorrow afternoon.
If it doesn’t affect performance, converting the hardcoded values to parameters would allow for this to be fixed by the user. (And wildcards in my presets.)
Hello again bud. Please dont give up on the Noise department. It really gives a better boost for RF presets even further. This effect is so little explored through the long list of shaders.
I agree. It would also help us make a new workaround for the legendary glcore flipping.
That’s my fault. Retroarch exposes the rotation correctly since some release, so I should have what I need to fix that internally.’
…however this cannot be fixed by the shader, but you already have the needed tools to flip the shades.
Indeed I’m using a lut to identify the screen sides, it’s under textures/side_shade-helper.png
You can use wildcards to rotate/flip it (include a rotated lut in the slangp), shader will react.
Normally green identifies the left/right, blue up, red down.
(Rethinking to that, the lut can be (ab)used to drive the shades strenght too…)
To recap, I’d take care of 270deg rotation, while for retroarch bugs, a workaround via wildcards will be needed.
ahah. 
I just pushed some changes.
-
Corrected reflection area shade placements for 270 deg. rotated titles,
so pacman and friends should be fine now. -
Spot: corrected spot placament for 90 and 270 rotated titles,
so spot position should be consistent across 90 and 270 rotated titles.
If you used to correct that by wildcards trick, you should remove that (retroarch bug with flipped images still needs workarounds tho). -
Lowered side_shade-helper.png by 4x brightness and compensated it in the shader.
Being the helper lut darker, you can edit it and include in the preset to alter the shades. RGB channels now have a brightness of 64/256 each, which produces the default shades.
If you push one of rgb channel, the corresponding side will be darkened more, lowering it will darken less. -
Added two variants of side_shade-helper.png
- side_shade-helper-flip-y.png: an y-flipped helper texture meant to be used alongside wildcards fo overcome retroarch issues with cores that flips images
- side_shade-helper-sharp.png: a not blurred version of the lut, which may be useful if you want to blur or not as you please; this affects the smoothenss of the shades.
Here is shown how the bezel contrast setting still affects shades on the outer bezel gradients, and outer frame vs inner frame difference, but not reflective area shades.
r,g,b=0.01,-0.02,0.00 ; contrast=4.60.
“Noise” is a generic term.
Latest additions include the ability to generate the RF noise before or after the blur/glow stage.
If one is using the glow, it is probably a good idea to leave the noise before it, but in situations where blurring is used, then one may prefer to “enjoy” a more sparkling noise and avoid to blur it by moving it after that stage/pass.
Now rf noise is splitted in two parameters, uniform one that produces a noise between [-x and +x] and a “snow noise” that produces very rarefied/casual “points” over 0.0.
The other “Noise” added lately is the dot crawl:
…theory states it should be an invisible effect that manifests only when something moves on the screen, but my memories suggests it is visible even on static content, so I’ve added a “Speed” parameter that moved to the max switches to the “Theory”, but in the PAL preset i crafted, it resambles what I remember, instead.
Same goes for the ability to set the speed parameter that switches the checkerboard crawling direction to vertical instead of horizontal, I rememember those pattern moving vertically, but this time i’ve set the PAL preset to horizontal.
Thanks for the info.
Do you know if there’s a chance to import the more available set of options to use for Noise, being provided by this guy ?
The few times I’ve found “Noise” being available, such as CRT-Guest-advanced presets, there’re only 2 options at most, which if remember correctly is Noise resolution and another one, but there’re not other ways to play around.
I still do have a 34+ years old NES being connected through coaxial RF, with dithering + rainbows + “noise”, yet it looks quite different from what is shown around these Noise options. More likely look like grey diagonal rays on the screen, but these options more likely look like small squares that can be increased on size. Be that as it may, the options from PlainOldPants allow to apparently change the size from the noise particles.
Thanks again for the work on here!