Ok, thanks for the explanation.
Let’s hope the new uniform in the next retroarch release will help solving those issues so that shader authors can finally provide shaders that work everywhere.
After doing a bit of testing it seems that the NTSC rotation issue appears to be fixed in the current version of Mega Bezel. Strangely though, the results I’m getting from rotation don’t seem to be consistent between FBA and Flycast. I don’t know if there’s something weird going on in the background, but I was able to get satisfactory results using the Flycast core’s vertical rotation option + adjusting rotation values in the shader; in FBA it looked awful with everything I tried so I’m not sure what’s going on there. I guess the good news is that MAME should essentially cover any relevant games that would be pertinent to FBA, Flycast (Naomi) is the one that has unique content and the results there were pretty good.
Unfortunately, and I suppose expectedly, all the presets across the board do not look identical when going from the 2022-11-22 release of Mega Bezel to the current one. Namely the shadow mask and deconvergence looks quite a bit different. I’ve mostly nailed down the relevant values to get pretty similar results to the previous version but more testing is required.
1 Like
Hmmmm that’s weird, iirc i implemented the libretro rotation in Flycast (and Kronos), and it should not be that much different from my code in FBNeo.
I was using the “Final Burn Alpha” core, not FBNeo. Maybe that’s the problem, I’ll try Neo.
EDIT: Yeah, no that didn’t fix it. The main issue is that the fake scanlines look completely hideous in FBA/FBNeo when using rotation. I was testing with Varth. Their scaling just seems completely wrong. They’re fine in Flycast though.
I don’t know that this is necessarily a problem with the cores/Retroarch itself. It might just be something odd happening in Mega Bezel. Again though, this isn’t exactly a huge concern personally since the same games can be played with the MAME core and they look fine there (with the existing presets + internal rotation core option).
1 Like
Just for reference:
MAME: Core Rotation: Internal / Shader Rotation: Off
FBNeo: Core Rotation: On / Shader Rotation: On
Flycast: Core Rotation: On / Shader Rotation: On
1 Like
I’m wondering if the difference between Flycast and FBNeo could be somehow related to CPS-1’s unusual resolution (384x224). Does the same happen with a more classic resolution ? Like donpachi or espgal2 (320x240) ?
Hmm, I think you may be onto something there. I tested out donpachi in FBNeo with core rotation on and rotated in the shader parameters and it looked just fine.
Ok, so basically there is a problem when the resolution ratio is not 4:3.
Edit: also, looking at the flycast screenshot again, the scanlines look wrong to me, they should be vertical instead of horizontal.
Edit2: actually, isn’t there exactly the same problem with the MAME screenshot ? some reminder
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.
1 Like
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
1 Like
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:
code example
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!
1 Like
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.
2 Likes
I’m aware, yes. It’s just an aesthetic preference.
That seems to be the case, yes.