It’s set to horizontal manually in the preset, intentionally. I just prefer the way that looks. That said, they don’t look the same in MAME as they do in FBNeo. The direction is not the problem. I want them horizontal. But in one case they look as expected and in one case they do not.
We’re getting into the weeds here y’all. The MAME screenshot looks the way I want it to / expect it to look. The FBNeo one doesn’t, with the same values between them other than rotation.
Doing some more testing, using the MAME core for Varth but performing the rotation via the TATE core option + rotation in the preset yields the same result as in FBNeo, so the cores are not the culprit. Doing it in MAME via core rotation: internal + no rotation in the shader looks as expected. It’s when doing it via manually defining the rotation in the core + preset that it looks wrong. That said, that same process isn’t causing an issue in Flycast. Nor is it causing an issue in FBNeo itself with certain content (like Donpachi). So I have to assume that the difference in content resolution is what’s causing the problem.
For added context in an attempt to convey what it is that I’m pointing out, this is what I want it to look like:
The scanlines and mask look consistent here from top to bottom. The only change between that screenshot and the one below is how rotation is performed. In the one that looks as intended it’s done via Rotation: Internal + no rotation in the prest.
When I perform the rotation in the core options + preset, however, I get this:
As you can hopefully see, this does not look the same. The scanlines + mask look, well, odd / wrong.
As I said before, I am not claiming that this is the result of the cores or Retroarch itself, but rather some combination between them and Mega Bezel and the way in which rotation is handled. That said, performing rotation via core option + preset yields the expected results in Flycast (and in FBNeo with certain content like Donpachi) so my suspicion is that the content resolution is the source of… whatever is happening here.
If the end result here is that I simply need to make a disclaimer of “Hey, if you want to use the vertical presets for CPS1, make sure you’re using MAME to do it and have rotation set to internal in the core options” that’s fine by me.
Hmmm ok, but you do understand that’s not how those scanlines look on the real cabinets ?
Actually, i pointed that out for a reason. I remember seeing a similar issue some years ago (a shader with incorrectly oriented scanlines looking like crap on a vertical game). I’m wondering how they would look if you didn’t set them horizontal manually.
Edit: actually, i suppose @Duimon already answered that question, so i suppose it’s an issue specific to games with a non 4:3 resolution when using frontend rotation and enforcing horizontal scanlines
@kokoko3k @HyperspaceMadness on a sidenote, it seems RA 1.16 was finally released yesterday, i hope the new uniform will help making adjustments to solve that kind of issue.
Great, but i’ll take the safe path and wait a bit more to be sure most of users will upgrade (using the new uniform on old retroarch would make the shader fails to compile)
Oh, there is no way to detect and fallback to something else when the uniform doesn’t exist ? That’s quite a problem then, since some users almost never upgrade. In the long term it might be safer to just keep the old version as an alternative and warn the users that they should use that alternative if they are still using a pre-1.16 version of RA
Not that i know of.
@hunterk maybe? But I think we already had a talk about it.
I’ll just wait at least for major Linux distros to pick 1.16 btw.
Does it fail to compile or just stay undefined? If the latter, I guess you could make a check for it, but that could also make a mess of your code.
I’d happily made my code a little messy for a while, but I guess it fails to link:
layout(push_constant) uniform Push {
float idontexist;
} params;
[..]
float tobeornottobe = params.idontexist;
[..]
[ERROR] [slang]: Unknown semantic found.
[ERROR] [slang]: Failed to reflect SPIR-V. Resource usage is inconsistent with expectations.
I even checked supported compiler preprocessor but came up empty of anything useful.
We’d need something like #ifnotuniform
@Zombeaver: sorry for hijacking your thread!
Maybe we could add #define statements in RetroArch alongside any spec extensions, such that we could do:
layout(push_constant) uniform Push {
#ifdef HAVE_ROTATION
float idontexist;
#endif
} params;
[..]
#ifdef HAVE_ROTATION
float tobeornottobe = params.idontexist;
#else
const float tobeornottobe = 1.0;
#endif
[..]
That would be good for maintaining compatibility with downstream projects, as well.
I’m aware, yes. It’s just an aesthetic preference.
That seems to be the case, yes.
Sorry to continue this old thread, but I’m not the savvy with this.
I’ve been using this pack for a while, but recently I updated the assets and shaders with retroarch and it messed it up. It now has this weird white glow around the letters and everything, I don’t know if I can fix this in the shader’s parameters or I have to do something about the updated assets.
Hi, “SirCharlesV”. 
You might be able to fix this problem by re-downloading a previous version of the emulator that was released around the same time as this shader, 6-11-2023.
Version 1.15 fits the bill: windows - buildbot.libretro.com > stable > 1.15.0 > windows (you can navigate to another version).
Alternatively, see if replacing the current shader folder with v1.15’s shader folder resolves the issue.
The folder is usually here, \RetroArch-Win64\shaders\shaders_slang
My suggestion is not to update the emulator unless there is a new feature or shader that you want to try out – cores are OK to update, though. I hope this is useful.
That fixed it. Thanks!
“My suggestion is not to update the emulator unless there is a new feature or shader that you want to try out – cores are OK to update, though. I hope this is useful.”
Yep, lesson learned!
Best thing is to revert to the version of Mega Bezel Reflection Shader you were using before you updated, or just stick with the version that @Zombeaver used when designing the Preset Pack. Next time backup before updating.
love these shaders!
The triple screen works perfectly 
However, using the double screen, it seems
like it’s too stretched. In fact, it seems very much like the triple screen.
Is anyone able to assist?
Trev
the strange thing is, the double screen (exactly the same shader presets) work fine for arescue.zip (mame). Seems like it’s a problem when turning it on for cyberbal.zip
What core does cyberbal.zip use? (Since you don’t mention mame after it.)
sorry, mame (current), so the 0.277 core on retroarch.
I am thinking there is a file somewhere in the pack which references the game title (no-intro) and instructs which Zomb’s Mega Bezel screen (single, double or triple) to load the rom in, maybe?
There is no such thing as a (no-intro) MAME romset. 
He probably has the aspect ratio hard defined. You could try setting it to PAR in the shader parameters, and save a game preset if it looks correct.
