MiSTer FPGA Forum

I've started a GitHub repository to collect horizontal integer scaling custom aspect ratios generated thus far. I've added several new systems and also calculated everything for 1200p alongside 720p, 1080p, and 1440p. You can use these custom ratios along with vscale_mode=1 for the purpose of achieving both vertical and horizontal integer aspect scaling, minimizing aspect ratio error when possible.

If you need contributor access to the GitHub drop a message here or PM me.

Link

https://github.com/meauxdal/MiSTer_Custom_Aspect_Ratios

Updates

2021-02-22: Automatic vertical+horizontal integer scaling has been officially added to several popular cores. This option will supersede most of the function of this repository in an easier-to-use way, so please prefer this option when possible. Source: https://misterfpga.org/viewtopic.php?p=19033#p19033

2021-02-16 (update 2): Added more Speccy ratios, added PET2001 ratios

2021-02-16 (update 1): Corrected [ZX-Spectrum] to [Spectrum], confirmed Speccy ratios are working properly (still need to add 283 height ratios)

2021-02-14: Added Minimig ratios from dfilskov at 1080p

2021-02-12: CPS1 ratios added (horizontal only), 1120p.txt added courtesy frdarko, general cleanup

2021-02-10 (update 2): Added PAL NES ratios to the main files, plus an optional wider aspect ratio for R-Type (TGFX16) to 1080p5x.txt

2021-02-10 (update 1): Added ratios for new 5x crop builds

2021-02-09 (update 2): Initial ao486, Atari800, TRS-80, TSConf, and ZX-Spectrum ratios added

2021-02-09 (update 1): Added a new file to contain ratios for sorgelig's NES_5x Patreon build (see 1080p5x.txt) and presumably others to come. Credit to Elexor on the Classic Gaming Discord for these ratios

2021-02-07 (update 2): Comments have been overhauled to provide more information for those interested in calculating their own ratios. Pixel clocks used, unreduced pixel aspect ratios, and more have been added. Minimig ratios are still problematic

2021-02-07 (update 1): New Minimig and VIC-20 ratios by LamerDeluxe added. Largely untested C64, Astrocade, Vectrex, and Odyssey2 ratios added

2021-02-06: Added Minimig and Colecovision ratios, cleaned up SMS somewhat (still waiting for the new build for further cleanup), added high-resolution mode for TG16 (used for Sherlock Holmes) [Edit: Minimig not working yet. This one will require more some more work.]

Oh wow, I have just been busy today with calculating correct aspect ratios for most of my vertical arcade cores, to give them integer horizontal scaling with full vertical scaling, at the expense of a slight aspect-ratio inaccuracy, which doesn't seem to be a problem at all with these old games.

This finally clears up the vertical scanlines perfectly, it looks great. I haven't noticed the non-integer vertical scaling at all. And like you mention, that can be fixed by selecting integer vertical scaling (you do need to calculate the different aspect ratio for that).

It doesn't seem to be possible to have a correct aspect ratio in combination with integer horizontal scaling with the current options.

112:135 was the most common one (which is very close to 5:6) for all the arcade cores with a width of 224 pixels, 8:9 was also common. So I set those as global custom options. I was surprised that you can only set two global ones.

Thanks for the repository! That is a really useful idea, I'll have a look at it.

EDIT: Your repository seems meant for square pixels, I'll just post my ratios (I haven't done all of the vertical arcade cores yet) for integer horizontal scaling combined with full vertical scaling, for vertical arcade cores here:

! For 1080p with vscale_mode=0, check the orignal game resolution that pops up at the top-left when starting a core. To apply to a single core, open the core menu, note its name in the left border, add to mister.ini:

