Core does not switch between 352 and 320 horizontal resolutions

[retrorepair]

I believe this is on purpose to avoid scaling issues looking through the code but does cause issues with CRT Switching as some screens look fine but others look crushed.

Assume the same is true for interlaced resolutions.

Verified by manually adding borders via overscan mask.

I also assume vertical resolutions are hard set as well given the option for first and last scanline being set in options? Not all games are 240 lines tall, some are 224 and in the case of pal also 256.

[retrorepair]

Actually, does the core ever pay attention to the current resolution? It seems like it only switches if the game resolution is interlaced. Pretty sure Saturn's boot resolution should be 320x224 but it's always 352x240 (352x288 for pal) with no overscan settings changed.

[seascape]

Not sure if my Win10 Beetle Saturn / CRT issue is the same or not. Some screens look fine (320x240) but others go way off the sides of the TV. Nightwarriors is one game that does this.

I'm not sure if RetroArch's CRT SwitchRes tech is sending an inappropriate signal to the TV for some Beetle Saturn modes or if my CRT Emudriver modelines should be configured differently. (Some MAME games are similarly poor-fitting.) I've adjusted the TV's service menu to look correct for most common modes like 640x480 and 320x240 but it doesn't support per-resolution tweaking.

[retrorepair]

It's the core. If you set the horizontal overscan to output 320, it will only output 320 pixels width, regardless if the original saturn would have or not. This is why I've opened this issue.

CRT switching will switch to whatever the core requests.

MAME games will likely ve this way as an original arcade board would be on a TV. Retroarch's switching aims to mimic original hardware where as groovymame can be set up to fit most resolutions within your monitor/TV's specs.

[hiddenasbestos]

Hi, I've submitted patch #126 which correctly uses 320 wide modes and crops the top/bottom of 224 line modes, hope you can test it.

[hiddenasbestos]

To answer your original question - the core adds appropriate borders to replicate original hardware. So even though the display mode is 320, the output frame is 352 with borders, like real hardware. Same with vertical resolutions - it only outputs 240p or 480i, borders are added to the 224 mode as they would be.

I've submitted patch #126 to allow these borders to be cropped if you wish, but for accurate behaviour they shouldn't be - so the option is off by default.

[retrorepair]

I'm still not convinced original hardware did this (pad every active hres to 352), but I will need to get another saturn to verify I think.

I've not had a lot of time to test but looks good without borders so far! Only thing I did notice is 320x240 ends up forced to 60hz (been testing a PAL ISO). Not sure if that's the crt switching doing something wrong or your patch, it's the first time I've seen it do that though.

I will have more time to test tomorrow but would definitely say it's worth having the options in there and it's much less confusing for the user.

[hiddenasbestos]

Check the log, you might see this message: [INFO] [Video]: Timings deviate too much. Will not adjust. (Display = 59.94 Hz, Game = 49.96 Hz)

I'm on a regular 60hz LCD but maybe something in the CRT code isn't happy with PAL timings?

[hiddenasbestos]

I'm still not convinced original hardware did this (pad every active hres to 352), but I will need to get another saturn to verify I think.

I posted some evidence in the #126 thread -- the 2nd video shows clearly the extra 16 pixels on either side make the apparent frame slightly wider, it doesn't seem to stretch.

[retrorepair]

I'll look into the timings issue. Most of my testing has been with PAL systems though so odd how this would be the only case where this happens.

I'm going to get a saturn off ebay too and see if I can work out exactly what it does. I may have a word with the mednafen guys too and see what they think.

Thanks for your work on this by the way!

[retrorepair]

Just to update, I've not forgotten about this, I'm just making sure the information I give is accurate so been doing a lot of research.

Basically for any display that is not covered by the CRT swtiching option, this is going to be irrelevant so an option to enable/disable it is the best way to go.

A CRT doesn't have any idea what pixels are, just electrical pulses. When a real Saturn outputs video to the screen, the "internal" resolution be it 320 or 352 pixels wide, would be stretched on the TV as the borders (overscan/hblank) don't change.

On an LCD it would probably compensate for this hence the video you saw but the bottom line is, for CRT switching, as with any other core, retroarch should only recieve this internal resolution with no extra borders.

[retrorepair]

Posted this on the patch by accident, will put it here too:

Well just to resurrect this, Yabause now appears to have correct resolution switching in retroarch so I'd think this is evidence enough? It looks pretty perfect in terms of screen image placement on a real CRT and switches at every expected point (as your patch did). I've not tested on an LCD.

I've since realised by the way that all the other mednafen cores have hard set resolutions as well, at least for the height. I can't imagine what the need for it is, it's confusing and all the other cores work great without this.

To be honest, I don't see the problem with having the patch you submitted as an option you can toggle if you are worried how it'd affect LCD displays. The CRT Switch code adds the extra porch information to properly display the image and will adjust this depending on resolution as it does with all the other non mednafen cores. It IS important for how the resulting image looks on the screen.

I can show images of Yabause vs Beetle Saturn on my CRT to show the difference it makes if required.

It's important for the CRT switch option for the cores to all follow the same approach to reporting resolution, at least by way of an option toggle. There's been a lot of support questions relating to this very issue so it'd be nice to clear it up once and for all. Just tell me what you need from me.

[ghost]

Hi,

Could you tell me if my modifications about box-max.slang shader provide help for this issue ?

[seascape]

@bribgo , I assume you're referring to this contribution of yours? https://github.com/libretro/slang-shaders/issues/115

I am not in position to test right now but I hope your solution is useful!