Not on a desktop, laptop, or TV with a fixed (non-rotating) screen. The default of TATE disabled means that the video is rotated and displayed correctly with respect to the screen for those users.
To slightly complicate things, not all RetroArch video drivers implement SET_ROTATION, which can make behavior less consistent across platforms.
Missing from:
What video driver are you using and what romset?
Using GL driver, game is Donpachi. Windows 64 bit.
romset?
Not sure, but the rom loads in FBA and MAME 2003. How do I determine this?
I’ll investigate a little. Would you say your experience matches the description of an unimplemented SET_ROTATION as described here? https://github.com/libretro/mame2003-libretro/issues/382#issuecomment-430289081
Yes, it sounds very similar to this. The aspect ratio changes, but the image is still sideways regardless of if TATE mode is on or not.
I also opened an issue on this here:
you can probably just skip to the end.
I can see at least three Donpachi romsets in the MAME 2003-Plus working list (the one I have handy): donpachi, donpachj, and donpachk.
Can you also confirm that you are using the correct version romsets to go with MAME 2003? That would almost certainly be a different romset than one that is built for FBA or FBA 2012.
Just to make sure we are using the same terminology: https://docs.libretro.com/guides/arcade-getting-started/#step-2-use-the-correct-version-romsets-for-that-emulator
This is what I see with a MAME 0.78 donpachi romset and the default settings in MAME 2003 with the d3d11 video driver in Windows 10 x64.
Unfortunately I can’t use the gl driver – can you try d3d11? Perhaps with a fresh retroarch.cfg file?
edit: Please ignore the FPS – I had fast forward on to get to something that looked interesting.
edit 2:To further complicate things, some TATE mode rotations (although not `donpachi` I think) are compromised by missing support for SET_VIEWPORT in some video drivers.
I have documented what I know here: https://github.com/libretro/RetroArch/issues/7660
Alright, it’s good to be using the same romset, and the correct one.
You’re definitely using video_allow_rotate = "true" in your retroarch.cfg? Without that option set to its default of true, then the core will – as one might guess – not be allowed to rotate the video in this way.
Because I can’t use the gl driver, the next step would be if you could please generate a new, default retroarch.cfg (perhaps by renaming your existing one and leaving it in place) and then trying the D3D11 driver.
1 Like
I’m not also familiar with using a custom aspect ratio rather than Core Provided. This should really be tested with a clean retroarch.cfg, and then these non-default settings be added back in one at a time.
It was set to false, I set it to true and it seems to work now.
TATE off:
TATE on:
I think the problem here is that “rotation” in this context is vague, and it’s not clear what’s going on with so many different knobs/dials. I had set it to false while trying to get FBA to display correctly. Now I need to do some more tests to see what the other cores are doing now.
1 Like
I’ve seen your other posts so I know you can be thorough. Help documenting the current behavior would be quite useful
So yeah there just appears to be a complete lack of standardization among the core options which leads to a lot of confusion, which you touched on earlier.
Here’s FBA with video_allow_rotate = “true”.
quick menu -> options -> vertical mode ON:
quick menu -> options -> vertical mode OFF:
Same result.
It’s only with video_allow_rotate = “false” that I can get a correct image in FBA. Confusing!
The next two are with video_allow_rotate = “false”.
quick menu -> options -> vertical mode ON:
quick menu -> options -> vertical mode OFF:
Appears to be working with “vertical mode” ON and video_allow_rotate = “false”
In other words, video_allow_rotate = false/true seems to result in the opposite behavior in FBA compared to MAME 2003.
Also, FBA and MAME 2003 rotate the image in opposite directions with vertical mode / TATE mode enabled.
I’m just using the custom res because at 1x scale it tells you the exact resolution being used (width/height).
It seems to me (from your description) like the FB Alpha “Vertical Mode” core option value is being ignored by the core. In other words, it’s always the same as TATE Mode being disabled in MAME 2003.
Only by disabling the functionality in the frontend with video_allow_rotate are you able to prevent FBA from orienting the video for a fixed display device.
Am I right that the vertical mode core option doesn’t have any effect, that the only change is from changing video_allow_rotate?
1 Like
I’m going to work on this some more tomorrow.
1 Like
@Nesguy My mistake about width/height being switched for vertical games in fbalpha. While there is no official statement about this, i also think the core should always report resolution before rotation, i changed this behavior in a commit today. Now that it’s settled i would recommend allowing core rotation again and enabling vertical mode, it’s now upscaling properly for me, and there doesn’t seem to be issues with shaders either. One last thing about fbalpha : if you want proper aspect ratio, use core-provided aspect ratio + DAR in core options for fbalpha (actually i’m thinking about removing this core option and always forcing DAR), aspect ratio is per-game and hardcoded in the emulator for each one.
1 Like
this is one instance why a core-implemented rotation is better due to different game configurations…
the ui-based rotation only rotates the image, preserving whatever geometry and aspect was last used or if using one manually… (wswan and lynx for one uses this ui-based rotation but sends the rotated aspect ratio (or you can send rotated geometry and retain aspect using )
1 Like
@BarbuDreadMon Awesome, thanks for fixing that!
I’m a bit weird when it comes to aspect ratio. I always go with integer scaling on the y axis so that scanlines are perfect, and then manually set the x axis so that the ratio is what’s intended. I use a shader to eliminate the scaling artifacts on the x axis. I also like to overscan some games that scale to 1120 on the y axis, since this amounts to just a few lines on either side of the screen. That’s why it’s important to me to get the right aspect ratio from the core; if 320 is switched with 240 then you get an unacceptable amount of overscan or underscan with integer scaling, in many cases.
I think a problem in this discussion is that “rotation” is often being used to refer to two different things, and it isn’t always clear which is being referred to: the image being rotated 90 degrees, and the height/width of the resolution being switched. It can quickly get confusing.
A problem with the core switching the height/width of the resolution is that it results in scaling artifacts unless you choose an integer scale that’s a multiple of both x and y. Furthermore, it just seems wrong- the emulator should just spit out whatever is there without altering it before it gets to the frontend. Maybe that’s just my opinion. I can see pros/cons to either side. I agree with @markwkidd that the main thing is to have consistent behavior of core options across cores, and that more consistent labeling of core options would help.