So the parameters ultimately seem to go all the way back to the file koko-aio-ng.slangp That’s where the path to the background_under.png is actually defined. I’m unclear how to change this image depending on the game when the path goes through this whole daisy chain of references all the way to that slang file, and changing it at that level will just propagate it through the whole chain of files that reference back to it. I looked at the wildcard documentation and I’m still unclear how I would apply that to this.
You just need to override the parameter in the last piece of the chain (the last preset), then set that preset as a core/game override.
Works exactly the same as other parameters, the next override previous.
So I could basically just cut and paste this line of text in the final shader file, but with whatever relevant image file I want? I’ll give that a try right now
bg_under = “textures/background_under.png”
Well I’m doing something wrong because when I try that it just fails to load the shader.
I added the extra lines at the bottom here to use the different background image, is this not how I would do it?
LICENSE https://creativecommons.org/licenses/by-nc-nd/4.0/deed
// Released with permission from original author - https://github.com/Duimon
// ----------------------------------------------------------------------------------------------------------------
#reference “…/…/Presets-ng/Monitor-Ambilight-immersive.slangp”
bg_over = "../textures/logo_Playstation.png"
bg_over_linear = “true” bg_over_wrap_mode = “clamp_to_border”
bg_under = "textures/background_under2.png"I looked up wildcards and after reading the documentation I don’t get what I would actually do. I’m not a coder unfortunately.
1 Like
No worries. If you manage to get one of your console graphics to work like you want (By adding a line to a saved preset.) you could use a wildcard to automatically select a different graphic based on the “Core” or “Content Directory”. (Much like saving a “Core” or “Content Directory” preset.)
The idea is that a single preset would be used instead of multiple.
(e.g. bg_under = “/my_content_dir_images/$CONTENT-DIR$.png”) Where your image names would match your content directory. (e.g. Playstation.png, N64.png, etc.)
Forget wildcards for a while; they are handy but a bit too complex since you seem to lack the basics and being on a phone makes things harder too, so follow the easiest/simplest route:
Name your new image file great_background.png
Place it in the same directory as the other ones used by koko-aio, i mean in the same directory containing background_under.png and background_over.png
Make a copy of a koko-aio preset you like from presets-4.1 or presets-ng directory, and rename it as great_preset.slangp
put great_preset.slangp in the same directory as the preset you copied it from.
Open the preset great_preset.slangp with a text editor and add the lines:
bg_under = "../textures/great_background.png"
bg_over = "../textures/great_background.png"
Save preset.
Explaination: the path can be ideally splitted as:
../
textures/
great_background.png
the path starts with
../
…it tells the shader to start to look for textures one directory up relative to the preset file, then continue as “textures/” which means descend into the folder named textures, and finally search for “great_background.png” in that folder.
Once you mastered that and the preset loads fine, then you can use retroarch menu to bind it to a core.
Hope this helps.
2 Likes
These shaders are outstanding and they are the only way to play for me, on my old laptop.
I would like to get a raspberry pi 4 though, and I would love to know if these masterpieces would be lightweight enough to run on that device. I googled quite a lot to no avail, so here I am asking.
Thanks anyone,
Why Raspberry when you can use a low-cost Mini PC?
Thanks, I don’t own any Pi4, but I’m curious too. You could try to find a gpu benchmark result done on pi4 and run the same bench on your laptop to have a (very) brief idea on what to expect.
1 Like
Ultimately, I’m in the mood of playing C64 games.
Since several of them are not full screen, ambient light cannot work as expected, simply because it relies on what color the external border is.
You could use core options to make the emulator (vice in my case) auto crop the void zones, but you may prefer to retain them to have a more authentic look as well.
Till now, the harcoded default was set to 0.07, which means 7% from the external border, and would produce this:
So there is another parameter now:
Internalness (Sampling point) sets where the leds should take their color from.
(where Internalness (Led position) means where the virtual led strip is positioned)
By setting it from the previously hardcoded 0.07 to 0.30, things gets better for c64 games (maybe 0.30 is a bit too much, but you get the idea):
4 Likes
Fanless, portable, can be hooked to a real CRT when that’s available. 
I think this is a non go, on my mali g76-mp12 gpu (android phone) I can reach 1080p at 60fps with some slowdowns here and there, but see the comparison:
https://www.cpu-monkey.com/en/compare_cpu-raspberry_pi_5_b_broadcom_bcm2712-vs-samsung_exynos_9825
1 Like
@kokoko3k after some time i’m messing around with Xbox Series S Retroarch, installed latest 1.17 version, updated shaders, changed the config-static.inc file but koko presets are still not loading for me. Is there something else i can do here?
- So, they never worked?
- Have you tried to switch between d3d11 and d3d12?
Thet’s weird, because I’ve had a different report, at least for a not so much older version.
Please try that, it is from december 4, a bit before 1.9-NG version.
Usual workaround is needed to try to run in on d3d.
If it does not, then i’m clueless, because that is the version said to be working.
If it does, then we can go on and bisect where the new breakage happened; if you have a github account, then we can continue on the afrolinked issue report.
Also, it would be advisable for xbox users to stay in sync with the development repo rather than the “stable” one via retroarch updates, or cherrypicking the offending commit becomes harder.
I just reopened the bug report on github, feel free to post there, providing full logs please!
Actually, I haven’t tested it further after my initial report that it wasn’t working. I kind of put the Xbox emulation on the back burner.
I will test it now and report
1 Like
I noticed that in the ambilight immersive presets under the Duimon_dditional_presets, they all include the following lines:
#AMBI_FALLOFF = “0.150000” #AMBI_POWER = “0.000000” #AMBI_INT_OFFSET = “-0.000000” #AMBI_STEPS = “20.0” #AMBI_GAMMA = "0.5
However this does not appear to be in the actual shader parameters. Is this as it should be?
Yes, the # prefix means the line is commented, so it does nothing.
However those parameters are defined up in the presets chain, see the first line, where it references another preset (the #reference line is an exception, the # prefix before the reference keyword does not comment the line)
Oh interesting, would there be a reason those lines are in there at all? Are they just suggested alternate parameters?