Video width and height are switched when a vertically-oriented game is loaded

[Patrickdroid]

Description

With vertically oriented games, Retroarch switches the emulator-provided width and height. For example, if the width/height is supposed to be 320x240, RA will switch this to 240x320. This only occurs with vertically oriented games. I tested this in both MAME and FBA using the Windows 64 bit version of RA.

Expected behavior

The game to be displayed using the correct resolution (width/height).

Actual behavior

The height and width is switched when a vertically oriented game is loaded.

Steps to reproduce the bug

1. load any vertically oriented game in either FBA or MAME using Windows 64 bit version of RA (example: DonPachi)
2. under video settings, enable integer scale.
3. set "custom aspect ratio width/height" to 1x.
4. look at "custom aspect ratio width/height" to see that it says 240 for width and 320 for height. This is the reverse of what it should be; it should be 240 for height and 320 for width.

Bisect Results

I first noticed this a few days ago.

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.7.6
  Git version: 9750719

Environment information

• OS: Windows 10
• Compiler: NA

[Patrickdroid]

I understand that, but the emulator-provided resolution should not be changed from the correct resolution, regardless of orientation. If the game is 320x240 it should be output as 320x240, not 240x320. The user can flip it or rotate it or resize it or whatever, but the output resolution from the emulator should remain the same (eg, 320x240 should be output as 320x240 before the user does stuff to it). Otherwise you get scaling artifacts unless you just happen to adjust the y axis to a multiple of both 240 and 320 (eg, 960). And if you’re playing a game that uses a weird resolution like 19XX (384x240), then it causes big problems with overscan or underscan when using integer scaling. As of right now, video aspect ratio for vertical games must be configured manually (custom ratio width/height, non-integer) along with custom ratio x/y position, because the resolution/ratio for vertical games isn’t being detected correctly.

[Patrickdroid]

I’m not referring exclusively to capcom games. You can see this behavior in the example screenshots I posted above, which are from Donpachi.

I understand very well that certain games are meant to be displayed vertically. This doesn’t change anything that I’ve said.

With a vertically-oriented 320x240 game, width should say 320 and height should say 240, and the displayed image should be sideways. On a 4:3 CRT monitor the image would be 320x240 and sideways. You then rotate the monitor 90 degrees. This doesn’t change the image to 240x320. It is still 320x240 but now it is rotated 90 degrees so it is no longer sideways.

Altering the internal resolution of the game is incorrect, and will always result in scaling artifacts unless you happen to use a resolution that is a multiple of both 320 and 240.

[Patrickdroid]

If you display the arcade pcb to a CRT monitor in normal orientation it will be a 320x240 image that is sideways. You rotate the CRT 90 degrees. The resolution of the game remains unchanged.

[Patrickdroid]

You just aren’t getting what I’m saying. I’m going to have to post some screenshots later to help illustrate what’s going on currently and what should be going on instead.

[Patrickdroid]

First of all, just look at the first two screenshots I posted above. See where it says "custom aspect ratio width" and "custom aspect ratio height" Both of these screenshots were taken with video rotation disabled.

Width/height should be the reverse of what is shown in the above screenshots.

[Patrickdroid]

Here is what it SHOULD look like with video rotation disabled. This is what is NOT happening, currently. I created this in GIMP by manually switching the height/width in GIMP.

[Patrickdroid]

Here is what currently happens. Both of these are incorrect.

video rotation disabled:

video rotation enabled:

[Patrickdroid]

Next, here are some tests conducted by HunterK. See how video height/width are switched from what it is in my screenshots in the very first post? That's what it should be.

[Patrickdroid]

Next, I made this shot by manually resizing the resolution to 1600x1200, and used a scanlines shader. Notice how the scanlines and mask are perfectly scaled with no scaling artifacts present. This could only be the case if the game's resolution is indeed 320x240. With the currently reported resolution of 240x320, you get scaling artifacts.

[Patrickdroid]

In my initial post, I said that the behavior is present in both MAME and FBA in the Windows 64 bit version of RA. As you can see in the tests conducted by HunterK, this behavior is not present in the Linux version of RA.

[Patrickdroid]

How are we supposed to know what the core reported width and height are from the screenshots you just posted? Again, the issue is that the emulator reported height and width are not correct.

[Patrickdroid]

Tate mode ON solves the issue in MAME 2003.

