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.
Mmh,
Check if I understood the final result you want:
you want to see not just a flat ambient light under the hexagons, but a more complex pattern mixed with the ambient light, is that right?
Since having more textures means more work for the shader, wouldn’t be equivalent to do this right in bgover?
In your gfx program, place the layer you want under the hexagons and make it semitransparent.
That way you’ll have the very same pic you just posted, but under the hexagons there will be the layer you placed, colorized by the ambient light by the same amout of the layer’s alpha channel.
Does it feel right?
1 Like
Sounds interesting I’ll try it. I thought it was already possible to use a bg_under.png since some textures were named this way.
This workaround you suggested sounds interesting, mind that what I’m trying to do is have the light reflect on a metallic layer not come through it, I don’t think the end result will be the same. But I’ll test it and show you.
1 Like
Yeah, i suppose you’re right:
through => alpha blend modulates a mix
on => alpha blend modulates an add
I’ll try to add an option so that ambient lights are added instead of mixed to/with bg_over and bg_under.
3 Likes
@Starman99x
I pushed a possible solution right now:
As you can see, there is a new parameter named “Back/Foreground image alpha blend”
- mix (0, the default) is the old behaviour, the leds are supposed to stay under a translucent image.
- add is a new possible value where the leds stay to the front. As usual, the amout of mix or add is modulated by the alpha channel, I hope this would be enough.
Also, colorization size, set to a low value, will avoid the ambient light to bleed over the tube, keep it in mind.
As a side bonus, since i was there, i decided to allow to always add a certain amount of the led lights over the foreground image when the alpha blend mode is set to add, this gives a nice effect:
Have fun!
4 Likes
Wow! This looks cool! I’ll play around with it and see what I can make.
But I have one small issue with the rotation stuff we discussed before, so I tried to load different texture files for different rotation states, but I couldn’t follow your instructions well, and it didn’t work, here’s how I named things:
- Inside the .slangp I put:
bg_over= “…/shaders_slang/bezel/koko-aio/textures/FBN_$VIEW-ASPECT-ORIENT$_FBN_R.png”
- Then I named the files/textures like this:
FBN_VIEW-ASPECT-ORIENT-HORZ_FBN_R.png
FBN_R_VIEW-ASPECT-ORIENT-VERT_FBN.png
Here’s the texture files too:
I know you have to run the latest retroarch for it to work, and according to this doc it seems it should.
What happens when you run your presets? An error or maybe it seems to ignore the substitution?
To test, i’d need the whole slangp too.
I can give a deeper look by tomorrow…
1 Like
This is what happens:
It loads the default bg_over.png. Here’s the slangp too.
Take your time, sorry for making a lot of requests.
1 Like
Gave a quick look and It seems right, but didn’t tested it.
@HyperspaceMadness : do you agree?
@Starman99x: Are you sure you’re using the latest RA version?
What puzzles me is that it doesn’t throw an error, but just uses the main texture, like the override is missed through the reference jumps.
what happens if you simplify and just use a single reference?
Are you sure you’re loading the right preset? Sorry for the question, but I couldn’t find an answer by myself.
1 Like
Yes I’m using version 1.15.0, I’ll try your suggestion and see what I can do.
Looks right, but what I recommend is opening the log window as mentioned in the docs which will show you warnings/logging about what it was looking for
This is my thought as well.
Ok actually now I see the problem, there is no space after the texture name, it needs a space E.G.
bg_over =
vs
bg_over=
I need to see if we can add some sort of warning for this when a config or preset file is loaded, since this is a general retroarch issue
3 Likes
Now, @kokoko3k - I need to complain: How will I EVER be able to make a new release of the arcade shaders if you provide additional killer features on a weekly basis?!?!?
Edit: New screenshot, I apply 85% Alpha just on the bezel, and it takes the color from the ambient light very nicely … so here goes my release, back to work.
What a killer feature!!!
3 Likes
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:
zoom out:
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:
- FBN_Rotated_VIEW-ASPECT-ORIENT-VERT_FBN_Vertical.png
- FBN_Vertical_VIEW-ASPECT-ORIENT-HORZ_FBN_Rotated.png
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:
- same-pre-string-as-other-VIEW-ASPECT-ORIENT-HORZ_same-post-string-as-other.png
- same-pre-string-as-other-VIEW-ASPECT-ORIENT-VERT_same-post-string-as-other.png
…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.
2 Likes
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:
- “clamp_to_border”
- “clamp_to_edge”
- “repeat”
- “mirrored_repeat”
…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.
1 Like
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.