Correct Geometry - Aspect Ratio for different systems

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.

The screenshots look wrong or in your emu? I just checked and metroid morph ball looks fine. That said and as you already noticed, you are not going to get all the sprites perfectly matching a geometry correct aspect ratio in all games. Some games mix sprites of different inherent PAR so you ultimately need to comply to one of the above methods. For example Super Mario Bros 3 screenshots above, for me clouds, the 3 GUI boxes, coins and koopas are extremely vertical stretched, but I finally complied with coin boxes, mario sprite PAR, also checked some other games to see what was the general intended PAR for the NES. I don’t know if other games shooted to other PARs rather than 1:1, haven’t checked every game.

I can’t speak for badly calibrated CRT’s but a proper calibrated CRT has a sample rate of 12.2727, which should be the target for half serious developers, if you were to play games of these developers on your correctly calibrated CRT then you would be displaying correct graphics. Others though chose the easy way out and designed everything to 1:1 PAR (WYSIWYG - no standard?), so you would play the games stretched on your CRT TV, now not anymore in emulation, unlike CRT, modern (all?) LCDs are 1:1 ratio so you simply set your core PAR to 1:1 and you are good to go.

Out of curiosity, where do you get the 1.24 PAR value? NES PAR is 8:7 = 1.14. I’m actually ignoring display aspect ratios since it heavily depends on resolution, and RetroArch (or Nestopia) don’t quite want to make overscan an open useable parameter (how much is it cropped? how much is it supposed to crop? how much can I crop?) Simply leave overscan off and work with full signal values (256x240) so you know where to go. My screenshots are multiple of 224 (although calculations are made with 240px wide in mind), while overscan being off so I think they didn’t disable the auto-default nestopia core overscan, a real mess, yes.

BTW, the link for the CRT aspect ratio standards are down since a few months ago, so I updated the link with an archived one, also made a PDF copy just in case.

My point is that there isn’t really any “right,” only certain correct parameters. Check out Castlevania - looks like they had a bunch of different artists using their own standards. Certain objects look round or square as they’re supposed to at certain ratios, but other objects look stretched. The Metroid morph ball is vertically stretched at 16:15, just run to the left from the start and it’s immediately apparent. There is no single ratio that NES developers used. Often, different ratios were used by artists working on the same game. There is no single ratio that CRT tvs used. Developers just did whatever they wanted with very little consideration for how the graphics would look to the end user since there was no way to tell what kind of TV they would be using.

I can’t speak for badly calibrated CRT’s but a proper calibrated CRT has a sample rate of 12.2727, which should be the target for half serious developers, if you were to play games of these developers on your correctly calibrated CRT then you would be displaying correct graphics. Others though chose the easy way out and designed everything to 1:1 PAR (WYSIWYG - no standard?), so you would play the games stretched on your CRT TV, now not anymore in emulation, unlike CRT, modern (all?) LCDs are 1:1 ratio so you simply set your core PAR to 1:1 and you are good to go.

It has more to do with how much is cropped than the sample rate. All TVs cropped different amounts; there’s no standard when it comes to how the image was cropped and then stretched.

Out of curiosity, where do you get the 1.24 PAR value? NES PAR is 8:7 = 1.14.

1.24 is the PAR when no overscan is cropped and the image is stretched to fill 4:3. Anything below this number and above 1 is fine.

I’m actually ignoring display aspect ratios since it heavily depends on resolution, and RetroArch (or Nestopia) don’t quite want to make overscan an open useable parameter (how much is it cropped? how much is it supposed to crop? how much can I crop?) Simply leave overscan off and work with full signal values (256x240) so you know where to go. My screenshots are multiple of 224 (although calculations are made with 240px wide in mind), while overscan being off so I think they didn’t disable the auto-default nestopia core overscan, a real mess, yes. [/quote]

If you don’t want to mess with overscan than the correct PAR is 1.24 (not internal aspect but how the pixels wind up being displayed). That’s how the image looks when nothing is cropped and the image fills the 4:3 area.

I can only repeat what I said, there are sprites made with 1:1 PAR and some in 8:7, those are the ones that make sense, everything else I’m not even going to bother because a pretty disturbed developer decided that a sprite should be in 6:5 or any other ratio he took from his ass. Anyways most games fall into those 4 categories, are you sure the orb should be spherical? I do know explosions tend to be circular so I give that more relevance, plus all the environment is perfectly square based and I simply find it more pleasing, it also aligns with the other games’ ratio I tested. Aren’t these enough reasons?

Now if you want to mimic (as I figured by reading your other posts) the old nostalgia look, that depends a lot from many variable things like used CRT, console region, etc but that’s not the aim of this thread. I’m from PAL land but I don’t want to play slowed down PAL games anymore, and in the same vein I don’t want to play badly stretched games because most developers didn’t care making anamorphic sprites.

That’s not how PAR works, but still, you described example 3: 240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look) Still don’t know where you get that PAR figure.

I made this thread to clear up the confussion many people like you had. If you believe that your correct PAR is 1.24, use that PAR, but that’s not how it works. If you have question I’ll be pleased to answer but if you want to throw different findings than mine, or simply interpret “nostalgic” as “correct” then you can make another thread to shoot for nostalgia accuracy, but in my eyes that’s nothing more than 4:3 DAR with full signal (nothing to do with PAR).

What games have you tested? Because numerous games I’ve looked at change too much in game to assume that there is any “correct” ratio being applied. I mentioned Castlevania earlier. SMB3 is another good example - certain things like the three squares at the bottom should be square, but if you set the ratio to make them square then all the ? blocks become rectangular. I think they just didn’t worry much about ratios and consistency back then because it was all going to be cropped, stretched and distorted by the TV anyway.

Now if you want to mimic (as I figured by reading your other posts) the old nostalgia look, that depends a lot from many variable things like used CRT, console region, etc but that’s not the aim of this thread. I’m from PAL land but I don’t want to play slowed down PAL games anymore, and in the same vein I don’t want to play badly stretched games because most developers didn’t care making anamorphic sprites.

Pixel aspect ratio seems to have more than one definition. I understand it to mean the ratio of the pixel’s width to its height, but people also use it to mean the ratio of the screen, in pixels. Around 1.24:1 is the ratio of the pixel’s width to it’s height when the image fills the 4:3 area and no overscan is cropped.

Is it possible to recover the OP, or at least get a copy of it? I don’t have any backup and it’s the work of many months of research between Vague Rant and me, aside the thread has little meaning without it.

Thank goodness!

OP is recovered and backed up.

Edit: btw, it looks like Sega Saturn had also a 8:7 aspect ratio. It’s not stated on the Pin Eight web, but after some tests it surely complies to that ratio or a near one. Some games simply took the easy way out and opted for 1:1 like Astal or DragonBall Z Legend. Some games have mixed aspect ratio sprites (common thing in the past) like Tryrush Deppy, but most of the sprites conform to 8:7.

Hi! Is there a setting I can use that covers all bases well enough without having to manically switch out a set of numbers every time I launch a different game? Also, these numbers are tailored for 1080p displays. I have a bit smaller display, 1280x720. How do I make them work for me?

Set aspect ratio to core provided, and set integer scale to ON. Works well for me.