Correct Geometry - Aspect Ratio for different systems

Hello.

Let’s start fresh and anew, this thread will be a common spot for those wanting to play the games how they were supposed to be played (instead of how you used to play them). Aspect ratio has an incidence on how you play and the experience you take specially on reaction based gameplays (easy example, predicting the path of a moving diagonal shot/object). I hope this is a positive thread with users alike adding positive and informative data and opinions on what correct geometry said game/system should run.

Here you can add your screenshots and ask for help. I will keep adding images and systems. Try to look for things that you think should be perfectly round (wheel, planets…) or square (some boxes, HUD), and add the applied aspect ratio you used for the image based on the below guidelines:

Although not 100% correct, here I will talk in pixels and resolutions instead of frequencies, for the sake of comprehension. There are 2 types of resolutions for retro games. Full signal with a height of 240 pixels, which is what the original hardware used as output (because it’s what matches NTSC TVs height resolution) and cropped signal, commonly 224 pixels, which is what most emulators do (included RetroArch). Width varies upon system depending on sported CPU and its clock rate. The reason why some emulators crop the signal (read as resolution) is because on the original there was a vertical normally black padding that was ultimately being hidden by the TVs overscan, so this is thought to be useless data. This padding is technically referred by the NAB acronym and also present on commercial DVDs. Overscan is used on old CRT TVs to hide signal artifacts, and surprisingly new LCDs also make use of overscan by default, although you can remove that if you access TVs service menu. This padding also was a way to comply to the 240 pixels height, so some systems would only render at 192 pixels high, but pad to 240 to comply to NTSC.

So we have two vertical resolution variants for each system, with and without NAB. And then we have many width resolution variants one (or so) for each system. Actually not so many since many share video chip. Here you can find the clock rates that give number to the width, although no resolution is given but that is a known bit you can find elsewhere, what is important to know is the PAR value. PAR is the difference in height and width within a pixel, or in other words the ratio in which a pixel is not square. This can be as literal as it sounds where images do have rectangular pixels, or in a figurative manner where the PAR defines the ratio in which the image would look before the anamorphic scale (presumably geometry correct).

This second definition is the kind of PAR we have. This target aspect ratio is roughly (I’m not technically versed) the difference in approximation in which the clock rate needs to show a 1:1 square pixel compared to industry standard frequencies. (Check here on D2: “industry standard”)

For example, using Snes, genesis, etc clock rate. (display freq/interlacing) / system clock rate = PAR (12.272727 MHz /2) / 5.37 MHz = 1.14 = 8:7

What is not widely known are system clock rates (haven’t found reliable specs outside the Pin Eight page linked above). Active area is easy to know since it is the typical height resolution that you can find specced for any system in wiki pages, etc. Real output resolution would always pad that active area to 240px for NTSC compliant height. With PAR values active area looks kind of unnecessary, but there are cases where the ratio scaling (DAR not PAR) needs to be done without the NAB to be geometry correct, this might be due to odd decisions on the game’s development stage, but the only way for us to know is by testing said DAR to with and without NAB resolutions and decide which one looks best, although I’m yet to find one example that agrees with this.

*: Stands for presumably correct geometry. Note: because RetroArch doesn’t allow the output of the full signal, screenshots have them removed (that’s why height is never a multiple of 240 but 224 instead)

Super Nintendo Entertainment System Full(256x240) Active(256x224) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 256*(8/7)x240 = 293x240 (8:7 PAR with NAB) 1* 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)2 224*(4/3)x224 = 299x224 (4:3 DAR without NAB)1 256x240 = 256x240 (1:1 PAR with NAB)2* note: Some games had different/esoteric resolutions to accommodate to some neat effects. These are only a few but it would only affect on the DAR screenshots in any case.

These are all the combinations we need to try before judging which one we would stay with. In case of snes and genesis, developers didn’t burn their brains much. They drew everything at a 1:1 ratio (most games) regardless of how it ended being looked on real displays. With rare exceptions, F-Zero, Mortal Kombat, Street Fighters, etc were developed correctly with deviation on mind and should use the first case 293x240. In practice it doesn’t matter whether you use 224 or 240 for height, when using PAR height size is not a relevant figure.

