Koko-aio shader discussions and updates

Sorry guys, unfortunately those params are an heritage of the past when the shader had a different structure that changed to accomodate new features and a more efficient chain/pass strategy.

At least, the good news is that it gained a bunch of fps.

I always try to keep docs updated, notify here on the forums and write descriptive git commit messages when critical changes are made, so if you have a github account, a smart thing to do is to subscribe to be notified in real time.

I’m still working on the dot crawl thing since I’m not satisfied of the result, but other than that, I don’t think the code would change before the next release, which should arrive soon.

4 Likes

That’s alright. It’s your shader so do what you will and us that do presets can go with the flow.

1 Like

Hello @kokoko3k, I have a bug report here, and it might be out for longer already:

  • Only vertical games are affected.
  • If Image Rotate/flip is set to Automatic (default value), then “Zoom Image” and “Shift Image over Y Axis” do not work.
  • But if you manually set the Rotation to an actual value, then both “Zoom Image” and “Shift Image over Y Axis” start working again.
  • Tested here both with the latest development code and the last release 1.9.30 Hope this helps, cheers!
1 Like

Ok thanks, tomorrow i’ll give it a look!

1 Like

Well, I have enabled the customization.

However I found my code commented about explicitely denying it but without further explainations, so I’m not really sure why I made that way in first place.

Please, test and see if there are some weird behaviours :slight_smile:

2 Likes

It seems that rotated/vertical arcade games require a rotated bezel frame (90 or 270), regardless of the video driver in use (not a flipping issue). And simply rotating the bezel png file does not give a good result (further edits are required). So I suggest that you take from Duimon’s example and make extra rotated bezel frame files; auto enabled with $CORE-REQ-ROT$ wildcard.

I’m stuck here :sweat_smile:

What do you mean?

Edit: ↓ Got it, thanks

1 Like

1 Like

Thank you, now it works!

1 Like

I’d like to solve that at shader level instead of relying on presets/wildcards.

However, fixing this may be too complex to be made before release.

2 Likes

Yeah… I’m a bit concerned that any internal changes might break compatability with my presets and method. :frowning:

I’m keeping that in mind, and will submit for review, no worries :wink:

I just made the change, it can be reverted easilly.

The bezel reflective area now has a single color in the png, and the shader changes it’s brightness.

Left right side have the same brightness; the up side is slightly darker, and the lower side is slightly brighter.

Doing that allowed it to be adapted when the content is rotated:

Brightness values are now hardcoded, but could be configured via parameters if needed, eventually.

@Duimon @estefan3112 @Starman99x

Since it only touches the internal frame area it should not interfree with any outer frame image, but please, do your testing.

3 Likes

Sounds elegant. I have no problem with updating my source and generating new bezel images.

If it works well it will clean things up a lot.:grin:

3 Likes

Ah, because you crafted your own monitor frame with rgba channel layers?

I think I missed or forgot about that.

If you need different kind of shades for the inner sides, then I can turn the hardcoded values into params, let me know.

3 Likes

Wrong scanline direction :grin:

Speaking of 1942 - I am truly puzzled: Why is the reflection in my preset not mirrored upside down? I have no clue how to achieve the same result as in the referenced setting, where it is correctly upside down. Many thanks for some hint, @kokoko3k!

EDIT: Nevermind, I started all over, the preset was a mess anyway. Now all fine again.

1 Like

I don’t think so. What RGB, or HEX value did you use for your inside RED color?

In the end this will simplify my presets, and make my job a lot easier. :grin:

2 Likes

Such a simple question requires a not so simple answer!

Speaking of bezel reflective area, png now is all flat 116/256.
Shader now modifes the brightness that comes from the red by adding -28 up, -10 left/right and +5 down.

tl:dr:
Long story short, the color brightness of the reflective area is the same as the previous implementation only for a value of bezel contrast = 0.0.

Why:
When it comes to the contrast parameter in the bezel section, it used to modify the contrast as you would expect from a gfx program, but it was flawed in the sense that it blindly operated on the r component (brightness), which included the “hardcoded” shades in the png.

Now that the shader draws them by itself, my choice was to let them untouched, so if the shade is set to subtract 5 from the underlying color, it will subtract 5 even if contrast is set to 2.0, not 10.

3 Likes

I meant the hex color value of the image in GIMP. Did you choose the value that was previously on the sides?

I am unfamiliar with this syntax.

The non reflective area was left untouched if you meant that, the inner area, the reflective one, is roughly the same as it was on the bottom.

edit: 116/256 means 116 in a scale from 1 to 256, almost half gray.

Screenshot_20241016_165636

1 Like

Beautiful work! Can this be also used to workaround the glcore flipping issue?

Edit: unfortunately the new solution did not work with pacman:

While it worked fine with 1943, as each game rotates differently (90° vs 270°).