I was thinking about getting rid of the separate sections in the menu and having a preferred aspect option or something in preferences. The menu options would continue to just resize and the maintain box would force as usual.
As for the overscanned height, I have no idea what the "correct" behavior is regarding that. It's probably ideal just to not have the overscan area available at all. I figure it's such a niche option that people using it can figure out a proper window size or whatever. I'm not overly concerned about it.
It seems that every emulator GUI has its own ideas about how scaling should work. snes9x's scaling system is pretty sensible for the most part, but completely different from bsnes's scaling which is pretty sensible in a different way.
A few months ago I tried to come up with a system worked the way I
felt was most sensible, and eventually I came up with this code
What the hell, I had a whole other half a post here, where did it go.
What I wanted
to say was, I understand you're not particularly interested in rewriting the snes9x scaling system, but if you wanted to give it a try, I think my algorithm is simple, easy for the user to configure, and gives results that should closely match what a real SNES connected to a TV should do.
- "hi-res" mode doesn't affect the rendered width of the SNES frame, so we can ignore it.
- "interlace" mode doesn't affect the rendered height of the SNES frame, so we can ignore it.
- "overscan" mode affects the rendered height of the SNES frame, but only changes it by a trivial 15 scanlines. Also, if a game toggles overscan mode, proper re-scaling of the frame would cause annoying jumping. Therefore, always reserve enough room to display a frame with overscan, and just letterbox the frame while overscan mode isn't being used (I believe this behaviour has been verified on hardware).
- To make it easier to center a non-overscan frame, and just because it's a rounder number, assume 240 scanlines rather than 239.
- Aspect-ratio correction does change the rendered width of the SNES frame, so multiply the 256 pixel frame width by the aspect-ratio correction factor. Suitable factors are available in the bsnes source (calculated by measuring the output of a SNES connected to a CRT, IIRC), and copy/pasted into my code above.
- Therefore, the scaling problem is to take a rectangle that is (256xratio) pixels wide, and 240 pixels high, and scale that to fit the available output area.
The code I linked above has a few extra features (like an "only integer scaling factors" mode, and the fact that "only integer scaling" is disabled if the output window is smaller in either dimension than the SNES frame), but it's still pretty simple.
I imagine the configuration UI would look something like this:
Scaling method: [Stretch |v] (what my code calls scale_max)
|Keep square pixels | (what my code calls scale_raw)
|Aspect-ratio correction| (scale_ntsc or scale_pal)
[X] Only use exact scaling factors
That's a lot simpler than the current batch of scaling options.