Sega Genesis H40 mode Full(320x240) Active(320x224) (12.272727 MHz /2) / 6.71 MHz = (0.914 = 32:35) 320*(32/35)x240 = 293x240 (32:35 PAR with NAB)12 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)1*2* 224*(4/3)x224 = 299x224 (4:3 DAR without NAB)12 320x240 = 320x240 (1:1 PAR with NAB)1*2*

H32 mode (list of games) Full(256x240) Active(256x224) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 256*(8/7)x240 = 293x240 (8:7 PAR with NAB)1122 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)1122 224*(4/3)x224 = 299x224 (4:3 DAR without NAB)1122 256x240 = 256x240 (1:1 PAR with NAB)1*1*2*2* note: some ports from snes or other consoles had resolution untouched so to comply to the original sprite geometry picture was drawn at 5.37 Mhz (H32 mode) making it 8:7 PAR.

Nintendo Entertainment System Full(256x240) Active(256x224) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 256*(8/7)x240 = 293x240 (8:7 PAR with NAB)111 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look) 224*(4/3)x224 = 299x224 (4:3 DAR without NAB) 256x240 = 256x240 (1:1 PAR with NAB)1*1*1*

Nintendo Famicom Disk System Full(256x240) Active(256x224) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 256*(8/7)x240 = 293x240 (8:7 PAR with NAB)12 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look) 224*(4/3)x224 = 299x224 (4:3 DAR without NAB) 256x240 = 256x240 (1:1 PAR with NAB)1*2*

Sega Master System Full(256x240) Active(256x192) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 256*(8/7)x240 = 293x240 (8:7 PAR with NAB)11*1* 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)1*11 192*(4/3)x192 = 256x192 (4:3 DAR without NAB) 256x240 = 256x240 (1:1 PAR with NAB)111

Game Gear (GG is based on Master System hardware so except this one all handhelds are 1:1 PAR) Full(256x240) Active(160x144) (12.272727 MHz /2) / 5.37 MHz = (1.14 = 8:7) 160*(8/7)x144 = 183x144 (8:7 PAR)1*1*22 160*(4/3)x144 = 192x144 (4:3 DAR with NAB, old GG look) 160x144 = 160x144 (1:1 PAR)112*2* note: full signal is 256x240 (hardware is practically master system’s), but the same is cropped before reaching screen and probably after having the signal corrected for the 8:7 PAR natural of the master system -assuming GG’s screen is square pixels-). edit: the signal is not corrected to 8:7 PAR but to 4:3 DAR to judge by some real GG screenshots. It tries to mimic how the master system looks on CRT, whether that’s right or wrong. Some games though (arguably master system ports) are geometry correct at 8:7, while GameGear exclusives are indeed 1:1 PAR.

Sega Saturn (We don’t know but I suspect it’s the same as many of the previous systems; 8:7) Full(320x240) Active(320x240) (12.272727 MHz /2) / 5.37 MHz? = (1.14 = 8:7) ? 320*(8/7)x240 = 366x240 (8:7 PAR with NAB) (All mostly fall into this ratio, still shots to add) 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look) 240*(4/3)x240 = 320x240 (4:3 DAR without NAB) 320x240 = 320x240 (1:1 PAR with NAB)

CPS3 Full(384x240) Active(384x224) (12,272727 MHz /2) / 7.50 MHz = (0.81 = 9:11) 384*(9/11)x240 = 314x240 (9:11 PAR with NAB)1*2* 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)12 224*(4/3)x224 = 299x224 (4:3 DAR without NAB) 384x240 = 384x240 (1:1 PAR with NAB)

CPS1, CPS2 Full(384x240) Active(384x224) (12,272727 MHz /2) / 8.0 MHz = (0.767 = 135:176) 384*(135/176)x240 = 295x240 (135:176 PAR with NAB)111122 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)1*1*1*1*2?2? 224*(4/3)x224 = 299x224 (4:3 DAR without NAB)2?2? 384x240 = 384x240 (1:1 PAR with NAB)

SNK Neo Geo Full(320x240) Active(320x224) (12,272727 MHz /2) / 6.0 MHz = (1.02 = 45:44) 320*(45/44)x240 = 327x240 (45:44 PAR with NAB)1 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look) 224*(4/3)x224 = 299x224 (4:3 DAR without NAB)11 320x240 = 320x240 (1:1 PAR with NAB)1*1*

