Correct Geometry - Aspect Ratio for different systems

RetroArch General
#94

Hello. I stumbled upon this thread and forum while google searching for clarification i did not find on reddit, and you guys seen to know a lot about this stuff.

So, i got a RaspberryPi 3 running Recalbox/RetroArch on my 42 inch TV through HDMI, the usual stuff. But i’m a emulation noob, so i’m not sure if i’m doing it right in my video settings. As a example, atm i’m playing Final Fantasy IV ( II US ) on SNES.

In the Recalbox menu options i got the games setting as:

Game Ratio: Auto ( It default to Core Provided ) Smooth Games: OFF ( Because it’s really blurry ) Interger Scale: ON

And the Advance Settings: SNES as:

Core: SNES9X Next Game Ratio: Auto

Do i got it right? I’m not sure about Interger Scale, i know it’s supposed to make the pixels display correctly, but all it seems to do is make the screen smaller on top and bottom, because i see no difference at all in the pixels.

About shaders, i either use xbr.glsp or nome at all, because i don’t like the scanline/CRT ones.

#95

Hello. I stumbled upon this thread and forum while google searching for clarification i did not find on reddit, and you guys seen to know a lot about this stuff.

So, i got a RaspberryPi 3 running Recalbox/RetroArch on my 42 inch TV through HDMI, the usual stuff. But i’m a emulation noob, so i’m not sure if i’m doing it right in my video settings. As a example, atm i’m playing Final Fantasy IV ( II US ) on SNES.

In the Recalbox menu options i got the games setting as:

Game Ratio: Auto ( It defaults to Core Provided in the Retroarch Settings ) Smooth Games: OFF ( Because it’s really blurry ) Interger Scale: ON

And the Advance Settings: SNES as:

Core: SNES9X Next Game Ratio: Auto

Do i got it right? I’m not sure about Interger Scale, i know it’s supposed to make the pixels display correctly, but all it seems to do is make the screen smaller on top and bottom, because i see no difference at all in the pixels.

About shaders, i either use xbr.glsp or none at all, because i don’t like the scanline/CRT ones.

#96

If you use nearest-neighbor sampling (that is, not bilinear, which is the “smooth games” setting) at non-integer scales, you will get inconsistent output pixel sizes. A 1080p TV has 1,080 lines of resolution, which equates to ~4.5x scale. This means half of your lines will be 4 physical pixels tall and the other half will be 5 pixels tall. This results in wavy motion in vertical scrolling and some pixels being larger/smaller than their neighbors. Similarly, CRT TVs were 4:3 aspect ratio, and at ~4.5 scale, that will end up with inconsistent sizes on the X-axis, as well.

If you don’t mind the inconsistent pixel sizes, no worries! You’re all set!

If you do mind them, your options are: set the aspect ratio in RetroArch to 1:1 PAR (this will assume all of the pixels in the game are square, just like your monitor/TV’s pixels) and enable integer scaling or you can use a shader like AANN, pixellate or sharp-bilinear that will slightly antialias the edges between pixels (or a shader like hq2x, which will use integer scaling up to a certain scale and then use blurry/bilinear scaling for the rest).

#97

[QUOTE=hunterk;45943]If you use nearest-neighbor sampling (that is, not bilinear, which is the “smooth games” setting) at non-integer scales, you will get inconsistent output pixel sizes. A 1080p TV has 1,080 lines of resolution, which equates to ~4.5x scale. This means half of your lines will be 4 physical pixels tall and the other half will be 5 pixels tall. This results in wavy motion in vertical scrolling and some pixels being larger/smaller than their neighbors. Similarly, CRT TVs were 4:3 aspect ratio, and at ~4.5 scale, that will end up with inconsistent sizes on the X-axis, as well.

If you don’t mind the inconsistent pixel sizes, no worries! You’re all set!

If you do mind them, your options are: set the aspect ratio in RetroArch to 1:1 PAR (this will assume all of the pixels in the game are square, just like your monitor/TV’s pixels) and enable integer scaling or you can use a shader like AANN, pixellate or sharp-bilinear that will slightly antialias the edges between pixels (or a shader like hq2x, which will use integer scaling up to a certain scale and then use blurry/bilinear scaling for the rest).[/QUOTE]

