To make it perfect it would be necessary to add the option “Horizontal Position”
There are some games in e.g. Master Sysem with these black stripes on the sides instead of top or bottom.
2 Likes
Damn Mastersystem. 
Lol,Snes also has several games like Out of This World (Another World),Jurassic Park,Prince of Persia and more and other systems,so I think it would be a good choice 
Btw, it should be trivial to add at this point, but still I wonder if this is a valid use case.
For x aspect ratio, there is the motivation of watching 16:9 content on 4:3 tube, but cutting black borders (x or y) that way, means modifying the creator’s intended aspect.
I can understand the need to just shift the image left/right for sega mastersysyem titles.
Aldo, for black borders all around, when using bezels, you can zoom the whole content with ‘zoom image’ parameter in bezel options group.
EDIT
PS: I see you’re using Duimon’s backgrounds.
Are they from the koko aio additional artwork repo or you’ve made it yourself?
Just asking because probably I’ve to fix reflection offsets a bit on those presets now,
Yes, perhaps at each person’s choice, since you are modifying the aspect ratio of the original game.
Horizontal shifting is in the latest git (not perfect, but usable).
About horizontal stretch, i decided to add a generic “zoom” control which works even without bezel (maybe i’ll ditch bezel zoom control), that, alongside the aspect ratio control should allow everything.
eg: Lionheart expanded horizontally via aspect + zoom
3 Likes
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