Yeah the original limit was 128
I was originally concerned there would be some technical problem with it, but there doesn’t seem to be.
I created a shader with the max number of parameters, textures, & passes, as a test, 64 passes, 16 textures and 1024 params. 
It still loads so I guess we’re all good 
@HyperspaceMadness My shaders are under my Retroarch folder.
Retroarch for linux is distributed ad an AppImage container. It’s a sort of self contained package, which needs no installation and can pratically be run anywhere. This kind of containers are a lot en vogue lately, there are many different implementations of the principle, the most famous is Docker.
Anyway, I’m not an expert, but I think it sorts of creates a private sandbox when is run, complete of home and config folders.
I have unpacked the AppImage distribution under:
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/
There you can find it’s “private home” folder:
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/
which already contains Retroarch’s .config folder with all subfolders (core, assets, overlays, shaders…) out of the box.
I, following the readme, added all the Mega bezel stuff under:
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel
As you can see in the logs. As I said, “regular” Mega Bezel presets work for me.
The issue, I think, is that when run the AppImage system creates some temporary stuff like:
/tmp/.mount_RetroAO1uKPv/usr/bin/shaders/shaders_slang/bezel/Mega_Bezel/Presets/Base_CRT_Presets/MBZ__3__BASIC-REFLECT__GDV.slangp
And that’s outside my control, I fear.
So, yes, the solution seems to be to go to relative paths, but I think it’s should ALWAYS be like this from the start, or we will run with similar issues in the future as these container systems are getting more and more popular, also in Windows.
Personally I don’t think this is elegant. 
I think the need for change is on that end. Fine control is the hallmark of Linux, shouldn’t there be some way to define a mount path for the tmp folder? Letting the AppImage make the decision is counter productive.
The reasons we use the :/ syntax outweigh the relatively low instance of it being an issue. (IMHO but @HyperspaceMadness is the boss. 
)
@Duimon is correct, at least for the moment the path we’ve decided to go down is to have all the base presets be relative, then have all others which look at them be absolute (relative to the retroarch folder with :/) for example the examples or variations.
The reason for this is so that in what seems to be the average case the user can copy these presets anywhere and they still work. So they can copy one they like then adjust it how they see fit.
Although we can always reevaluate depending on how people are actually using these things.
And I might need to change at least what goes into the libretro repo such that it is guaranteed to work with relative paths. Variations will probably go into the repo, but The “Examples” will definitely not go into the repo since its too big!
Edit: I really feel like what we need here is to add a retroarch feature so that there is a path ID (E.G. “[shaders]/” something like that) which will point to the root of the shaders folder wherever it is, since it can be changed. I’ll talk to some people about this. I would hope it could work in the appimage context
This is the way the official RetroArch appimage build you can download from the Retroarch side works.
As I said, I’m not a regular user of AppImage or Docker or other containers, but I don’t think either me or you can do anything about this.
Maybe the Retroarch develop team, and I underscore “maybe”, can say more about this.
If that’s the way contained apps, which are more and more becoming used, work then the problem will surface again, even in Windows if the team decides to move to Docker or similar systems.
In any case the fact is that the Examples, and any other shader preset that makes use of that “:/” syntax is incompatible with the official Linux version of Retroarch, unless you manually edit the files themselves.
Talking with the Retroarch dev team sure could help.
I don’t know a think about how this “:/” shader language syntax works, but it seems to find and expand a sort of global variable, only it’s not what we expect in the environment of an AppImage installation.
Maybe it’s a bug, or there’s a workaround.
BTW: I tried correcting the path to relative as you suggested and it works great. 
I’m not sure this is true. It does make it impossible to store the shader folder outside of the RetroArch path, but it is internal to RA so not incompatible.
It does seem to be incompatible with AppImages though.
I think this solution would work. You could have the shaders folder anywhere and the AppImage would just ignore anything it it’s own path. I’m not sure how the AppImage handles permanent configs if it generates tmp stuff. Where is the config folder? How does it manage settings?
Yeah “:/” returns the root of the retroarch folder, I did the latest coding in the shaders for this portion.
Yeah no clue, it’s quite weird that it seems almost as if the file preset file is requested by retroarch (which is how it found it in the first place in
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel
Then it creates some temp place and loads it from there, I really don’t know what it’s doing…
Maybe the knowledgeable @hunterk knows?
Pretty sure it’s related to the portable home directory, which is doing a weird transparent redirect behind the scenes to work its magic. I don’t think there’s anything we can do about that, but I also don’t know if it’s worth fretting over.
I think that’s the way that app containers work.
Every application is started in it’s own private sandbox. Think of it, with all due differences that are not worth discussing here, like a poor man’s virtual machine.
The application is run in a private environment. The “home” directory that’s provided with the packaged app is mounted to a “random” place and becomes the real home directory for the process.
To answer @Duimon’s questions, the config folder of Retroarch is located under the application “portable home”, in my case
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home
Under here i have /.config/retroarch with all the subfolders commonly associated with retroarch. And that’s where I put all Mega_Bezel stuff.
Then AppImage when run, as @hunterk said, does it’s magic, it temporarily mounts its stuff and everything works fine.
Except for that “:/” syntax expansion.
BTW, when AppImage Retroarch is running, if I go to Settings -> Directory, I can see all parameters, including “Video Shaders”, pointing to the real paths where the files are, for example:
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch/shaders
It seems it’s only the peculiar “:/” syntax of the shader language to expand the “wrong” value in this case.
Or, to explain it maybe ina n easier way:
When the AppImage application is run, it “automagically” and temporarily installs itself in a random path like /tmp/.mount_RetroAO1uKPv
The Retroarch executables are copied under /tmp/.mount_RetroAO1uKPv/usr/bin, and THIS is the “Retroarch” folder.
The “home” folder, though, stays the one where you downloaded the package app, in this case
/home/tarrasque/Downloads/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home
So, the shaders, in this architecture, will NEVER be under “the root of the retroarch folder” as @HyperspaceMadness requires.
“:/” gives you back /tmp/.mount_RetroAO1uKPv/usr/bin, wich is correct, in a sort of way, but does not work in our case.
the path we’ve decided to go down is to have all the base presets be relative, then have all others which look at them be absolute (relative to the retroarch folder with :/) for example the examples or variations.
The reason for this is so that in what seems to be the average case the user can copy these presets anywhere and they still work. So they can copy one they like then adjust it how they see fit.
On a side note, doesn’t this cause a problem for everyone that puts the shader folder OUTSIDE the retroarch folder?
Directories are configurable so, everyone id free to do it.
Now that I think about it, on some Android devices, like my NVidia Shield, I was forced to do it, because the system folders, where the app is installed, are not user writable, so I had to configure every directory that I wanted to manage (roms, of course, but also overlays, screenshots, playlists, shaders…) to an USB attached drive in order to do it.
Edit: I really feel like what we need here is to add a retroarch feature so that there is a path ID (E.G. “[shaders]/” something like that) which will point to the root of the shaders folder wherever it is, since it can be changed. I’ll talk to some people about this. I would hope it could work in the appimage context
Couldn’t you just query Retroarch’s Video Shaders directory config parameter?
Yes it does which is why I suggest adding syntax in the preset paths so the shader folder can be used directly.
Yeah I’ve run into this, it’s a real pain.
Yup, that’s the direction I was thinking, sounds simple, so I hope it is, you never know until you get into the weeds
Well, Retroarch is so insanely configurable that makes no sense not to try to leverage it.
I have two questions/issues, both of them are absolutely defeating me…
The version of MegaBezel I previously used was 2020-04-19 & RA 1.9.0. I have now upgraded to MegaBezel 0.9.21 & RA 1.9.7 with a fresh install.
I want to use the vignette, however for the vignette to be enabled, grade also has to be enabled. BUT… when I turn grade on, it instantly changes the colors of the screen. How do I stop this behavior as I only want the vignette and not the overall color to change?
I have enabled the static reflection image (the tube glass at top of the screen) but it has serious banding issues. I tried changing the reference to the 16 bit version of the tube glass but it makes no difference. The tube glass appeared allllmost perfectly smooth on my previous install.
Can provide screenshots if needed, I still have my previous install to compare to as I’m trying to achieve parity with the new version
It is pretty tough to get an exact match, but then I’m not sure how accurate the colors in the old version were, compared to reality.
You can come close by simply adjusting the gamma in the grade settings. Then skip down to the Guest settings and play with color profiles and LUTs.
With enough tinkering i think you may find something you like more than the old.
About the reflection, I thought there was a dithering parameter like in the night mode. Apparently I was wrong. @HyperspaceMadness?
I found “[NIGHT LIGHTING] Dithering Noise Samples (Reduces Banding)” but it doesn’t seem to have any effect on the static tube glass image
So if you change the following:
CRT Electron Gun Gamma : 2.2 Signal Type : 0 CRT Phosphor Gamut : -1 Display Color Space : -1 White Point : 6600
If you place the following in your preset it will give you the above
g_gamma_out = 2.22 g_signal_type = 0 g_crtgamut = -1 g_space_out = -1 wp_temperature = 6600
This seems to get somewhere close to the unadjusted color
You may want to try out the Grade defaults though, they fix a lot of the really strong yellows which shouldn’t really be yellow and purples which should be blues which you see in of a lot of games with the raw color.
Just to give an example of the default color correction in grade: Without Grade
With Grade
As you can see some of the purples get shifted toward blue and the really strong yellow is reduced, and the gamma creates a greater contrast which ends giving the image more depth.
But of course you should play however looks good to you 
.
Hmm, I’m not sure why it looked better on the previous install, I had been getting complaints about banding on the highlight image all the way along.
There was a dithering sampling I did for this highlight image but it’s currently hidden and off by default, I can take a look at bringing it back. The parameter you found is really just for the night lighting.
Edit:
I would definitely not recommend using the 16bit reflection image as it causes a big slowdown on load… And in my testing never gave any better result with the banding issue.
Did anyone find an easy way to remove the scanlines? I’m using the MBZ 1 preset and I tried playing around with the beam shape of Dr. Venom but it doesn’t look like I can make the scanlines themselves disppear without messing up the image altogether. Don’t get me wrong, they look really good, but they don’t jive so well with video recording so I’d like to be able to turn them on and off when necessary.