Ok, let me see if i got you. So for SNES, to have it “right” i’d have it at 8:7 (1:1 PAR) aspect Ratio, Interger Scale on and Overscan off. Small screen, but perfectly squared.

Or i could have it at Core Provided aspect Ratio, Interger Scale OFF, crop Overscan off and a shader like xBR. Not the “right” pixels display but good screen size and, technically, the shader corrects the pixels?

#98

There are two different choices you have:

Do you want maximized screen size? If yes, you can turn integer scale off and use a particular shader to correct things like hunterk suggests. If not, turn integer scale on. This is more ‘correct’ but the differences are minor.

Do you want 1:1 PAR (which is IMO geometrically correct) which results in 8:7 aspect ratio? Then set up 8:7 (1:1 PAR) as your AR. If not, use core-provided AR which will result in 4:3 aspect ratio (this is what most of us saw on SNES when viewing on most TVs).

Finally, I would have crop overscan turned on no matter what you decide above. There is no reason not to crop off black bars - it gives you more screen real estate for the actual gameplay.

[QUOTE=OmniSandro;45984]Ok, let me see if i got you. So for SNES, to have it “right” i’d have it at 8:7 (1:1 PAR) aspect Ratio, Interger Scale on and Overscan off. Small screen, but perfectly squared.

Or i could have it at Core Provided aspect Ratio, Interger Scale OFF, crop Overscan off and a shader like xBR. Not the “right” pixels display but good screen size and, technically, the shader corrects the pixels?[/QUOTE]

#99

a shader like xBR

XBR mutilates the pixels and the resulting display looks awful.

#100

That is completely subjective.

#101

I’m trying to figure out the pixel aspect ratio for PAL version of Sega Mega Drive. Is it correct that the master clock frequency of PAL MD is 53,2 MHz (or exactly 53203424 Hz) and that the dot rate is 1/8 of that in H40 mode and 1/10 in H32 mode? If that’s correct, then the exact pixel aspect ratios got by following the same methodology of calculation as in OP would be: H40: 1843750/1662607 (~ 1.10895118) H32: 4609375/3325214 (~ 1.38618897)

