Indeed, that was the problem. But now we have another problem:
While the horizontal orientation worked fine, when rotating screen orientation via RetroArch/Output the rotated/vertical texture is not being utilized, instead it’s the horizontal one zoomed in:
I tested this with both MAME and FBNeo cores.
Here’s a new zip that contains a test preset with new textures, the preset goes into Retroarch/shaders. While textures go into koko-aio/textures.
I downloaded your texture and presets, but it’s not clear to me what are you trying to achieve.
First, take in mind that after changing any retroarch option, you have to reload the shader for it to react to changes and behave differently.
As far as i can understand, the wildcard you are using is to load different textures for rotated and unrotated output displays, so your goal is to use different textures for whan the viewport itself is rotated, gotcha.
…but there are incongruences in your slangp.
You used:
bg_over = "shaders_slang/bezel/koko-aio/textures/FBN_Vertical_$VIEW-ASPECT-ORIENT$_FBN_Rotated.png"
The you provided 2 textures:
wildcard matching will never select the first one, see that it ends with “Vertical”, while the wildcart itself $VIEW-ASPECT-ORIENT$ is supposed to assume two different values:
VIEW-ASPECT-ORIENT-HORZ or VIEW-ASPECT-ORIENT-VERT
So the correct naming for it to pick different textures is:
…and in the .slangp: bg_over = “/path/to/same-pre-string-as-other-$VIEW-ASPECT-ORIENT$_same-post-string-as-other.png”
In other word, texture names has to be identical, the only things that can change are the strings in place of any $WILDCARD$
-edit-
…and understood.
Since koko-aio is aware of the rotation state, it already had the ability to rotate the background image, and it does exactly that.
It is configurable:
from koko-aio docs.md:
Rotate image mode
This could be needed when dealing with vertical games.
Use -1 to let the shader try to guess if the rotation is needed.
So, it you want to provide different textures by yourself and manage this externally, set the option to 0.0
Other issues regarding the texture naming are still valid.
Hi there estefan,
I was rethinking to the Wrap mode function i added a while ago and come to the conclusion that it is useless and maybe I started this mess by answering you the wrong way.
The right answer is “yes” there is an alternative way to do that.
bg_under_wrap_mode and bg_over_wrap_mode can take several values:
…and you set them in .slangp the same way you set any other parameter.
So my question is:
Is really needed to change the wrap mode as a runtime option in the shader?
Ditching it would free the code from some branching and complexity.
I’d ask you to try to set Wrap mode in koko-aio to default and use the retroarch’s builtin bg_under/over_wrap_mode instead.
If you’ll be able to do the same things as before, i’d cut that code from koko-aio.
Can you send the properly named files and properly edited slangp so I can take example from them? Because I’m still a bit confused about naming.
Hi again, @kokoko3k. I do not need a runtime option, although it is of course nice to test in real time. But no problem to edit that in the preset. In my use case, I will hardly ever head for a repeat option as it looks weird with real looking artwork. Best, Stefan
@Starman99x
Stripping the file paths for clarity, In slangp i used:
bg_over = “same-pre-string-as-other-$VIEW-ASPECT-ORIENT$_same-post-string-as-other.png”
The filenames i used:
See? the only thing that can change is the BOLD TEXT
@estefan3112, right then, i’ll cut it off.
…done, i made another static option in config.inc:
// #define ALLOW_BG_IMAGE_TEXTURE_WRAP_IN_SHADER
That way you can easilly have the old functionalities by removing the leading “//” and it won’t impact performance as long as it stays commented.
koko please go easy on me 
I still don’t get it, what does this mean:
and this:
If you can just provide a ready to use preset with properly named textures, I’ll be able to follow you more clearly.
It means that text is common to both filenames. I literally use that filenames!
Just use that in place of your bg_over=xxxx (prepend the path ofc) and everything will work.
#reference “shaders_slang/bezel/koko-aio/monitor-slotmask-bloom-bezel-backimage.slangp” BG_IMAGE_OVER = “1.000000” DO_AMBILIGHT = “0.000000” DO_GLOBAL_SHZO = “1.000000” GLOBAL_ZOOM = “1.005500” BG_IMAGE_WRAP_MODE = “1.0” bg_over_wrap_mode = “clamp_to_border” bg_over = “shaders_slang/bezel/koko-aio/textures/same-pre-string-as-other-$VIEW-ASPECT-ORIENT$_same-post-string-as-other.png”
This is what happens when I turn auto rotate image off:
Now the horizontal image is flipped wrong.
And the vertical image/texture still doesn’t show up when I rotate the display. Even after reloading the shader.
So I decided to give up on this and just make a separate slangp for rotated displays.
But if somebody is willing to help make this possible (to make an auto rotate preset), here are the files I used, so make something that works with them, and I’ll include it in the upcoming pack I’m making from @soqueroeu new designs.
Maybe there’s a better way to do things if we take a look at the “Updated vertical presets with automagical variables” by @Duimon I just couldn’t figure it out on my own (I’m still a newbie).
It worked for me, weird. btw, maybe those new features deserve a thread to be explored deeply.
Hey, it’s cool you are enjoying working with this stuff 
Keep in mind if you are doing your own packs and distributing them you need to be careful including graphics created by others to make sure you are getting their approval and following their licences.
This is important so we don’t inadvertently take away from the hard work and talent they have poured into these wonderful creations.
As an example of licenses, the graphics in both @Duimon’s and @TheNamec’s packs have a license which does not allow someone else to distribute them without permission, it could be the same with @soqueroeu’s unique creations.
Ok I created one:
Roger that. As for Soqueroeu’s stuff I’m only making a pack for him which he himself will post if he wanted, he was kind enough to make the graphics for me upon request anyways. I just didn’t want to keep them for myself and I’m trying to make them utilize the features of koko-aio to the fullest.
Hi @kokoko3k - suddenly problems in Windows11/Geforce RTX 2070 during testing: All games show ugly and flickering pixel artifacts (see screenshot, tested also with today’s changes). The problem does not arise with the koko-aio version of my version 0.1 release (around January 29). It is independent of he presets used, so just switching back to the version 0.1 shader release removes the artifacts. Any idea how I could debug this??? 
Any hint appreciated, many thanks!
EDIT: Ok, it also occurs with your Commodore standard preset as well. Only Windows so far, no troubles on Macs and iPad.
No problem, I’ve seen that in the past and fixed, I just need to test on nvidia myself.
-edit-
Found it, it is not (only) a matter of gpu, it is vulkan behaving a way versus glcore behaving the other, i’ve reproduced under intel and amd by switching from glcore to vulkan, didn’t yet on nvidia.
You can confirm the issue is the same by enabling ambient light with the commodore 1084s preset. Doing that should clear the glitches till i’ll fix it properly.
Correct! Enabling ambient light removes the glitches. Another reason to head for your most recent edits in the ambient light department 
.
It should be fixed now.
Works - many thanks!
Sorry, another question to #define ALLOW_BG_IMAGE_TEXTURE_WRAP_IN_SHADER
After activation in config.inc, it seems that the default behavior in my own presets is not “mirrored repeat”, but “clamp to border”, which is a mystery to me. I have no special setting in my shader preset, but it nevertheless defaults to “clamp to border”. My presets reference from the “monitor-slotmask-bloom-bezel”-preset (today’s github revision).
Even if I like the result, I would like to understand why this is so…I thought that I would have to add this option to the preset, but it works from alone as well…no mirrored repeat any longer.
Many thanks!
I did not changed anything and it is a mistery for me too, as it works as it should here!
Exploring now the possibility to emulate a sort of dynamic contrast. When the global luminosity of the scene goes up, the global scene illumination goes down:
…to return to full brightness on darker scenes:
This is entirely implemented in the shader, no extra texture required, but i’m not 100% sure it would be useful and probably would need some tweaking (eg: the reflections should stay up).
In the worst case, i could keep the code to tweak the background luminosity as a user parameter.
What do you think?
