Integer-scaling menu options assume 240p output

[A-Force-For-Change]

At the moment, the maximum scaling option via UI is 5x/1200p.

For high-resolution display devices (3840x2160 4K UHD, 7680x4320 8K UHD2) there need to be scaling-options up to 18x to scale 240px/PAL, and 19x to scale 224px/NTSC to fit a 8K-display.

Ideally, the integer-scaling factors provided by the UI should be customizable, either via options or via settings.bml.

[A-Force-For-Change]

Ok, I just found out that the list of available multipliers is auto-generated (presentation.ccp).

But there seems to be a bug?
Because on my screen with 1440 px height, the maximum multiplier for 224 px should be 6x, but the list only contains multipliers up to 5x.

Also does this mean, than on a 8K monitor the list of provided multipliers is almost 20 entries long?

[Screwtapello]

In the default video mode, the (NTSC) SNES renders 239 rows of output. The top 8 and bottom 7 are drawn black (unless the game turns on overscan mode), but they're always there.

However, bsnes includes the "Show Overscan Area" option in Settings → Output. When this is disabled (that is, the overscan area is hidden), bsnes always crops the top 8 and bottom 7 rows of output, so it always produces 224 rows of output — if the game turns on overscan mode and "Show Overscan Area" is disabled, nothing happens.

Meanwhile, the code that generates integer-scaling size options hard-codes the base height as 240 rows, which makes it inaccurate when "Show Overscan Area" is disabled. That's definitely a bug.

However, I'm not sure what to do about it. The obvious thing would be to regenerate the list of scales whenever "Show Overscan Area" changes, but the code that generates the list has a big "MAKE SURE THIS FUNCTION IS ONLY CALLED ONCE" comment at the top so maybe that's not a good idea? Even if we did regenerate the list, what if (say) 3× was currently selected? Should we keep the window size the same (potentially reducing the integer multiplier so the image still fits in the window), or keep the multiplier the same (potentially enlarging the window and disrupting the user's layout)?
And I just don't like the idea of changing one setting ("Show Overscan Area") causing a bunch of changes to other parts of the program; that's a recipe for mysterious crashes.

The way things are now, the only downside is that (in some environments) there's an integer scale you can't get to from the menu, only by manually resizing the window, maximising it, or entering full-screen. I suspect most people who use windowed mode want to see other things on the screen at the same time, so they only go about half-way down the scale list, not all the way to the end. Meanwhile, people who want the game to be as large as possible will go full-screen, and not care about the scale list at all.

Thanks for reporting this issue. I'm not sure how or when it might be fixed, but it's good to have it written down for other people to find.

[A-Force-For-Change]

Thank you very much for your detailed reply.

The way things are now, the only downside is that (in some environments) there's an integer scale you can't get to from the menu, only by manually resizing the window, maximising it, or entering full-screen. I suspect most people who use windowed mode want to see other things on the screen at the same time, so they only go about half-way down the scale list, not all the way to the end. Meanwhile, people who want the game to be as large as possible will go full-screen, and not care about the scale list at all.

Generally, I don't like the idea of an potential useful integer scale missing from the menu.

Manually resizing the window would be a workaround, but this way we encounter another problem/annoyance. I really like the 'shrink window to size'-option. But this options shrinks to the integer scale that is selected in the menu (5x in my case), and not to the integer scale that is currently being used (6x).

With 'shrink window to size' not being helpful here, I either have to manually adjust the size of the window to pixel-perfect match the integer scale, or I'm running into #129.

I fully understand your reasoning and that there seems to be no ideal solution for this. But wouldn't it be at least less suboptimal to generate the integer-scaling size options with 224 rows as base height for now? Better – in the edge case – one scaling factor too much that one can easily ignore, than a missing scaling factor that could be useful.