Tate mode off:

Tate mode on:

[Patrickdroid]

The problem is, tate mode ON in MAME 2003 should be the default for all emulators including FBA. This is what the image looks like when you connect the actual hardware to a CRT that isn't rotated. There shouldn't be any automatic switching for vertical-oriented games. Switching height/width (Tate mode off) should be something that the user has to select because it's altering the original output of the emulated hardware. Anything done to alter the original output of the emulated hardware in this way should be something that the user has to manually select.

Still no idea how HunterK was able to get the image to to display correctly using FBA, and I'm still unable to get the other version of MAME to display the image correctly.

[Patrickdroid]

I'm not just being pedantic, here. The width/height being switched isn't helpful and causes numerous potential issues. With the current behavior of height/width being automatically switched with vertical games, you still have to rotate the image if you want correct aspect ratio and orientation or to avoid a huge amount of letterboxing, and with height/width being switched like this, it results in scaling artifacts unless you happen to choose a resolution that is a multiple of both 320 and 240.

Furthermore, there is still no way that I know of to get any emulator besides MAME 2003 to work correctly.

The current rationale of "people don't want to rotate their displays" just isn't sufficient to justify this.

[Patrickdroid]

Yes, and how do you think what you just said contradicts this statement?

I think there is a language barrier here that is preventing meaningful discussion.

[Patrickdroid]

Furthermore, the conversation has progressed quite a bit beyond the initial post. If you had been keeping up with the conversation you'd realize that the real issue is a lack of consistency between cores when it comes to the options related to video rotation.

I am 100% done debating with you what the default behavior related to video rotation should be.

It doesn't matter what the default behavior is. There are pros and cons to having rotation on or off by default and ultimately it's just an arbitrary decision that has to be made. What matters now is getting consistent behavior across cores and removing unnecessary knobs/dials that just lead to more confusion. @fr500 already outlined the solution and what he needs to implement it.

[Patrickdroid]

that was you that it in your first post your rotate an images the 90 degrees THE x /y swap

I literally can't even tell what you're trying to say, here.

I'm sorry, I really don't want to offend but the language barrier is just too much to deal with. I feel like you just consistently fail to understand the point being made and respond with irrelevant information most of the time and now I'm just wasting a lot of time trying to clarify things to you. I appreciate that you're trying to help, but we haven't been getting anywhere for a while.

[Patrickdroid]

i literally cant even figure your problem out the games will show sideways if they arent rotated. mame fba and lr cores do this.

did you even bother following the steps I listed to reproduce the bug? Or bother looking at the discussion at the libretro forums? There is most definitely something weird currently going on with video rotation and height/width being switched. It's not a problem present in all cores. Rotation behavior is not consistent across cores, for the nth time. That's probably the main problem.

So i guess i leave it at this not wasting more time on you back tracking it not a good default leaving vertical games sideways. Something you claimed fba done

FFS, the screenshots I provided prove it! Facepalm. Here, to make things even clearer:

[Patrickdroid]

you rotated the image what do you expect to happen? you creen shots prove nothing accept the video is rotated fba and mame2003 create the same images

That's exactly what I expect to happen. Do you see that you're just not following what I'm saying very well?

[Patrickdroid]

you rotated the image what do you expect to happen? you creen shots prove nothing accept the video is rotated fba and mame2003 create the same images

That's exactly what I expect to happen. Do you see that you're just not following what I'm saying very well?

No they don't, and I've provided numerous examples demonstrating this.

[Patrickdroid]

I guess you dont get it when you rotate the bideo it becomes 4:3 proof is in the screen shot from fba rotated. it 240 x 230 as well not wasting any more time repeating this

Read this thread, from this post down to the end. Others clearly recognize that there is an issue.
https://forums.libretro.com/t/switch-video-width-height-when-video-is-rotated/21674/21?u=nesguy

Please just go away. You aren't getting it and I've reached the limit of my patience with this.

[Patrickdroid]

is fba wrong as well. Ive lost my patience with this as well.

From the thread I just linked to, above:

BarbuDreadMonSenior Member
30m

@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.

So, yeah. It's not that you're wrong, it's just that you never quite understood what the problem was in the first place. Thankfully, the issue with FBA was recognized and corrected by BarbuDreadMon.

[dankcushions]

i can explain the reasoning behind TATE mode core option in mame2003:

