Koko-aio shader discussions and updates

[kokoko3k]

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.

[Starman99x]

Very interesting I’ll try this, thank you!

[HyperspaceMadness]

@kokoko3k

read: koko-aio was already capable of detecting if the core requested viewport rotation

How are you able to detect this in the shader code?

[kokoko3k]

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

[HyperspaceMadness]

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?

[kokoko3k]

If i’m not wrong it gives 1/aspect

[Starman99x]

@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.

[kokoko3k]

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?

[Starman99x]

@kokoko3k

In your gfx program, place the layer you want under the hexagons and make it semitransparent.

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.

[kokoko3k]

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.

[kokoko3k]

@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!

[Starman99x]

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:

1. Inside the .slangp I put:

bg_over= “…/shaders_slang/bezel/koko-aio/textures/FBN_$VIEW-ASPECT-ORIENT$_FBN_R.png”

2. 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:

FBN_R_VIEW-ASPECT-ORIENT-VERT_FBN.png and 1 more file

[kokoko3k]

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…

[Starman99x]

This is what happens:

It loads the default bg_over.png. Here’s the slangp too.

@kokoko3k

I can give a deeper look by tomorrow…

Take your time, sorry for making a lot of requests.

[kokoko3k]

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.

[Starman99x]

Yes I’m using version 1.15.0, I’ll try your suggestion and see what I can do.

[HyperspaceMadness]

@kokoko3k

@HyperspaceMadness : do you agree? @Starman99x: Are you sure you’re using the latest RA version?

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

@kokoko3k

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.

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

[estefan3112]

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!!!

[Starman99x]

@HyperspaceMadness

Ok actually now I see the problem, there is no space after the texture name, it needs a space

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.

[kokoko3k]

@Starman99x

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.