I use an early version of @hgoda90’s bezel color converter. (Now a preset editor.) I had created a python script that took a hex value input but abandoned it.
The current preset editor should work just fine.
3 Likes
The latest koko-aio update is now merged into main RetroArch.
I’m excited for your upcoming update.
1 Like
That is good news. I have some work to finish, then some testing… it should happen fairly soon. 
1 Like
Wrong thread I think. 
Oh lol
This is my own fault for trying to multitask. My time has been totally overtaken by schoolwork lately, and the one time I decide to post something on here… I done goofed.
2 Likes
Hi everyone, I wanted to report this resizing problem. I use a POCO M4 Pro smartphone. Of course everything is updated to the latest available version and I have set the resizing aspect to “full”, I also use the Vulkan libraries. I attach some example images with the first one only with Kokoaio and the other two (where you can see the problem) with duimon-kokoaio:
1 Like
What is it that you expect exactly? koko-aio doesn’t adapt to screen aspects like the Mega Bezel.
I have plans for a 21:9 pack but other aspects are probably off the table.
3 Likes
Ok thanks, I had the chance to try your package only on smartphone and not on Computer, since on Smartphone I can only use koko-aio. So in this scenario it’s normal, I understand. Thanks for the answer.
1 Like
It seems LRS2 is finally out of Alpha:
This requires some file renaming for the glcore flip params.
2 Likes
Is the next update coming soon? just checking to see if I should manually fix the broken parameters from the older koko-aio versions, or wait.
1 Like
If you are talking about the auto flip wildcards… they all use the $CORE$ wildcard… which is broken ATM.
I fully plan on updating anyway but it has been so long that I will need to do a deep dive into koko-aio to at least add new base presets. (I will assume that the wildcard will be fixed at some point so leave that as is and add a new LRPS2 entry to the list.)
I have been waiting for my new glasses to arrive, which they have.
We’ll see what I can find time for in the very near future.
3 Likes
So… I started digging into this and it turns out I left it in a very incomplete state. I think I had some questions that have since been answered. (About updates that were recent at the time.)
There are a lot of wildcard references that may not be required so I need to dig into my presets a bit to clean things up.
Rest assured that I am in elbow deep now and will stay there until I get this thing updated. 
4 Likes
Thank you for your hard work!
4 Likes
So… I think I am stuck. 
I just tested the nightly and the $CORE$ wildcard bug is still there.
Changes koko made will let me eliminate flipped versions of my bezels (Since the shader handles the bezel color variations now.)
The problem is that I have no way of testing my wildcards to verify that the shader handles the bezel correctly. (Or if I need to add some parameters to handle it.)
The user can fix the flipping and save a new preset. It’s inconvenient but not out of the ordinary. (That’s the way things were before wildcards.) I just don’t want them to also have to tweak the bezel.
Going in and blindly removing seemingly unnecessary bezel graphics and parameters seems like a bad move at this point.
My only hope is that @HyperspaceMadness, or the dev who performed the wildcard “cleanup” can fix it sooner than later.
3 Likes
I wasn’t able to reproduce any issues on my end (linux 64-bit) so was unable to bisect effectively, unfortunately. All of the test presets loaded correctly for me. 
So, it may be something specific to Windows…? In any event, it will need to be bisected by someone who can reproduce it.
2 Likes
In my personal pack tests, I found that koko-aio now handles all rotation instances (90 vs 270 vs 180), by taking care of bg, spot, and bezel shade (side_shade-helper.png) accordingly. However, it DOES NOT handle the infamous glcore flipping issue, everything remains flipped upside-down, so Wildcards are still needed in this case.
I feel I’m misunderstanding your comment though.
1 Like
When the color variations on the bezel (Darker at the top, lighter at the bottom, etc.) were static… I had to create custom bezels that were shaded correctly for the rotation.
Now I don’t need them.
When you say “Personal Pack” are you referring to my pack that you are using?
I’ll dig a little deeper into my presets. The flipping wildcards “should” be the only place I am using the $CORE$ variable. If this is indeed the case, I can move forward and just ignore the flipping errors for now.
I am insecure about this only because the solution to the bug may not directly mirror the old behavior.
1 Like
No no, I meant the packs on my GitHub.
If the new bundled side_shade-helper.png is working fine with your custom bezels under normal rotation conditions (not related to glcore flipping), and if it’s correctly shading the bezel sides, even with 90/270 degree rotated games; then all you’ll need to do for the glcore flip issue is to remove the old flipped custom bezels, and instead reference the extra bundled side_shade-helper-flip-y.png.
This worked great for me in the previous RA version when $CORE$ was not broken. I thank @kokoko3k for including that file by default.
But maybe you already know all of this, and have some exceptions, so I will just wish you good luck.
EDIT:
Oh there’s one instance, specifically with flipped + rotated games (like Ikaruga with Flycast on glcore), where I had to NOT use the side_shade-helper-flip-y.png and instead use the normal side_shade-helper.png .
The flipped side shade helper should only be used with CORE-REQ-ROT-0 and not with CORE-REQ-ROT-90 which should just use the default.
1 Like
I’m not at all familiar with the helper png. I’ll have take a look and see how well it works with my custom bezels.
In the very least there will have to be some editing to my references to include it.
1 Like