the emulator sends two bits of information to the retroarch API; the games width and height, and how much it should be rotated:

so, for a typical arcade game, that would be:
width: 320
height: 240
rotation: 0 (none)

now, for a typical arcade vertical game (which were rendered sideways, and then the CRT was rotated when put in the cabinet), that information would be be:
width: 240
height: 320
rotation: 1/3 (90/270 degrees)

the issue is, retroarch uses the sent height and width regardless of whether it has been rotated or not. so, the emulator has to send the width and height of the game on the presumption that the rotation has happened. so, if you set video_allow_rotate = false you will get an unwanted result:

video_allow_rotate = true:

video_allow_rotate = false:

so in this case, mame2003 is sending the core:
width: 240
height: 320
rotation: 1/3 (90/270 degrees)
but video_allow_rotate = false is saying "I don't care about how much the emulator wants to rotate it", so you are ending up with the game not rotated (fine), but the screen dimension are now wrong.

TATE mode was added so that it doesn't presume rotation. Ie, it instead would send:
width: 320
height: 240
rotation: 1/3 (90/270 degrees)
(the rotation is still sent - the presumption is that anyone with a TATE setup would also set video_allow_rotate = false)

(PS, screenshots from behaviour of mame2003 from a year or so ago, and retroarch 1.3.6 - this is what i originally designed TATE mode on - someone else rewrote TATE mode in 2003 so it instead does the rotations within the core itself - personally i think it should all be handled in the front end)

so hopefully that shows the issue that TATE mode was trying to solve. IMO there's some better solutions:

1. the API lets the core find out what video_allow_rotate is set to. that way, it can send the appropriate height/width for the situation.
2. rotation of 1 (90) or 3 (270deg) also flips the height/width. this would be my preference.

i haven't really thought about the ramifications of these! :)

[dankcushions]

there is also some interplay with aspect_ratio that I've forgotten the details about.

EDIT: hmm actually it think TATE mode only changed the core provided aspect ratio. but anyway you can see the problem i had to solve.

[Patrickdroid]

no matter what your little numbers say the resolution is 240 x 320 when rotated :).

No one ever disputed that the correct resolution is 240x320 when rotated. What's being disputed is whether or not all the cores are reporting the correct resolution when the image is rotated. You really are failing to grasp what's going on, here.

Numerous people have since recognized the issue I'm describing and the issue in FBA was both recognized and fixed. The fact that you're holding firm on this even in spite of this indicates either a willful stubbornness on your part to admit that you're wrong, or just a complete misunderstanding on your part.

There are numerous ambiguities and equivocations occurring in this conversation which make it very difficult to have a meaningful discussion with you. In fact, on more than one occasion you seem to think that I'm arguing for the exact opposite of the point I'm trying to make.

The question of what the default rotation behavior should be for vertical games is almost trivial. It literally only matters the first time RA is launched, after which the user can set the behavior in the frontend. The MAIN issue is getting consistent behavior across all cores, regardless of what the default behavior should be.

Now, if we're discussing the SEPARATE issue of what the default behavior should be or what is technically "correct," I've already said what I'm going to say about that. You can either respond directly to the points I've made or continue ignoring them, either one is fine by me. Both standalone FBA and now also the FBA core do exactly what that they should be doing: by enabling rotation in the core options and enabling vertical mode in the quick menu core options, you get the correct image, which looks like this:

[Patrickdroid]

@grant2258

You are completely hopeless. Several other devs agreed that there’s an issue, FBA dev already agreed that there is an issue and fixed it In FBA. To deny that there is an issue at this point is pretty much insane. I’m done talking to you.

[Patrickdroid]

@fr500, yeah I don’t know why this is even still a discussion. I’m at a loss.

I use custom aspect ratios with RA because I overscan some games that scale to 1120 on the y axis. Switching it to core provided didn’t change what was going on with the reported width/height and rotation, as far as I could tell.

Anyway, the issue in FBA was fixed yesterday so I think this issue can be closed; rotation behavior appears to be consistent, at least from the user’s perspective. The issue of how to best handle rotation is really a separate topic that probably warrants its own issue.

[inactive123]

@grant2258 Let's please keep this respectful at the very least. That last line was unnecessary and he shouldn't have been insulted like that.

People in this thread recommended that I close this thread so that is what I will do.