MiSTer-devel / Main_MiSTer

Main MiSTer binary and Wiki
GNU General Public License v3.0
3.02k stars 325 forks source link

vscale_border is ignored in square resolution(s) #883

Open dfilskov opened 6 months ago

dfilskov commented 6 months ago

Please make vscale_border work in all resolutions.

I run 1920x1920 on my square Eizo 26.5" monitor.

Setting vscale_border works in the menu - but it seems that all cores ignore vscale_border unless I change resolution to e.g. 1920x1080 (which wastes a lot of screen real-estate)

I use vscale_border to get integer scaling in cores that doesn't support Integer scaling - like Gauntlet 2.

birdybro commented 6 months ago

How does vscale_mode=1 behave with Gauntlet?

dfilskov commented 6 months ago

How does vscale_mode=1 behave with Gauntlet?

Do you meant Gauntlet 1? - I can check.

Even though I use vscale_mode=1 generally in MiSTer.ini it's hard to make pixels square or integer scaled horizontally in cores that don't support integer scaling.

birdybro commented 6 months ago

Sorry, I meant Gauntlet 2. All cores support integer scaling, you use the vscale_mode for that. Maybe you mean "square pixels" instead sorta like the Genesis/MegaDrive core?

dfilskov commented 6 months ago

Actually vscale is only vertical integer scaling. That's great for shoot'em ups (vertical scrolling).

Horizontally the pixel sizes vary on cores - like Gauntlet 2 - that don't support HW-integer scaling in their video settings.

Uneven pixel widths cause a what is called shimmering on horizontally scrolling objects - like in a platformer. It happens because with uneven pixels objects change sizes slightly for each frame when they move horizontally.

To avoid this all pixels must have the same width and the same height (but their height and width don't need to be the same / not necessarily square).

Scrolling objects in an e.g. 320x240 signal where all pixels are upscaled to e.g. 3x4 or 5x3 or 5x6 "sub"-pixels will look nice without shimmering - but they might look stretched. Most systems probably look less stretched with square pixels (e.g. 4x4 or 5x5 sub-pixels) - but some probably look better with 5x6 or 6x5 sub-pixels.

dfilskov commented 6 months ago

MiSTer lacks an hscale_mode

birdybro commented 6 months ago

Ah, that's what I figured you meant, but didn't want to presume ahead of time. Yeah, typically doing HW integer scaling will throw things out of their original proportions so this is left up to the core developer. It's not as much a feature lacking from the cores as it is intentional design. Typically almost all games would not look correct with a 1:1 pixel aspect ratio.

To get rid of shimmering, but to have the original display aspect ratio preserved, I typically just use the interpolation video preset on everything.

dfilskov commented 6 months ago

Alright! - thanks. I always prefer sharp pixel perfect scaling.

Anyway - all cores should react to e.g.

vscale_border=128

when the menu does, right? - so something seems to be wrong.

birdybro commented 6 months ago

So what you are originally saying is that you have a 1920x1920 resolution display, your MiSTer.ini is set to use 1920x1920 as the resolution and when you use vscale_border=128 you don't get a border that has 64 pixels on the top and bottom?

When you say menu, you mean the Menu core when you first boot the MiSTer? If this works with vscale_border and others don't then I have an idea of where the issue might be in the framework vaguely... The HV integer settings in a handful of cores is manipulating things prior to the scaler so that's different.