Support integer-rounded aspect-correction, like bsnes-mt

[El-Juancho]

when playing center mode and aspect ratio correction turned on i have shimmering BUT when i play the same game on bsnes-mt with the options "pixel perfect" and "aspect ratio correction" on i have NO shimmering, would be cool if bsnes didnt have this problem.

Sorry for my broken english.

[rtretiakov]

Have you tried using any shaders? If you want something that looks pixel-perfect you can try sharp-bilinear or aann.

[El-Juancho]

Have you tried using any shaders? If you want something that looks pixel-perfect you can try sharp-bilinear or aann.

This fixes the error but i don't like how the shaders make the pixels look blurry.

[rtretiakov]

Yes, that is why I suggest using a shader that does not blur things, and looks approximately like it's pixel-perfect.

Check out some of these:
https://filthypants.blogspot.com/2017/01/shaders-for-sharpest-pixels.html

[A-Force-For-Change]

Using shaders to reduce shimmering would only be a bandaid solution.

The problem/solution JuanchoES is referring to is explained here:
https://tanalin.com/en/projects/bsnes-mt/

bsnes-mt

Improvements over bsnes

Pixel-perfect integer-ratio scaling on both axes
The new “Pixel-Perfect” mode does integer-ratio scaling both vertically and horizontally, even with aspect-ratio correction enabled. Thanks to this, all pixels have exactly the same size, so there is no pixel shimmering.

The “Center” mode is only pixel-perfect vertically
The “Center” mode available in both bsnes-mt and original bsnes, with aspect-ratio correction enabled, only uses integer-ratio scaling vertically. The horizontal scaling ratio is typically fractional for the purpose of achieving a precise aspect ratio.

But at fractional scaling ratios with blur disabled, different pixels in the same line have different sizes. This results in so called pixel shimmering (a.k.a. ripple effect, or jitter), when in-game objects are moving horizontally. Pixel-perfect scaling on both axes is free of this issue.

Precise aspect ratio in the “Center” and “Scale” modes

4:3 instead of 64:49
In the “Center” and “Scale” modes with aspect-ratio correction enabled, aspect ratio is precisely 4:3 (≈1.333) by default. The scaling mode can be selected and aspect-ratio correction can be enabled via the “Settings” → “Output” menu.

Original bsnes uses the aspect ratio of 64:49 (≈1.3), because it calculates the image width based on the pixel aspect-ratio (PAR) of 8:7 instead of the target aspect ratio of 4:3 of the entire image. In bsnes-mt, the 8:7 PAR mode can be enabled via the “8:7 PAR instead of 4:3 AR” checkbox in the “Settings” → “Output” menu.

More precise algorithm
A more precise algorithm is used for aspect-ratio correction in the “Center” and “Scale” modes, that uses rounding of the scaled-image width.

Original bsnes calculates a corrected width before calculating scaled size and discards fractional part of the resulting value instead of rounding. This results in an error that is higher than with rounding and grows proportionally with scaling ratio.

[Screwtapello]

I stumbled over an actual description of the "pixel-perfect aspect-correct scaling" algorithm. As far as I can tell, it works like this:

• ordinarily, the image is scaled up as big as it can be to fit the display, which probably results in a fractional scaling ratio and hence blur
• if you enable aspect-ratio correction, the vertical and horizontal scaling ratios are different, and almost certainly still fractional, and hence it's still blurry
• if you enable integer scaling without aspect correction, the vertical and horizontal scaling ratios are truncated to the nearest integer and thus crisp
• if you enable integer scaling with aspect correction in bsnes today, the vertical ratio is truncated to the nearest integer, and the horizontal ratio is still fractional so things are probably still blurry
• if you enable integer scaling with aspect correction in bsnes-mt, the vertical ratio is truncated to the nearest integer, and the horizontal ratio is independently truncated to the nearest integer, and thus crisp

If we define the "best" result as "a full-screen, crisp, aspect-correct image", then it's impossible to achieve that result on the majority of displays. All the results we can achieve fall short in various ways, but we can move the error around

• in the fullscreen, uncorrected mode, the error is "blurriness"
• in the fullscreen, corrected mode, the error is still "blurriness"
• in the integer, uncorrected mode, the error is "aspect incorrect" and the blank gap around the image
• in the integer, corrected mode in bsnes, the error is "blurriness" and the blank gap around the image
• in the integer, corrected mode in bsnes-mt, the error is "aspect incorrect" (but less so) and the blank gap around the image

Now that I see all the options laid out like that, I don't think there's any reason for bsnes to support the current "crisp vertically, blurry horizontally" mode. If you want aspect-correct output and you're willing to put up with blurriness, disable integer scaling. If you really want crispness, you can't have perfect aspect-correctness so the bsnes-mt approximation is better than uncorrected.

[Screwtapello]

I don't have time to look into it now, but I expect it shouldn't be too difficult to make this change in bsnes. I would be interested in a PR that makes this change.