More options for internal resolution

[72374]

What would you like to see?

Options for up to 22x internal resolution (5632 x 4224). Those are mostly useful when playing on screens with a resolution of 3840 x 2160 (4K) or 7680 x 4320 (8K), when having one of the game-views tall enough to fill most of the height of such a screen.

Bilinear-resampling (at least the one used when using MelonDS DS in RetroArch) can apply supersampling to a certain extent (resampling from at most twice the width and height the game-view is displayed at). 4224 pixels is exactly twice the largest integer-scaled vertical resolution that does fit on a 3840 x 2160 display.

Screen-Images (Super Mario 64)

3:1 - 8x:

3:1 - 16x:

2:1 - 8x:

2:1 - 20x:

---

I tried making this change, but found that hybrid- and large-screen-layouts have issues with resolutions above 16x, when using a ratio of 3:1, or above 21x, when using a ratio of 2:1; nothing was shown then.
I went looking for the cause, and so far i found that this seems to be caused by bufferSize.x in src/libretro/screenlayout.cpp becoming higher than 16384, as the buffer-size is multiplied by the larger number of the ratio (2 or 3), in both dimensions, when using either of these layout-modes. Limiting buffer-size to 16384 resulted in something being shown, but incomplete and/or not properly aligned. Solving this seems to require a rework of the way layouts are calculated.

Up to 16x seemed to work fine, and also matches the options currently available in MelonDS.
If wanted, i can open a pull-request for the change to add options for up to 16x internal resolution.

Terms

• I agree to follow the code of conduct.
• I understand that melonDS DS is not developed or maintained by the authors of melonDS.
• I understand that the author develops this core in his spare time, and that he is under no obligation to respond to this feature request.

[JesseTG]

Thanks for reaching out.

I don't mind adding this, but there's a lingering issue I'd have to resolve; namely, what to do if the max geometry is bigger than RetroArch can allocate. As discussed in #212, asking for too big a screen can cause RetroArch to crash without any chance to ask for less. It can even cause the OS to crash -- this happened with my 2014-era Mac Mini.

There's also the matter of deciding when to ask for a bigger framebuffer. Although I suppose changing the resolution doesn't happen as often as changing the layout, so I could probably afford to make that require a driver-restart.