I’m rather confused by the rotation results I’m seeing here.
What is the supposed correct way of rotating so that there is no mismatch between gui and video direction with MAME and FBNeo and shaders are correctly displayed?
EDIT (9/18/2021): actually the guy I’m referring to below is NOT the programmer (@BarbuDreadMon) , it was some other guy commenting on Github. Anyway, the issue is apparently with Retroarch and not FBNeo itself. 
original post:
FBNeo does rotation wrong and I made an issue on GitHub like 2 years ago, lol. The programmer couldn’t understand why you would want vertical games to remain un-rotated and he eventually just insulted me 
.
We have too many ways to rotate things and we need just one way, which is already in the video options in RA. Automatically rotating stuff causes all kinds of headaches. The core should not be altering the image in any way, that should all be done in the frontend and not under the hood. Just my opinion.
MAME gets it right, it displays vertical games unrotated and the user rotates the image by using the rotate option in RA.
I’ve seen a lot of people mentioning this over the past year or so, but good luck getting FBNeo fixed. Maybe if enough people post the same issue on GitHub the programmer will reconsider his position.
1 Like
In MAME, first image is rotated by internal MAME menu, (screen was rotated by me Irfanview afterwards), the second one is rotated by RA screen rotation.
Isn’t the first one correct ?
1 Like
first one is correct
1 Like
Yes, it looks there is some consistency in the sense that you can get a correct emulation image if using the core options and rotating the display, but RA rotation options mess things up and it’s not possible to make the gui behave accordingly.
btw, what shader is that? Looking for something that works for vertical games, guest-dr-venom is good but the scanlines get wonky when you alter the vertical scale, for some reason.
1 Like
I always use crt-hyllian for TATE, but crt-geom’s TATE mode is pretty good these, too, IIRC
1 Like
That’s TV-Out Interlacing, it makes things very obvious by default when something is wrong with scaling, that and the parameters are useful for some quick testing. Part of why I was just looking into vertical content again now was also that I’m planning to use a 480p EDTV (easily rotable), but as you can probably imagine, not a lot of shaders are usable with that 
1 Like
The FBNeo approach has a nice benefit, that allows many crt shaders to display vertical scanlines by default. The drawback is a loss of mask accuracy with HW rotation after the shaders are applied. But’s it’s not this of a great deal.
1 Like
FB Neo’s rotation also doesn’t work in the d3d10-12 drivers, since it relies on set_viewport, which hasn’t been implemented in them yet: https://github.com/libretro/RetroArch/issues/7660
2 Likes
Hi, this is an old thread, but I had a conversation on Discord with the developer where I managed to fully understand what is going on under the hood.
So basically the FBNeo core is doing the correct thing with respect to outputting to retroarch. It outputs the image sideways (the original orientation from the arcade hardware’s perspective) And then sets the Retroarch variable to tell Retroarch the rotation needed to get in the orientation the user wants to see. Retroarch is the one which rotates the shader coordinate space.
Mame in the other hand pre-rotates the image before it gets to Retroarch, then tells retroarch that there is no rotation to do.
For some shaders this rotation works fine, and some don’t, I think the ones which don’t are related to using glfragcoord instead of using vTexCoord * global.FinalViewportSize.xy basically using glfragcoord should be avoided because it is sometimes unreliable. For some other shaders like border shaders and the Mega Bezel which coordinate refers to the top of the screen is important and the graphics will show up rotated which is bad.
We also talked about having this rotation value get passed to the shader system so in the shader you would know if you are dealing with rotated coordinates or not.
I think the real solution to this problem is to add an option in the shaders menu which would allow you to choose if you want a rotated coordinate space or not for the shader. If you choose to have an unrotated space then the image would get pre-rotates at the entry to the shader pipeline and the coordinates system would be left unrotated.
Anyway I just wanted to share my thoughts and understanding of this issue
3 Likes
Honestly alot of stuff in RetroArch sounds like it needs refactoring and rewrites, to just get stuff more inline with itself.
But this is what happens when you have a community driven project that’s been going on for years. (Not giving anyone flack, RA and all the work that has been done on it is amazing!)
I’m just saying some more thought should be given to the custodial side of things.
2 Likes
The issue here isn’t so much RA consistency as core consistency, but cores will never all be consistent because they’re made by different people with different ideas of what’s best for their own usecase.
MAME-current, for example, has the top priority of not interfering with the internal workings of the MAME codebase so it’s easier to update. FBNeo, in contrast, is a deep port with a lot of care taken to make the experience better with libretro.
So, if you have inconsistency among cores, you either add an option to a core to make it behave like other cores or you add an option in RetroArch to work around the inconsistency. I don’t love adding more niche options that are just another thing for people to fiddle with unnecessarily (and subsequently request support to unfuck), but it’s also not fair to ask core authors to change how their stuff functions just because someone else does it differently. (see: different retropad mappings in Genesis/MD and Saturn cores)
4 Likes
Fair fair.
Completely valid stuff I didn’t think of.
2 Likes
No, FBNeo is doing the rotation properly, meaning it asks the frontend to rotate the display through the libretro api. It always did. However RetroArch wasn’t handling rotated shaders well in the past, but it was fixed by https://github.com/libretro/RetroArch/pull/11942 for glcore/vulkan video drivers, and https://github.com/libretro/RetroArch/pull/9734 for gl video driver (i suppose it might still be broken for direct3d).
I’m the only FBNeo programmer browsing this forum and i never insulted you, i think you are talking about grant2258, who was never a FBNeo programmer.
And that’s exactly what FBNeo is doing, actually all arcade cores are doing this except MAME & MAME2016.
Wrong again… See https://github.com/libretro/mame/issues/261, the first screenshot is from MAME, the second is from FBNeo.
There is nothing to fix, it’s already handling rotation properly. Whatever issue you might experience would be a wrongly coded shader, or maybe a very outdated RetroArch
Please stop spreading lies.
Indeed, usage of gl_FragCoord is supposed to be forbidden in libretro shaders, here is an example on how to fix those wrongly coded shaders : https://github.com/libretro/glsl-shaders/commit/6b345091aecbbb0ec599ec9692a88ba53ce31922
1 Like
Well shit, guess I better read because I think I was using gl_FragCoord 
It’s saying 320 for height and 240 for width, how is that correct? Vertical games via CRT do not swap height/width. It’s always 240 scanlines.
I don’t understand why this is so difficult.
edit, to get it to display properly, vertical mode has to be enabled. I don’t understand why this is the case, though. If the game isn’t being automatically rotated then why is vertical mode necessary?
FBNeo is doing this by the book, that’s a RetroArch issue, don’t put the blame on FBNeo, and don’t spread lies about me insulting you.
Obviously I was referring to that other guy, then. Honestly don’t know where the defensiveness is coming from. I’m just pointing out the problem. I have no idea who is/isn’t a contributor to FBNeo, didn’t know it was just you, i assumed that other guy was as well.
From a user perspective, I have zero insight into how the core itself works, I only experience how it works through RA.