I agree with this. Make no mistake, my earlier post was not advocating PAR for all systems. I have only tested SNES thoroughly right now (which IMO looks correct with PAR). CPS1 and CPS2 definitely look better stretched to 4:3 (I don’t have any experience with CPS3)
Personnally if I crop, I don’t get the bottom of the screen in Bsnes-mercury (I noticed it in Killer Instinct) ; cropping on or off has no effect on other cores like Nestopia and Genesis Plus GX.
Some cores have the cropping behavior moved to the core options (Nestopia and genplusgx are 2 good examples). Snes9x just adds padding to the bottom of the screen, which is… weird, and Snes9x-Next doesn’t have any cropping behavior at all.
It seems like Snes9x Next crops regardless, does it not? I get a 256x224 raw screenshot output from it. The crop overscan option does nothing though.
Yes, that’s correct. It’s always cropped. I haven’t checked to see how it handles games that actually use the overscan area…
I checked it out and I’m not seeing this. With that core, I took these Killer Instinct screenshots with/without crop. You can see the only difference is the cropped overscan at the top/bottom.
BTW the pics are 512px resolution, which surprises me because I didn’t think KI ran in SNES hi-resolution mode?
For PAR, lately I’ve been using 240p test suite - linearity circles. For SNES, SMD, PCE - 1.219047619047619 works best for me “on average”. It looks like an “ideal” circle in most cases and “sprite width” looks similar enough to what I remember on real TV.
bsnes cores (ntsc only) 92 24 49 92 24 49 f2 3f ==> 14 38 81 13 38 81 F3 3F
genesis plus gx, mednafen pce (ntsc only) ab aa aa 3f ==> c1 09 9c 3f
Not at all claiming it’s precise or accurate or realistic or usable or mathematically correct. But it satisfies my taste enough and “core provided value” was just way too wide / narrow for gaming.
I have no memory of PAL aspect and know that using above values for PAL games should mess you up.
tepples has a NES ntsc/pal tv pass/fail with PAR test. I’ve been using punes but have been thinking about moving back to RA-Nestopia because of some minor glitches. And the sync feature. 
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.
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.
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=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?
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]
a shader like xBR
XBR mutilates the pixels and the resulting display looks awful.
That is completely subjective.
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).
that uploaded image is closer to widescreen to me. it should be basically square at 61:55, surely?
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.
Not much love for PAL here, it seems. 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.
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: