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.