MiSTer FPGA Forum

So I have my MiSTer hooked up to a 1440p gaming monitor with the newly-added 1920x1440 video mode enabled. As others have noted, 1440p is ideal for playing retro games with integer scaling because it's a multiple of well-known vertical resolutions like 144, 160, 240, and 480. Furthermore, it's great for integer scaling of 256x224 titles that were displayed with non-square pixels on CRT TVs: scaling to 1792x1344 (7x horizontal, 6x vertical) produces a 4:3 image that fills 93% of 1440p's vertical resolution.

Wanting to get the sharpest pixels possible, I set the SNES core to use nearest neighbor scaling with vscale_mode=1 in MiSTer.ini and noticed something was a bit off. It should have been a perfect integer scale--1344px height (as determined by vscale_mode=1) * 4:3 aspect ratio = 1792px width--but some of the pixels were different widths.

Long story short, I looked at the source code and discovered that the SNES core scales its output* to a 64:49 aspect ratio by default (the "4:3" menu option). This is also the case for the NES core when overscan is cropped and the Genesis/MegaCD cores in 256x224 mode.

I know the emulation community spent years arguing over the true SNES aspect ratio and I don't mean to question the correctness of 64:49. I just want to play games with integer scaling and don't mind if the proportions are a tiny bit off. I even downloaded Quartus and recompiled the NES and SNES cores with my preferred values for VIDEO_ARX and VIDEO_ARY, but it would be a huge hassle to do this after every core update. Would the maintainers be open to adding an additional option alongside the current 4:3 and 16:9 for a true 4:3 aspect ratio? I would be willing to submit a patch.

*I'm aware that the SNES core technically outputs at 512x224 to support games that use the hi-res modes, but for those that don't, the nearest-neighbor math should work out the same as 256x224 if I understand correctly (since it's just pixel-doubled horizontally).

MiSTer has video filters to achieve good-looking scaling without the need to be exact integer scaled.

https://github.com/MiSTer-devel/Main_Mi ... efficients

For the SNES, what you want to use is the "SNES Interpolation (Sharp)" filter.

antibolo wrote: ↑Mon Jun 22, 2020 5:05 am MiSTer has video filters to achieve good-looking scaling without the need to be exact integer scaled.

https://github.com/MiSTer-devel/Main_Mi ... efficients

For the SNES, what you want to use is the "SNES Interpolation (Sharp)" filter.

Why settle, though? Interpolation can never be quite as sharp as integer scaling, and integer scaling at 1440p is possible with what looks to be a fairly simple code change. Maybe this is in the realm of things that approximately two people care about and therefore don't justify the maintenance burden of adding an option, but I thought I should at least put the idea out there.

Count me among those that care about this too. I'd love an integer scale option. If this doesn't gain traction was it intensive to recompile the cores with the options? Would all cores need it or are there ones that already integer scale horizontal?

I also care about this option!

Jayde Six wrote: ↑Mon Jun 22, 2020 2:17 pm Count me among those that care about this too. I'd love an integer scale option. If this doesn't gain traction was it intensive to recompile the cores with the options? Would all cores need it or are there ones that already integer scale horizontal?

To be clear, this wouldn't be an integer scaling option per se (that would be a lot more work). The math just happens to work out such that when you nearest-neighbor scale a 256x224 image to a 4:3 aspect ratio in 1440p with vertical integer scaling turned on, you get horizontal integer scaling as a happy accident.

It took about 30 minutes to recompile the SNES core from scratch on my Ryzen 2600 PC, which is the main reason why it's such a hassle. The actual change was just changing the numbers 64 and 49 to 4 and 3; it didn't require any FPGA programming knowledge at all. Obviously that won't fly for the official releases since it would take away 64:49 support from those who prefer it.

As for other cores, I haven't gone through all or even most of them but the only ones I found that used the 64:49 aspect ratio were NES, SNES, and Genesis (256x224 only). NeoGeo, Genesis at 320x224, Gameboy, GBA, and SMS all default to square pixels so vscale_mode=1 will give you integer scaling at any resolution.

That's very useful info, thank you for taking the time to explain it to me.

Somehow integer scaling doesn't work correctly with vertical oriented cores, if you enable scanlines you get interference patterns. I guess an aspect ratio is applied horizontally, so it isn't really integer scaling anymore.

In genesis core there is an option to correct or not the aspect ratio. I thought that it was switching between 64:49 and 4:3... So what that option does?

Lisko wrote: ↑Thu Jun 25, 2020 10:08 am In genesis core there is an option to correct or not the aspect ratio. I thought that it was switching between 64:49 and 4:3... So what that option does?

A majority of Genesis games output at 320px horizontal resolution (320x224 for NTSC, 320x240 for PAL). The "320x224 Aspect" setting lets you choose between a square pixel aspect ratio (10:7 for NTSC, 4:3 for PAL) and the agreed-upon CRT aspect ratio (64:49 for NTSC, 128:105 for PAL*) for 320px output only--256px output is not affected.

*128:105 is kind of interesting, normally you'd expect the CRT aspect ratio to be the same (or very close) between NTSC and PAL, right? I think this is a concession to NTSC-to-PAL converted games that just letterboxed the 224p NTSC output into a 240p frame and ended up looking squished on PAL TVs. 128:105 gives the same pixel aspect ratio for 320x240 as 64:49 for 320x224, so squished games don't look squished on MiSTer.

Update on this: there is now a mechanism for specifying custom aspect ratios built into the MiSTer framework! Individual cores need to be updated to add support, but the per-core changes are pretty simple from what I can tell--hopefully this comes to all cores that can benefit from it in short order. For now you can try it out on NES (like I did), Minimig, ao486, Atari ST, and Archie. SNES hasn't been updated yet but I'd expect to see it soon.

How it works: you can specify up to two custom aspect ratios in MiSTer.ini, and they can be per-core like any other INI setting. So for NES, you could add the following to MiSTer.ini: and both 4:3 and 8:7 will show up as options under Aspect Ratio in the core menu alongside "Original" and "Full Screen". These aspect ratios produce an integer scale of NES titles (7x horizontal, 6x vertical) with vscale_mode=1 set in the INI file and MiSTer's output resolution set to 1920x1440 (use 4:3 if "Crop Overscan" is enabled, 8:7 otherwise).

A big thank you to Sorgelig for adding this! Now I don't have to spend half an hour recompiling each core with my preferred aspect ratio(s) after every update.

custom_aspect_ratio_x options are great indeed! Now we only need 5x scaling with vertical cropping for 1080p!

Custom cropping options would be great! I really hope it makes it in eventually.

This thread has been very helpful, NES and SNES are looking amazing in 1440 with 8:7 and 4:3 custom aspect ratios. Any idea how to get square pixels or horizontal integer scaling out of the TurboGrafx-16 core when using vscale mode 1 and video mode 12? No matter what aspect ratio I try, it always seems to need horizontal interpolation. Plus, it puts out resolutions like 360x242 and 270x242 that aren't listed as resolutions supported by the original hardware (heights change to 231 when overscan is hidden).

justaguy wrote: ↑Mon Jun 22, 2020 2:57 am

I know the emulation community spent years arguing over the true SNES aspect ratio and I don't mean to question the correctness of 64:49.

Technically, it should be 128:105 based on 240p for every 256 mode from Colecovision on up to PS1. That's because most of these consoles can in fact draw into the 240 lines (the NES does by default).

And yes, the dot clock of the all these 256 modes all match the formula of (256 * scale) * (8/7) for horizontal correction. There's no question or debate of it, even if there was prior to the dot clocks and Rec. 601 documentation.