SNK Neo Geo games with horizontal padding. Full(320x240) Active(304x224) (12,272727 MHz /2) / 6.0 MHz = (1.02 = 45:44) 320*(45/44)x240 = 327x240 (45:44 PAR with NAB) 304*(45/44)x224 = 311x224 (45:44 PAR without NAB)11 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)1*1* 224*(4/3)x224 = 299x224 (4:3 DAR without NAB) 320x240 = 320x240 (1:1 PAR with NAB)1*1* note: most games make use of whole horizontal resolution, but this would leave you with a letterbox type of image, to optimize screen (4:3) area many games also added horizontal padding to compensate (ie mslug series). As with other systems designers might have accounted for the system clock rate in order to draw sprites, but here changing horizontal active area (not usual) has an effect on PAR, so as we don’t know which both of active areas designers aimed at I include both.

GameCube NTSC - DAR 4:3 (12,272727 MHz ) / 13.5 MHz = (0.909 = 10:11)

GameCube PAL - DAR 4:3 (12,272727 MHz ) / 14.75 MHz = (0.832 = 104:125)

##################################################

Settings to get the above “correct” ratios working on your config, with integer scaling and centered on a 1080 display. First set “Aspect Ratio” to “Custom” and Integer to OFF (we will input integer manually at least for the vertical resolution which is important for the scanlines). The commented (:wink: entries are not necessary since by default RetroArch allows the 1:1 ratio option.

You will just need to swap figures for the next parameters: custom_viewport_width = “1256” custom_viewport_height = “896” custom_viewport_x = “12” custom_viewport_y = “64”

Integer (vertical) and centered for 1080p: snes:1170x896 (8:7) (x=375, y=92) ;snes:1024x896 (1:1) (x=448, y=92)

;genesis(H40):1280x896 (1:1 & 4:3) (x=320, y=92)

master system:1463x960 (8:7) (x=228, y=60) gamegear:1280x1008 (8:7) (x=320, y=36)

cps3:1257x896 (9:11) (x=332, y=92) cps1,cps2:1280x896 (4:3 w/ NAB) (x=320, y=92)

;neogeo:1280x896 (1:1) (x=320, y=92)

PD: if you want to correct or add something, please be polite and stay on topic.

3 Likes

The Mega Drive/Genesis actually has two common horizontal resolutions (256 wide and 320 wide), with different pixel clocks for each. Most games will use one or the other, but occasionally you’ll find a game alternates between them. As a general rule (although one with a lot of exceptions), most native Mega Drive software uses H40 (320 wide), while H32 (256 wide) is common in games that were ported from the SNES. But again, that’s an oversimplification. Also, boring backstory stuff.

When running 256 wide, the MD uses a 5.37MHz pixel clock (like the NES and SNES, so 8:7 pixels). So like the NES and SNES, that’s 292 (technically closer to 293) square pixels to represent the MD PAR.

When running 320 wide, the MD uses a 6.71MHz pixel clock (resulting in 32:35 pixels). The fun part is here: 32/35*320 = 292.57, exactly the same width as H32. Obviously, this is no accident: the system has exactly the same DAR in both modes.

EDIT: The Neo Geo is another problem case here. As you can see from your figures, it has a characteristically wide picture, so the average user would lose a considerable amount to overscan on the sides. Because of this, many developers would only make practical use of the middle 304 pixels, and the edges would be blank, filled with garbage, etc. A big-name example would be the entire Metal Slug series, which are all 304 wide. Similar to what emulators do with unused vertical area, it’s common to lop off the sides entirely for certain games (as far as I know this isn’t automated like with SNES emulators, but determined from a database). This means that unless the emulator does otherwise, you may need to calculate the correct DAR using 304 as the width instead of 320 (so for 45:44 PAR, that’d be 310.91 or 310 for a nice round figure, and for 4:3 DAR, just a plain 304*224).

SNES supports a bunch of different resolutions:

256x224 was the most common. 512x224 was used for “hires” mode (frequently used for transparency effects), and interlacing was used in a handful of games, notably R.P.M. Racing.

Thanks I rushed a bit for posting and ended up with a mix-up of both modes for sega genesis. I fixed that and some figures to near round instead of even figures. The post as it is now is a rough sketch of what I will try to complete, so hopefully add some screenshots of both genesis modes soon. I will stick with the one used on the first game level for those ones mixing up modes.

I was surprised to find marvel super heroes looks better with plain 4:3 DAR. I would have expected something more on the CPS3 line where PAR is respected. At least with CPS2 image would look good on all old (uncalibrated?) TVs.

Do you think I should switch active area to 304x224 for NeoGeo, is this more like the rule or the exception? In any case this would work in a case where the game was designed without NAB or nominal analogue blanking. I couldn’t follow you much TBH, the only example where I use active area is in the third one “DAR without NAB”. And 4:3 DAR would give a resolution that divided by itself gives 1.33, but 304/224 is 1.36. As for PAR if I’m using vertical padding, doesn’t make sense to calculate PAR with horizontal padding as well? I prefer to do this and crop the (multiplied or not) vertical and horizontal padding on the calculated resolution, in case the emulator is already cropping it.

@hunterk: hires is used very rarely AFAIK, jurassic park, Kirby’s Dream Land 3, and Seiken Densetsu 3, maybe some more obscure games too IDK. I will try to stick to most common values for sanity reasons.

I think there are probably more games that use all 320 pixels than not, but it’s not uncommon either. Maybe 70-30% or so?

The problem for RetroArch is that some emulators (Final Burn Alpha definitely; unsure about the MAME cores) crop the image in those games to the 304, so stretching the result to any desired aspect ratio directly will be wrong. Since the Neo Geo’s full signal is 320240, if you wanted to play Metal Slug stretched to 4:3, the resolution you’d need to set in RetroArch would be 304224 (i.e. 1:1 PAR). But yeah, the full signal is still 320*240, so if you don’t want to include cropping in your figures, you can leave it out and let people correct for the difference themselves.

Added pics for Genesis and NeoGeo. Also pic #2 for CPS1/CPS2. This one Alien vs Predator looks like correct in the third option (4:3 no NAB), indeed some things are perfectly square/circle with this odd ratio. 4:3 with NAB doesn’t look wrong at all either…

I added a new “mode” for NeoGeo. Changing horizontal active area has an effect on PAR if emulator removes this padding by default, which seems to be common, so I add the mode there.

Anyways I might be wrong but the whole looks fine on 1:1 PAR, joystick circle is perfect 64x64px. I think there’s a reason why some systems chose 320x240 as default resolution, 1:1 PAR matching 4:3 DAR is perfect when saw on 4:3 displays so everything would look geometry correct and developers could draw at 1:1 ratio (it would be interesting to know if sonic looks round when jumping on an original NTSC CRT). 311x224 res for mslug is near, it might be correct specially looking the second pic, but I don’t know, I wouldn’t understand the reason to draw anamorphic by so little margin when you can do it right at 1:1. Since the emulator is not giving the possibility to show or hide padding I chose to upload screenshots without the padding although still matching the ratio on the left. That’s why I add “with/without NAB” to avoid confusion, if image res is not multiple then I clearly cropped padding. I like adding full signal figures since it’s what I think RA should be doing, for now the overscan setting is a joke because you don’t know what to expect, otherwise I would be uploading full signal shots.

Also if you know I would be interested to add some handhelds, are them all 1:1 PAR?

And for some reason, last RA build (8-10) won’t allow me to resize RA window…

Handhelds are almost always 1:1 PAR. The only exception I’m aware of is the Game Gear, whose pixels are wider than square. The GG is essentially a portable Master System and I’m pretty sure it shares the 5.37MHz clock and (theoretically) 8:7 pixels of its predecessor. That’d be 182.86 pixels, 183 with rounding. However, this all assumes that the Game Gear screen is analogous to an NTSC monitor, which … ehhhhh, I’m not well enough versed in the GG to say is the case. It’s worth noting that it’s actually a pretty simple mod to get video out from a Game Gear (with a 256*240 signal). But how is the Game Gear screen “calibrated”? More importantly, what are the precise dimensions of the Game Gear screen? I don’t know. If we assume the pixels are the expected 8:7, the DAR would be 80:63.

EDIT: For an entirely unscientific measure, characters in Sonic Triple Trouble curl into 21*24 balls. This would result in true circles with 8:7 pixels, but with graphics this small it’s impossible to make a fair measure of what the screen’s pixels look like; a minor adjustment in either direction wouldn’t be enough to require wider/slimmer art. Still, the evidence mounts that the Game Gear uses at least very-close–to-8:7-pixels.

If you want to measure things to be “more” accurate it’s better to do in higher multiples when using point sampling. Anyway for 1 or 2 pixels off I’m not going to worry much, I will probably only take one of the 4 choices of my OP leaving alone esoteric ratios.

I did give GG a try. I get a perfect circle (I keep testing with in-game footage) on the intro. This is 1280x1004, which is 160(8/7)x144 scaled up 8x7 times.

btw, I’m not sure how to treat GG, is 160x144 full signal?

Not really, re: 160144 as full signal. Again, it’s pretty much a Master System; there’s even an adapter to play any Master System cartridge on the GG, and a couple of games are literally just SMS ROMs in a Game Gear cartridge (try Castle of Illusion GG). So the hardware is perfectly capable of a 256240 signal–the picture is scaled to fit the GG screen when in this mode. It kinda looks like ass, but cut it a break, it’s a friggin’ Game Gear.

In fact, even when running in “real” GG mode, the full signal is 256240 and the hardware just shows the middle of that. Make a note of the Genesis Plus GX core setting (not running it right this minute, but something like “Extended Game Gear screen”) which expands the picture out to the full size the hardware is actually capable of. Games ported from SMS to Game Gear or otherwise derived from SMS games frequently actually “use” this area. You can play all the Sonic games in 256192; I’d even argue they’re more fun that way. But developers never foresaw people doing that, so all kinds of problems might appear depending on the title, from sprites not appearing in the “outside” area to the whole thing just being garbage.

Yeah, more horizontal data is seen with expanded option. It’s neat although I would have to custom resize the whole thing big enough to hide the garbage. Here is a list of exclusive GG games if anyone interested, there are more not shared with master system but no exclusive either.

You say that the real GG used 256x240 as output but the screen only showed 160x144, so the padding was actually cropped as it’s done now in emulators? I don’t quite get it since I doubt handhelds had overscan at all, well maybe 2 pixels? I often see resolution being 160x146. If cropping is done at all it would be before reaching screen so applying 8:7 PAR to 160x144 does actually work.

I updated a few things. Also I tried to look for a 256x240 Mega Drive game but found none. Is this very rare? because if so I probably should delete the H32 mode (kind of makes things confusing for little to no benefit).

It’s not outrageously rare, but certainly less common than H40. A few examples are:

[ul] [li]Arrow Flash (ITL)[/:m:8tcebsyo][/li][li]Bubble and Squeak (Fox Williams)[/:m:8tcebsyo][/li][li]Captain America and the Avengers (Data East)[/:m:8tcebsyo][/li][li]Devilish (Genki)[/:m:8tcebsyo][/li][li]DJ Boy (Kaneco)[/:m:8tcebsyo][/li][li]Double Dragon V: The Shadow Falls (Leland)[/:m:8tcebsyo][/li][li]Heavy Unit: Mega Drive Special (Kaneko)[/:m:8tcebsyo][/li][li]Hook (Ukiyotei)[/:m:8tcebsyo][/li][li]Insector X (Hot-B)[/:m:8tcebsyo][/li][li]Lemmings (DMA Design)[/:m:8tcebsyo][/li][li]Mega Bomberman (Hudson Soft)[/:m:8tcebsyo][/li][li]Mega Man: The Wily Wars (Capcom)[/:m:8tcebsyo][/li][li]Pac-Man 2: The New Adventures (Namco)[/:m:8tcebsyo][/li][li]Scooby-Doo Mystery (Illusions)[/:m:8tcebsyo][/li][li]Shining Force (Climax)[/:m:8tcebsyo][/li][li]Shining Force II (Climax)[/:m:8tcebsyo][/li][li]Shining in the Darkness (Climax)[/:m:8tcebsyo][/li][li]The Smurfs (Infogrames)[/:m:8tcebsyo][/li][li]Snow Bros. (Toaplan)[/:m:8tcebsyo][/li][li]Spider-Man & Venom: Maximum Carnage (Software Creations)[/:m:8tcebsyo][/li][li]Street Fighter II (both Champion Edition and New Challengers; Capcom)[/:m:8tcebsyo][/li][li]Sunset Riders (Konami)[/:m:8tcebsyo][/li][li]Viewpoint (Sammy)[/:m:8tcebsyo][/li][li]Warsong (NCS)[/:m:8tcebsyo][/ul][/li] That’s far from exhaustive, but probably enough to make the point.

They render at 320px to me. Pixels seem to be square so I’m not sure if this can be a bug on RA.

edit: I’m also getting 240x224px for NES output. Is that the active area? 240px wide is not something commonly referred around.

For NES, it sounds like you have RetroArch’s “crop overscan” feature enabled. Uncropped, NES is 256*240, no exceptions. That’s not to say developers would always fill right to the edges, but it’s a different scenario to the SNES where most games literally run 224-high and the rest is filled automatically.

Zombies looks to be an error on my part, all I did was canvas MobyGames for 256*224 Genesis screenshots, checking them now it appears their 256-wide shots were just resized from 320 by whichever user/s uploaded them. My mistake, sorry. I will remove Zombies from my previous post for clarity.

Shining there definitely looks 256-wide to me; look at all those horrible uneven pixels. It looks like 256 point filtered to 320 in that shot. Look at the lowercase "a"s in “that’s” and “today” and observe that they don’t even look the same because the doubled pixels fall in different locations. There’s a similar shot on MobyGames in the correct 256-wide:

The same thing seems to be happening with Arrow Flash. Compare your screen with this similar shot from MobyGames:

It’s hard to tell without blowing up the picture, but there’s doubled columns all over your shot; it’s perhaps easiest to see in the horizon, where the left shot is uneven and the right is a perfectly dithered checkerboard pattern.

Yes, I have it enabled but RA cropping horizontally to 240 means NES has horizontal padding, this is to input correct data above.

You are right about Shining Force but I made the screenshots with RA’s last revision using Custom 1:1 (integer on) ratio. So if one uses 1:1 PAR (which seems the correct one) for all Genesis, RA will bug on all H32 games rendering them at 320px wide. How did you managed to get the 256px images?

Those 256-wide screenshots aren’t mine, I just cribbed them from MobyGames. That said, I could hazard a guess how it could be done with RetroArch: try toggling GPU screenshots to OFF; this might allow you to capture the raw image output from the core. That’s just speculation on my part, though; I only use RetroArch on a Wii, where the screenshots are always native-res.

To say the NES has padding is iffy, many games use the full resolution. Here’s Super Mario Bros. and Kirby’s Adventure::

In horizontally-scrolling games you would get some garbage in the leftmost column of tiles (8-pixels across), so games could optionally disable it in hardware for sprites, background or both (indeed replacing with what is essentially padding), but overscan took care of the problem for many users, anyway (ditto the bottom of the Kirby screen, which is pretty much more padding, but not via any hardware capability to fill with padding, just a design choice). RetroArch’s “crop overscan” setting doesn’t care what it’s cropping around the edges, so you may lose padding or some extra visual range (or a bit of HUD in poorly-tested games).

It renders at 256px wide now, I managed to get 320px again for H32 games, it’s not consistent so I am not going to report, seems that it gets stuck under certain conditions so that’s what happened above. I tried several times to load a 1:1 PAR config and it works, so it’s going to stay like that until I find a pattern for the issue above.

I updated the H32 genesis part, to me it looks like the 8:7 PAR is the most natural, there things are not square or perfect circular but artwork looks more relaxed. It could also be 299x240 since it’s so close, but I consider that (4:3 DAR without NAB) kinda out of spec and a marginal ocurrence.

Let me check NES now. I will set active area as 256 then.

I’ve been busy lately but wanted to add that some shaders can actually change how the ratio gets applied to the image, namely was having issues with the lcd-shader.cgp shader and gamegear, so beware of that if using the above numbers. I recommend instead these fantastic ones by Pokefan531

edit: First, I added some more shots for game gear, this time Sonic Chaos, it looks better in 1:1 which goes to show how random some “correct” ratios can be, maybe we can find a sweet spot for the majority of games in this system, and make two different standards.

Also I made an autohotkey modification so custom ratios get written properly into the cfg files based on your display resolution just before launching the game, and depending on the system/game played. This works only only if you use frontends which I deem necessary seen how many limitations retroarch and other emulators present, in this case retroarch not being able to retrieve display resolution, necessary for the below operations.

if ( systemName = "Super Nintendo Entertainment System")
	{
		ratio := 8/7
		scale := floor(A_ScreenHeight/224)
		h := 224*scale
		w := round(256*ratio*scale)
	}

if ( systemName = "Nintendo Entertainment System")
	{
		ratio := 8/7
		scale := floor(A_ScreenHeight/224)
		h := 224*scale
		w := round(256*ratio*scale)
	}

if ( systemName = "Sega Master System")
	{
		ratio := 8/7
		scaleh := floor(A_ScreenHeight/192)
		scalew := floor(A_ScreenWidth/(256*ratio))
		scale := scaleh < scalew ? scaleh : scalew
		h := 192*scale
		w := round(256*ratio*scale)
	}

if ( systemName = "Sega Game Gear")
	{
		ratio := 8/7
		scale := floor(A_ScreenHeight/144)
		h := 144*scale
		w := round(160*ratio*scale)
	}

if ( systemName = "PCB CPS")
	{
		if ( AppendCFG ~= ".*CPS3.*")
			{
			ratio := 9/11
			scale := floor(A_ScreenHeight/224)
			h := 224*scale
			w := round(384*ratio*scale)
			}
			else
			{
			scale := floor(A_ScreenHeight/224)
			h := 224*scale
			w := round((h+(16*scale))*(4/3))
			}
	}


y := round((A_ScreenHeight-h)/2)
x := round((A_ScreenWidth-w)/2)

Added Nintendo and Nintendo Famicom Disk, some sprites specially in NES look better in 8:7, but probably the whole thing makes more sense in 1:1.

The nestopia core for some reason doesn’t like loading custom resolution from configuration files, only possible from RGUI, so there goes another bug, I add to my bug list.

The ratio for NES looks really wrong to me. The morph ball in Metroid becomes a vertically stretched oval.

There really is no “correct” way to display these graphics since CRTs all were calibrated differently and there was no single set of standards being applied by developers. Heck, you can even see evidence of different artists working on the same game employing different standards. For example, in Castlevania, the orb you collect after defeating a boss is perfectly circular in 8:7, but all the blocks are rectangular. You can make the blocks square by switching aspect ratios but then the orb is no longer a circle.

In short, you can’t apply a “this object should be perfectly circular/square” rule because it varies so much between games and it even varies within the same game. That said, there are still certain parameters for a “correct image.” The pixel aspect ratio (not video aspect) will be ~1.24 whenever the image is not cropped (i.e., all overscan is visible) and the image is stretched to fill 4:3. So anything that results in a PAR greater than 1.24 (wide) to 1 (tall) should be avoided. Also, most CRTs cropped top, bottom, top and bottom, or all 4 sides. Very rarely were only the sides cropped. If you crop just sides then stretch to fill 4:3 it horizontally stretches the image (to greater than 1.24:1).

Real TVs varied in how much overscan they cropped but you can still simulate the effect in emulators by adjusting the video aspect ratio, if overscan options are not available. If you crop just the top or bottom 8 scanlines and then stretch to fill 4:3 this is approximately equivalent to adjusting the video aspect ratio to 1.25:1 (or 5/4). If you crop the top and bottom 8 scanlines (16 total) this is approximately equivalent to adjusting the video aspect ratio to 1.2:1 (or 6/5). Real TVs vary in how much overscan they have so I just use whole integer ratios based on examples I’ve seen from major manufacturers. Panasonic and Vizio brand TVs crop the top and bottom by 8, and this is also what Nestopia (standalone) does.

I personally like the look of 6/5 in RA 1.0.0.2 with overscan enabled :). To get this PAR on real hardware would require a TV that cropped the top and bottom by 8 so that you wouldn’t see overscan and the image would fill 4/3.