Lacking support for RetroArch platforms without hardware rotation

[vaguerant]

The FBNeo libretro core simply assumes all platforms are able to use the RetroArch frontend's hardware rotation feature to correctly orient screens, but some platforms don't have rotation, or else they do have it but it doesn't work correctly, in which case rotation can be disabled in the frontend (Settings > Core > Allow Rotation OFF). In FBNeo, this means games just display un-rotated, e.g. sideways Donkey Kong (dkong) and Pac-Man (pacman), upside-down Wily Tower (wilytowr), etc.

This is something that's been discussed extensively at libretro/mame2003-plus-libretro#1202, another core that makes heavy use of rotation.

Another core with handling for internal rotation is beetle-wswan: https://github.com/libretro/beetle-wswan-libretro/blob/9355f252d7d9c58bb6bec4fb209c9636b0a0fa37/libretro.c#L878

Both of these cores check whether frontend rotation is available. If not, they do their rotation internally before passing the image off to the frontend. To the end-user, this means that rotation just invisibly works regardless of whether the platform they are using has hardware rotation.

The ideal situation would be for all platforms to have working frontend rotation, but that currently hasn't been achieved, so falling back on in-core rotation is necessary in some cases. It would be nice to have in FBNeo for use with rotated games on those platforms, as currently only standard horizontal games are playable.

[barbudreadmon]

If retroarch wants to implement software rotation as a workaround when hardware rotation is unavailable, they can but that MUST remain a frontend feature. One of the main reasons rotation core-side is such a bad idea and should be avoided at all cost is explained at https://github.com/libretro/mame/issues/261.

[vaguerant]

I think software implementations are already the case for some platforms, it's often referred to as "hardware" rotation, with scare quotes, which I suspect means frontend rotation is variously achieved via whatever method happens to be set up in RetroArch for that platform; hardware or software.

I do think in-core rotation offers a decent compromise solution until somebody correctly hooks up frontend "hardware" rotation--in the scheme of things, "1942 has its scanlines in the wrong direction" is a better problem than "1942 is sideways and unplayable."

The other thing to note is that there are likely relatively few platforms which don't support rotation but do support shaders. Basically any platform with a mature RetroArch port supports both, and a less mature port is more likely to get rotation support before it gets shaders, so the use of shaders combined with in-core rotation is likely rare in practice.

But ultimately, I do understand this is a frontend issue, not a core one. Those cores which do offer in-core rotation are providing an (incomplete) backend fix for a frontend problem. If the FBNeo team doesn't want that sort of thing in the core then that's fair. I'll go ahead and close this issue.

[barbudreadmon]

Even if the shader issue is secondary for those platforms, it still doesn't make sense at all to implement that software rotation in multiple cores instead of implementing it once for every cores in the frontend.

I understand implementing this here would be a decent compromise for you, but i'm really not fond of workarounds that don't make any sense, especially one that would break other features, like the ability to prevent rotation through retroarch settings : retroarch will answer to the core all the same whether the rotation failed because it is not supported or because the user disabled that feature.