-
-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vscale_border is ignored in square resolution(s) #883
Comments
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. |
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? |
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. |
MiSTer lacks an hscale_mode |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: