in the core options to play master system there is an option to automatically disappear these bands on the left side of the screen
Hey @kokoko3k , how these backlight work? Can this feature run with @HyperspaceMadness MegaBezel Shader?
2 Likes
This feature isn’t there yet, but it has been planned for some time, so will come eventually, maybe this year 
6 Likes
The latest development version, the preset in the picture below is a bit abnormal, please take a look, thank you.
No problem, I understood why it happened. Will fix today, thanks.
It works by sampling a lowres version of the picture alongside the border of the imaginary screen, then it puts some virtual leds (actually smooth circles) upon it with the same color of the sampled zone. Those circles color/size (light/power) and border sharpness (falloff) are controlled by user parameters and their colors will eventually sum up each other.
In every next frame that color is also averaged with particular strategies with the previous one to make the fades slow or fast over time, depending on user preference.
This ensures that the led lights does not distract from the main game, but for the very same reason, some heuristic code is also used to detect when the picture/scene has changed so that the fades will be faster in that case.
Seems complicated? Yes, it has been a pita, but i’ve’had already wrote part of that code for arduino to drive real leds under my real lcd
Btw the code is solid now and reusing it into @HyperspaceMadness’ s MegaBezel should be definitely possible!
5 Likes
Thanks,it’s perfect 
1 Like
Wops sorry, I forgot to inform you, the issue has been fixed.
3 Likes
I’ve reimplemented the colorization feature, and now it should not leak anymore. Apart from the colorization taken from the ambient, there are more parameters to play with for what concerns the bezel, like the reflection blurriness, strengths and specular reflections strength.
7 Likes
That’s very cool. I think I should disable this feature in my RGB presets anyway, since the idea doesn’t fit this feature. I’ll update the presets right away.
Speaking of which! There’s some sweet stuff coming to koko community presets by @soqueroeu here are some leaks:
There’s even new portrait overlays:
@kokoko3k I hope, if possible, you’d make an automatic solution for these type of overlays, so for example, when rotating the display to portrait mode while using lets say, FBNeo horizontal, then the shader will auto switch to FBNeo portrait.
I think Duimon implemented a similar feature in the Duimon mega bezel packs.
3 Likes
Uhuh, really nice!
As for automatic rotation, I’ll have to take a deep look.
Understand what is the problem to be solved, will be the first step 
3 Likes
For Auto-Rotation what is currently possible in retroarch is to take a look at the aspect from the viewport resolution. There is a $VIEW-ASPECT-ORIENT$ wildcard which can be used to redirect to different params files for vertical vs horizontal viewport aspect. Keep in mind that this only gets evaluated at preset load.
If you are talking about something like FBNeo core rotation, then you can use the $CORE-REQ-ROT$
The doc for the wildcards is here: Shaders - Libretro Docs
8 Likes
@kokoko3k I updated my presets, adjusted some parameters, and put all of them in one shared folder to allow for switching on the go via M & N hotkeys.
As usual, they go inside the main koko-aio folder (shaders/shaders_slang/bezel/koko-aio).
2 Likes
Yes, I understood that, but still that magic happens before the shader code per se, since it is unaware of what happens in the .slangp for what concerns the texture/luts filenames, hence there’s no much to do by my side (read: koko-aio was already capable of detecting if the core requested viewport rotation, but without different lut bindings for them to avoid excessive branching).
@Starman99x:
I just pushed your updated presets to presets and overlay repo, thanks!
If you want to load different textures files for different rotation states, you just have to edit one .slangp according to naming conventions/wildcards supported thanks to the new features; koko-aio (like any other already pre-existing shaders) is just ready for that.
As a recap, the luts that may be of interst in that context in koko-aio slangp files are:
- bg_over: the texture applied “over” everything that shows underlying things (game, bezel, ambient lights) via alpha channel.
- bg_under: the texture that sits between the bezel and the ambient light and that show underlying things (ambient lights) via alpha channel.
So you can edit the slangp with something like:
bg_over=path/to/some_name_$VIEW-ASPECT-ORIENT$_some_name_post.png
Then you name those texture files:
- path/to/some_name_VIEW-ASPECT-ORIENT-HORZ_some_name_post.png
- path/to/some_name_VIEW-ASPECT-ORIENT-VERT_some_name_post.png
Those filenames will be alternatively picked, depending on the game orientation, that way, you can have one .slangp that uses different textures for horizontal games and vertical ones.
It is handy, of course, but it would save just one .slangp, because $VIEW-ASPECT-ORIENT*$ assumes just two values.
The real gain that comes from that features, lies in the opportunity to have one slangp to load “TONS” of different texture files when the wildcard substitution can have many different values (see wildcards: $GAME$, $CORE$, $PRESET_DIR$), exponentially growing when you combine them into a single wildcarderd fileneme, eg:
bg_over=path/to/some_name_$GAME$_$CORE_$VIEW-ASPECT-ORIENT$_some_name_post.png
So, my question, in this context:
“what is the problem that needs to be solved?”
…would have been answered:
“to use one .slangp instead ot two for horizontal and vertical games”.
Ok, maybe more because i read that apart from H and V orientations, the game could be rotated by 0,90,180,270 degrees, but i repeat, the real gain comes from being able to support tons of combinations.
3 Likes
Very interesting I’ll try this, thank you!
How are you able to detect this in the shader code?
Yes.
If a core requests rotation and does not pretotate, you can do this in a pass that scales to viewport:
#define ar_tolerance 0.1 //To compensate when comparing different A/R
bool is_rotated = (abs((params.OutputSize.x/params.OutputSize.y) - (global.FinalViewportSize.x/global.FinalViewportSize.y)) > ar_tolerance);
…that basically exploits the fact that “Output” aspect ratio differs from “FinalViewport” aspect ratio in a pass that scales to viewport.
Maybe this is a bug in retroarch, maybe it is intended, but it is working fine since months here.
If you ask me what is ar_tolerance and why on earth is there, blame me for not being wise enough to comment it enough
2 Likes
I’ll have to test this, what does OutputSize give you, some multiplication of the core size? Or does it give you 9:16 vs 16:9?
If i’m not wrong it gives 1/aspect
1 Like
@kokoko3k is it possible to place a background image under the bg_over.png and under the LEDs at the same time?
This would allow for more flexible overlay designs, like having a reflective metal layer under the grille in this design by @soqueroeu:
As you can see, the grille is cool and all, but the backlight is reflecting on nothing, it doesn’t look right.