[the core name mentioned above, case doesn't matter, add these brackets]
video_mode=8 (for 1920x1080, if that isn't your global setting)
vscale_mode=0 (for full vertical scaling, if that isn't your global setting)
custom_aspect_ratio_1=112:135 (the correct ratio listed below)

Then select the custom aspect ratio in the core menu.

225 x 256 = 5:6
224 x 253 to 224 x 297 (and a bit below/beyond, haven't checked the exact range) = 112:135
234 x 256 = 13:15
240 x 253 = 8:9
240 x 320 = 2:3
240 x 337 = 2:3
240 495 = 8:9 (double width)
240 513 = 8:9 (double width)
240 192 = 32:45 or 8:9 pick the one you like, I chose 8:9
384:448 -> 32:45

I calculated them this way:

Divide 1080 by the vertical size of the display of the core, that pops up at the top-left when you start it. This is the largest number of the two, it might be displayed before the horizontal size.

Round the result of your division to the nearest round number.

Multiply that by the width of your core display.

Your ratio is the calculation result followed by ':1080'

Simplify that ratio by entering those two values in this calculator: https://www.bellevuefineart.com/aspect- ... alculator/

Great work! The custom aspect ratio feature is very powerful indeed, I hadn't even thought about using it in that way. Maybe we can put yours up there as well, potentially as new files. Those ratios look useful!

LamerDeluxe wrote: ↑Sat Feb 06, 2021 7:44 pmEDIT: Your repository seems meant for square pixels[...]

Just a quick note, the calculator uses the pixel clock to try and minimize aspect ratio error. Resulting pixels will be consistent in size but not necessarily square! In some cases I've provided both a (thin) and (wide) ratio so you can decide which you like better. In most cases, the calculated PAR isn't exactly square, especially at the higher resolutions with more pixels to work with.

A quick way to get square pixels (1:1 PAR) with vscale_mode=1 in many cases is to use a custom aspect ratio equal to the resolution that appears on the screen in the OSD when switching to it, or the dimensions of a screenshot taken in that resolution.

meauxdal wrote: ↑Sat Feb 06, 2021 8:30 pm Great work! The custom aspect ratio feature is very powerful indeed, I hadn't even thought about using it in that way. Maybe we can put yours up there as well, potentially as new files. Those ratios look useful!

Thanks! I got the idea to look into this from a user in another topic here.

My main motivation was getting rid of the ugly interference patterns in the vertical scan lines. Though I would have preferred a correct aspect ratio with that. I think a separate file for integer horizontal scaling combined with full vertical size, for cores with vertical displays would be a good idea.

Just a quick note, the calculator uses the pixel clock to try and minimize aspect ratio error. Resulting pixels will be consistent in size but not necessarily square! In some cases I've provided both a (thin) and (wide) ratio so you can decide which you like better. In most cases, the calculated PAR isn't exactly square, especially at the higher resolutions with more pixels to work with.

Interesting, that is very thorough. I'm looking forward to trying them.

A quick way to get square pixels (1:1 PAR) with vscale=1 in many cases is to use a custom aspect ratio equal to the resolution that appears on the screen in the OSD when switching to it, or the dimensions of a screenshot taken in that resolution.

Yes, I've read that trick in another topic, it makes a lot of sense.

I can't push to your repository, I've made ones for the VIC-20:

Mister source resolution:
228 x 280 (PAL)
204 x 241 (NTSC)

Pixel clock:
4433618 Hz (PAL)
4090909 Hz (NTSC)

PAL:
Integer aspect ratio for 480p (2x and 1x): (57:35) minimum required pixel clock: 7.584192 mhz
Integer aspect ratio for 720p (3x and 2x): (171:140) minimum required pixel clock: 22.752576 mhz
Integer aspect ratio for 1080p (5x and 3x): (19:14) minimum required pixel clock: 56.881440 mhz
Integer aspect ratio for 1200p (7x and 4x): (57:40) minimum required pixel clock: 106.178688 mhz
Integer aspect ratio for 1440p (8x and 5x): (228:175) minimum required pixel clock: 151.683840 mhz
Integer aspect ratio for 1576p (8x and 5x): (228:175)

NTSC:
Integer aspect ratio for 480p (2x and 1x): (408:241) minimum required pixel clock: 6.914425 mhz
Integer aspect ratio for 720p (3x and 2x): (306:241) minimum required pixel clock: 20.743275 mhz
Integer aspect ratio for 1080p (6x and 4x): (306:241) minimum required pixel clock: 82.973100 mhz
Integer aspect ratio for 1200p (6x and 4x): (306:241) minimum required pixel clock: 82.973100 mhz
Integer aspect ratio for 1440p (8x and 5x): (1632:1205) minimum required pixel clock: 138.288499 mhz
Integer aspect ratio for 1576p (9x and 6x): (306:241)

I should be able to give contributor rights if you need them for the Github. For now, I've added these new ratios to my working files and will add them to them the site on my next commit.

And here are settings for the MiniMig that work (at least on 1080p, some other values seem wrong).

MiSTer source resolution:
754 x 572 (PAL)
754 x 241 (NTSC, don't know why it needs to be half size vertically)

Pixel clock:
14.187580 (PAL)
14.318180 (NTSC)

PAL (Seems to be the same as Original):
Integer aspect ratio for 480p (1x and 0x): (1:1) minimum required pixel clock: 0.000000 mhz
Integer aspect ratio for 720p (1x and 1x): (29:22) minimum required pixel clock: 25.618507 mhz
Integer aspect ratio for 1080p (1x and 1x): (29:22) minimum required pixel clock: 25.618507 mhz
Integer aspect ratio for 1200p (1x and 2x): (29:44) minimum required pixel clock: 51.237014 mhz
Integer aspect ratio for 1440p (1x and 2x): (29:44) minimum required pixel clock: 51.237014 mhz
Integer aspect ratio for 1576p (1x and 2x): (29:44)

NTSC (Big improvement):
Integer aspect ratio for 480p (2x and 1x): (1508:241) minimum required pixel clock: 25.556257 mhz
Integer aspect ratio for 720p (1x and 2x): (377:241) minimum required pixel clock: 25.556257 mhz
Integer aspect ratio for 1080p (2x and 4x): (377:241) minimum required pixel clock: 102.225028 mhz
Integer aspect ratio for 1200p (2x and 4x): (377:241) minimum required pixel clock: 102.225028 mhz
Integer aspect ratio for 1440p (2x and 5x): (1508:1205) minimum required pixel clock: 127.781285 mhz
Integer aspect ratio for 1576p (3x and 6x): (377:241)

Are you using Video area by Blank or Blank+ for Amiga? I have been having a lot of issues getting ratios to work on that core...

meauxdal wrote: ↑Sun Feb 07, 2021 2:32 pm Are you using Video area by Blank or Blank+ for Amiga? I have been having a lot of issues getting ratios to work on that core...

Oh, sorry, forgot to mention, I'm using the default Blank setting. The source resolutions displayed by MiSter don't give correct results. I had to experiment a bit to get proper values out of it. Not sure if some of the results could be caused by a bug in the aspect ratio calculator.

I am adding your values to my current commit along with some extra information (including unreduced PAR in the comments so you can know the integer scaling for each axis at a glance), but I did go ahead and add you as a contributor on the GitHub, LamerDeluxe. Consoles are definitely easy mode compared to arcade and especially computer cores. This stuff is super-confusing!

Going to try out your Minimig ratios now and see how they work on my end.

I still have no luck with any Minimig ratios. Mainly testing in 720p as that's the easiest way for me to work rapidly. No matter what I do, I can't get it to work. What was your methodology for generating those Minimig resolutions? Nothing seems to work for me and I'm not sure where you got those values.

And here I thought I was obsessive about aspect ratio and integer scaling... Nice work! My head is spinning from all those different Atari 2600 resolutions.

For what it's worth re: your recent commits, jotego's cores don't read custom aspect ratio settings from MiSTer.ini. The only way I can find to change the default of 4:3 is recompiling the core with the JTFRAME_ARX and JTFRAME_ARY macros set (https://github.com/jotego/jtframe#aspect-ratio).

Thanks for the info on Jotego's cores. That Arcade section really only currently exists as a placeholder, but I'll be working on it more soon.

meauxdal wrote: ↑Sun Feb 07, 2021 10:19 pm I still have no luck with any Minimig ratios. Mainly testing in 720p as that's the easiest way for me to work rapidly. No matter what I do, I can't get it to work. What was your methodology for generating those Minimig resolutions? Nothing seems to work for me and I'm not sure where you got those values.

I've been missing all responses, but I have found the unread posts option now, which is really helpful.

I haven't been testing in 720p, I'll do that next time to see if I can get something to work properly with Minimig.

meauxdal wrote: ↑Sun Feb 07, 2021 10:19 pm I still have no luck with any Minimig ratios. Mainly testing in 720p as that's the easiest way for me to work rapidly. No matter what I do, I can't get it to work. What was your methodology for generating those Minimig resolutions? Nothing seems to work for me and I'm not sure where you got those values.

I just looked up the pixel clocks, looked at the source resolutions at the top left of the display when starting a core and noticed some of them were really odd.

Plugged them into the aspect ratio calculator and when it came up with zero or really stretched aspect ratios, I halved or doubled the input width or height until ratios that looked correct came out. I don't know what is going on with those weird source aspect ratios.

I think the calculator needs an update for the Amiga. If I'm understanding this correctly the Amiga does not use 13.5 mhz sample rate for NTSC/PAL video but instead uses a 28.375160MHz (SHRES ECS/AGA) or 14.187580MHz (for HIRES) sample rate. This could explain the wrong results. I'll be adding an option to select Amiga (AGA or HIRES mode) in the calculator.

I've ceased using the resolution display on the OSD for these calculations, as the screenshot tool is much more reliable. Take a screenshot, plug the dimensions into the calculator, and even if you lack the real dot / pixel clock you can usually fudge it a little bit until you get the desired ratios. I tend to provide multiple options to account for thinner or wider taste, especially at 1440p, and you can get the calculator to spit them out for you by making adjustments to the pixel clock.

With that said, the screenshot details in the Amiga core still don't appear to produce accurate ratios. It's very confusing to me that the method that works in every other core doesn't work in Amiga, and I'm not sure pixel clock is the reason why. After all, changing the pixel clock is only going to give different width ratios, but the results should be integer scaled on both axes nonetheless. Something about how Minimig reports resolution appears to be peculiar. I will say that when attempting to use LamerDeluxe's ratios, I could not find any games or software that were using an appropriate resolution for those. As of yet, I've been unable to see full integer scaling even once in the Minimig core!

LamerDeluxe, I'm curious what software/games you used to test your Minimig ratios, and how you checked to confirm whether or not they were working? I'd like to, if nothing else, see if your ratios will work for me given the same software. I use a method similar to one described by dfilskov in another thread, toggling the scale filter onto Misc/Horz Interpolation Only/Gaussian_Sharp_NN_07.txt, as this one is the easiest for me to tell when horizontal integer scaling has been achieved. No matter what I've done to date, I always get pixel shimmer when doing this in the Minimig core, and shimmering when scrolling horizontally. I know there's some detail I'm missing somewhere...

meauxdal wrote: ↑Wed Feb 10, 2021 2:19 am With that said, the screenshot details in the Amiga core still don't tend to produce what seem to be accurate ratios. It's very confusing to me that the method that works in every other core doesn't work in Amiga, and I'm not sure pixel clock is the reason why. After all, changing the pixel clock is only going to give different width ratios, but the results should be integer scaled on both axes nonetheless. Something about how the Minimig reports resolution appears to be peculiar. I will say that when attempting to use LamerDeluxe's ratios, I could not find any games or software that were using an appropriate resolution for those. As of yet, I've been unable to see full integer scaling even once in the Minimig core!

I wasn't referring to the pixel clock in my previous post but the rate at which NTSC/PAL is sampled. The calculator had this set at 13.5 Mhz which works for older consoles but the Amiga used higher frequency oscillators which is why it wouldn't work on SDTV. I'm almost done patching the calculator so we can test if this improves results.

Ah, my mistake! I'm learning a lot these days and I greatly look forward to seeing if this patch improves our results for Amiga!

The online calculator now has the option to select Minimig/Amiga. I haven't tested any custom AR's with it yet. Let me know if this requires more investigation/patches. We might have to check these values as well:

LINES_NTSC = 240.0
LINES_PAL = 288.0

These are hardcoded FCIF PAL NTSC values atm. Not sure what the correct values for the minimig should be. I think the correct values for Amiga line number need to be:

LINES_NTSC = 200.0
LINES_PAL = 256.0

If someone can confirm? (source http://oldwww.nvg.ntnu.no/amiga/amigafa ... AQ_19.html)

Number of lines for Minimig NTSC/PAL also updated in the calculator (using different NTSC/PAL standard number of lines than FCIF format)

meauxdal wrote: ↑Wed Feb 10, 2021 2:19 am LamerDeluxe, I'm curious what software/games you used to test your Minimig ratios, and how you checked to confirm whether or not they were working? I'd like to, if nothing else, see if your ratios will work for me given the same software. I use a method similar to one described by dfilskov in another thread, toggling the scale filter onto Misc/Horz Interpolation Only/Gaussian_Sharp_NN_07.txt, as this one is the easiest for me to tell when horizontal integer scaling has been achieved. No matter what I've done to date, I always get pixel shimmer when doing this in the Minimig core, and shimmering when scrolling horizontally. I know there's some detail I'm missing somewhere...

I've only checked with the 'insert workbench disk' startup screens. But now that you mention it, resolutions on the Amiga are quite variable. So it might not be possible to come up with a proper solution this way. We really need an integer horizontal scaling option.

As for the vertical arcade cores. I just read an idea in another aspect ratio thread of using the vsync_border option to shrink the display vertically, to get the desired aspect ratio (only works with vscale_mode=0). Combined with my horizontal integer scaling method this could make the resulting aspect ratio correct. Not a very elegant solution though.

morf77 wrote: ↑Wed Feb 10, 2021 2:45 am The online calculator now has the option to select Minimig/Amiga. I haven't tested any custom AR's with it yet. Let me know if this requires more investigation/patches. We might have to check these values as well:

LINES_NTSC = 240.0
LINES_PAL = 288.0

These are hardcoded FCIF PAL NTSC values atm. Not sure what the correct values for the minimig should be. I think the correct values for Amiga line number need to be:

LINES_NTSC = 200.0
LINES_PAL = 256.0

If someone can confirm? (source http://oldwww.nvg.ntnu.no/amiga/amigafa ... AQ_19.html)

Number of lines for Minimig NTSC/PAL also updated in the calculator (using different NTSC/PAL standard number of lines than FCIF format)

Looking at the numbers, this seems to work out. Those non-over-scan resolutions are correct (I'm a bit of an Amiga veteran, programmed lots on it as well).

Here we go, Amiga low resolution, as used for most games:

7.093790
320 x 256
PAL

Integer aspect ratio for 480p (1x and 1x): (5:4) minimum required pixel clock: 4.866048 mhz
Integer aspect ratio for 720p (2x and 2x): (5:4) minimum required pixel clock: 19.464192 mhz
Integer aspect ratio for 1080p (4x and 4x): (5:4) minimum required pixel clock: 77.856768 mhz
Integer aspect ratio for 1200p (4x and 4x): (5:4) minimum required pixel clock: 77.856768 mhz
Integer aspect ratio for 1440p (5x and 5x): (5:4) minimum required pixel clock: 121.651200 mhz

7.159090
320 x 200
NTSC

Integer aspect ratio for 480p (2x and 2x): (8:5) minimum required pixel clock: 18.001920 mhz
Integer aspect ratio for 720p (2x and 3x): (16:15) minimum required pixel clock: 27.002880 mhz
Integer aspect ratio for 1080p (4x and 5x): (32:25) minimum required pixel clock: 90.009600 mhz
Integer aspect ratio for 1200p (5x and 6x): (4:3) minimum required pixel clock: 135.014400 mhz
Integer aspect ratio for 1440p (5x and 7x): (8:7) minimum required pixel clock: 157.516800 mhz

As you can see, PAL comes up with a perfect 5:4 ratio, which is correct for the SD PAL standard (I have a background in broadcast TV software and graphics).

And Amiga high resolution (which is interlaced):

14.187580
640 x 256
PAL

Integer aspect ratio for 480p (2x and 1x): (5:1) minimum required pixel clock: 19.464192 mhz
Integer aspect ratio for 720p (1x and 2x): (5:4) minimum required pixel clock: 19.464192 mhz
Integer aspect ratio for 1080p (2x and 4x): (5:4) minimum required pixel clock: 77.856768 mhz
Integer aspect ratio for 1200p (2x and 4x): (5:4) minimum required pixel clock: 77.856768 mhz
Integer aspect ratio for 1440p (2x and 5x): (1:1) minimum required pixel clock: 97.320960 mhz

14.318180
640 x 200
NTSC

Integer aspect ratio for 480p (1x and 2x): (8:5) minimum required pixel clock: 18.001920 mhz
Integer aspect ratio for 720p (1x and 3x): (16:15) minimum required pixel clock: 27.002880 mhz
Integer aspect ratio for 1080p (2x and 5x): (32:25) minimum required pixel clock: 90.009600 mhz
Integer aspect ratio for 1200p (2x and 6x): (16:15) minimum required pixel clock: 108.011520 mhz
Integer aspect ratio for 1440p (3x and 7x): (48:35) minimum required pixel clock: 189.020160 mhz

And then the ECS chipset has things like super hires and productivity mode. I can't remember if the AGA chip set supported even more resolutions.

EDIT:
These aspect ratios look clean to me, but seem a little bit horizontally squashed.

LamerDeluxe wrote: ↑Wed Feb 10, 2021 1:17 pm And then the ECS chipset has things like super hires and productivity mode. I can't remember if the AGA chip set supported even more resolutions.

I could add those resolution modes. All I need to add those to the calculator is the number of lines for PAL and NTSC and the samplerate of the NTSC/PAL format in mhz for those modes.

morf77 wrote: ↑Wed Feb 10, 2021 2:24 pm

LamerDeluxe wrote: ↑Wed Feb 10, 2021 1:17 pm And then the ECS chipset has things like super hires and productivity mode. I can't remember if the AGA chip set supported even more resolutions.

I could add those resolution modes. All I need to add those to the calculator is the number of lines for PAL and NTSC and the samplerate of the NTSC/PAL format in mhz for those modes.

Super high res seems to just double the pixel clock (1280 x 256 for PAL), it looks fine with the same aspect ratio, at least at 1080p.

Productivity mode is 640 x 480. The Amiga's OS says it is 31.44kHz x 60Hz, MiSTer reports 31.12Khz 59.2Hz. I couldn't find pixel clock values online. It works fine on MiSTer. I'd expect this to have an aspect ratio of 4:3 with square pixels.

Thanks for all the great work on the Amiga stuff! I will give it a go soon and see if I can get them working.

Just added ratios for the new 1080p 5x crop builds to the repository. I'm very also excited by Yim's work on automatic horizontal integer scaling in the SMS core, which should be relevant to most people following this thread

I love what Yim has achieved and all the work you and others have been putting into aspect ratio options. I hope this will lead to a separate option in mister.ini for integer horizontal scaling. An option to set the integer scaling multiplier(s) yourself, with possible cropping, would also be cool.

It could be hscale_mode and vscale_mode, 0 = full, 1 = integer, 2 = 1x, 3 = 2x, 4 = 3x. Not the most intuitive, but to be backwards compatible. Assuming nobody is using those half and quarter modes, which IMO aren't really useful.
I don't know if you'd want different scale factors for horizontal and vertical, otherwise it could just be something like scale_multiplier = 1, 2, 3, 4 etc.

I went with an option in the OSD partly because I knew how to make one already and partly because for testing it was better to be able to turn it on and off and switch between narrow and wide on the fly rather than having to edit mister.ini and reboot every time. If the option were changed to be in the the ini file then I think it would be possible to distribute it to every core just by updating the framework, but I think my preference is still to have it in the OSD. It’s only a few lines to code per core to add an OSD menu option.

I thought about having choices for how much to multiply by, but it makes things more complicated. It would also lead to fluctuating aspect ratios in cores where the resolution changes - if the system goes from 320x240 to 640x480 (just a random example), then under my current implementation the scaler would just scale by half as much and the image would remain the same size (unless it had been upscaled by an odd multiple, in which case it would shrink slightly). If the setting were for 4x multiple then it would go from 1280 wide at 320x240 up to 2560 wide at 640x480. Not an issue on SMS where I’ve done it so far, but my goal is to have this distributed to all cores.

If there were to be an option to choose the upscaling multiple I’d definitely want there to be separate options for horizontal and vertical, otherwise the aspect ratio would be fixed at the core’s resolution which would often be incorrect.

Not too long ago I submitted a feature request to ask Jotego to add custom aspect ratio support to his cores. He has recently made the changes to his framework, and all cores compiled from now on should include that option.

Yim wrote: ↑Thu Feb 11, 2021 12:10 am I went with an option in the OSD partly because I knew how to make one already and partly because for testing it was better to be able to turn it on and off and switch between narrow and wide on the fly rather than having to edit mister.ini and reboot every time. If the option were changed to be in the the ini file then I think it would be possible to distribute it to every core just by updating the framework, but I think my preference is still to have it in the OSD. It’s only a few lines to code per core to add an OSD menu option.

I thought about having choices for how much to multiply by, but it makes things more complicated. It would also lead to fluctuating aspect ratios in cores where the resolution changes - if the system goes from 320x240 to 640x480 (just a random example), then under my current implementation the scaler would just scale by half as much and the image would remain the same size (unless it had been upscaled by an odd multiple, in which case it would shrink slightly). If the setting were for 4x multiple then it would go from 1280 wide at 320x240 up to 2560 wide at 640x480. Not an issue on SMS where I’ve done it so far, but my goal is to have this distributed to all cores.

If there were to be an option to choose the upscaling multiple I’d definitely want there to be separate options for horizontal and vertical, otherwise the aspect ratio would be fixed at the core’s resolution which would often be incorrect.

Good point! Dynamic changes in resolution always makes these things more complicated. I just though of the multiplier mostly because I have seen it with emulators and apparently some people like one to one pixel displays, even if the result is tiny.