For H32 the PAR is equal to the PAR calculated for PAL NES in nesdev wiki (http://wiki.nesdev.com/w/index.php/Overscan#PAL). According to the same article that’s also the case with NTSC versions of the same consoles, so I’m inclined to think that my calculation on that is correct. However, I couldn’t find any reference for the PAR in H40 mode, so that may be more uncertain.

Here is a sample on how Sonic 1 looks with PAR 1843750:1662607 (or approx. PAR 61:55, if you prefer short numbers).

#102

that uploaded image is closer to widescreen to me. it should be basically square at 61:55, surely? :slight_smile:

#103

PAR is the aspect ratio of pixels, not whole screen. And that uploaded image is only the active portion of the total screen, or viewport, so the borders that would be visible in real crt are cropped. The active display area in H40 is 320 pixels wide and 224 pixels high, while in PAL there are 288 visible scanlines, so that picture takes only 78% of the height of the viewport.

Here is another screenshot with borders enabled. That’s how it would look in 4:3 DAR and all 288 scanlines visible.

#104

Here is example screenshot how it would look in 4:3 DAR and all 288 scanlines visible.

#105

Not much love for PAL here, it seems. :slight_smile: Well I can’t blame you, mostly horrible ports from NTSC region with slowed down gameplay, out of tone music and squeezed picture. But that’s what most of us europeans grew up with.

I noticed that if I set borders to full for genesis_plus_gx in core options and use the core provided aspect ratio (which is always 4:3), then the calculated pixel aspect ratio ends up being almost equal to the one I have calculated. So far that’s the only reference point I have for my calculations being right. Is that pure coincidence? It could be, because I don’t find any deeper logic from genesis_plus_gx source code for border width calculation. Are here any genesis_plus_gx developers with whom I could discuss with about this?

BTW, if this isn’t the correct forum for this kind techical discussion, and/or you know that there’s some other forum where genesis_plus_gx libretro core developers are more active, please tell. :slight_smile:

#106

Ekeeke, the author of genplusgx doesn’t frequent any forums, AFAIK, but you might be able to get him to talk about it via github issue:

#107

Hello. :slight_smile: I’m using Libretro (Lakka) on my good old Raspberry Pi 1 to play Sega Megadrive games on Picodrive. My Raspberry is connected to a CRT TV via Composite (not the best quality I know but, hey, the real console had composite too!).

I’d like to find out, with your help, the best resolution and aspect-ratio settings for my setup. So:

  • I’m using Composite-out on RPi

  • In my config.txt (at boot)


sdtv_mode=0
sdtv_aspect=1
scaling_kernel=8

Now RPi should output at 720x480@60Hz (standard NTSC resolution, is this correct)? Whereas a “native” Sega Genesis / Megadrive resolution is impossible via Composite out, what’s the nearest result I could get?

  1. Should I add

framebuffer_width=320
framebuffer_height=224

…in config.txt?

  1. And how to combine these settings with the viewport and aspect-ratio options in Libretro (Lakka), considering that on CRT pixels are not square?

Thank you very much!

#108

I think your best bet would be to set the RPi to 640x480, which will avoid having black borders on the sides when it stretches to fill your TV, just like it would with the real console. However, coming through the composite connection, it will always output 480i (that is, 480 vertical lines interlaced). This should look perfect on interlaced content, such as Sonic 2’s multiplayer splitscreen but everything else will have unnecessary jitter. Unfortunately, this is unavoidable via the Pi’s composite output.

#109

Hi and thank you very much for your feedback.

Real console outputs (mostly) 256x224, so a framebuffer with the same values in config.txt would be better? Since it is a 8:7 aspect ratio, in Lakka/Libretro should I set 8:7 option or it wil be “redundant” with the framebuffer resolution? And integer scaling should be set to on or off? :S

Sorry, but I’m a bit 'confused by all these values and the way they interfere.

#110

RPi’s composite output is hardwired to only output 480i and there’s nothing you can do to change that. Whatever you change outside of that will always get up/down-scaled to that same 480i resolution. You’ll just want the aspect ratio to fill the screen (at 640x480, this would be 4:3) and it will look right on your TV.

#111

This thread looks good is it worth reading the lot :slight_smile:

#112

Dogway, I don’t understand why you are using the horizontal resolutions that you are for the 4:3 DAR. For example, for 4:3 DAR with NAB, why aren’t you multiplying 256 by (4/3) since NAB means the overscan is shown? Similarly, why are you multiplying 224 by (4/3) when using the 4:3 DAR without NAB. For 4:3 DAR without NAB, wouldn’t you be multiplying 240 by (4/3) instead of 224 because there are 8 lines of overscan cut off on each side which would be 16, so 256-16 = 240?

#113

Hello shatterhand, yes in hindsight I think I overcomplicated the writing. For PAR you multiply the nominator (width). For DAR I chose to keep consistent with the PAR height and kept the height value fixed, hence to calculate the DAR I need to multiply 4/3 to the height resolution (denominator), that’s why it’s 240 and not 256 what I multiply to. I could divide 256 to 4/3 as well, but that gets me a different height across all the tests.

SNES

256*(8/7)x240 = 293x240 (8:7 PAR with NAB)
240*(4/3)x240 = 320x240 (4:3 DAR with NAB, old TV look)

or also written as:

256*(8/7)x240 = 293x240 (8:7 PAR with NAB)
256x240*(4/3) = 320x240 (4:3 DAR with NAB, old TV look)

When multiplying without NAB I use 224 because 240-16=224. NAB in this case is important only in height, since we have plenty of lateral room on widescreen TVs.

Important: To add on this to note that the last portion of my OP is all while crop_overscan as true. We want to maximize the whole vertical size of our display, since further on the road using an integer height resolution won’t take advantage of the whole vertical area (some pixels off 1080). The reason I ignore the integer_scaling option is because that enforces both height and width integers, and that makes it difficult to set our (geometry correct) found PAR. My only take is to enforce height as integer resolution, to accommodate for pixel shaders.

I might release soon an small autohotkey app to input screen resolution and get the resolution and offsets for every system of the OP. This is only for those willing to play as intended; correct geometry (regardless of round circles and square blocks), not as remembered (simply use overscan, without cropping and use 4/3 DAR).