Overscan / Scanline / Aspect Ratio control

#6

Having cores act differently was always considered okay, I think, since the idea was that they’re independent programs whose authors may have different ideas of how things work. I agree that some of the options are weird and confusing, though.

We had started moving the overscan cropping functionality out of the frontend and into the cores at one point because the single frontend option simply wasn’t sufficiently granular enough to cover the many different core behaviors. Our plan was to eventually nuke the frontend option altogether but that obviously hasn’t happened.

The frontend option was originally a leftover from SSNES being a libsnes (i.e., bsnes) frontend exclusively, as SNES doesn’t really need any granularity, just a dumb crop / don’t crop. I tried to reconcile the cropping on snes9x2010 with snes9x-git at one point, but I couldn’t even get it to pad out the extra pixels, so I gave up.

For Higan, byuu decided to run the program at the highest possible res (512x448[?]) all the time instead of running at the more common 256x224 by default and then resizing as required (IIRC, this is because SNES can do this mid-scanline, which PC software/APIs can’t keep up with). This fucks up shaders, so when maister worked on the re-port, he added the option to downsample it to the more common, shader-friendly res. This is indeed confusing, but the alternative is just to have a core that makes all shaders look like shit, which would likely be confusing, as well.

For beetle-saturn, I believe it has black pillarboxing of varying widths, so when it appears to just widen the image, I think it’s actually cropping off black, and then when it’s cropping and stretching, that’s overshooting the black and cutting off actual image.

I actually wish more cores had the first/last scanline option, as it lets you get perfect scaling on CRTs easily.

Personally, I don’t think a database is feasible for the same reason all these goofy options are here in the first place: people are super-picky about cropping and aspect, and nobody can agree on what’s “correct”.

1 Like
#10

it’s tricky because, for example, some NES games have garbage on the extreme horizontal (SMB3 has a border on the left, and scrolling artefacts on the right), and some have useful parts (Castlevania’s UI extends the full width), so you might want to crop for some, and not for others, and you might only want to crop the horizontal overscan, and not the vertical, or vice versa.

arcade emulation rarely seems to have overscan you’d want to crop because (theory) they didn’t have to worry about consumer TVs with various viewable amounts of overscan, because the CRT of each cabinet was adjusted by the engineer. with arcade stuff you mostly have scores and useful stuff right up to the edge.

personally, i think having a global ‘crop overscan’ option isn’t going to be much use across many cores, and it’s better to have it as core options (if at all) where the emulator authors can pick appropriate defaults, and appropriate levels of control. eg, with NES you’d want to control vertical and horizontal overscan separately, and with arcade you’d not want to have any overscan options.

2 Likes
#11

As I see it, all the static DAR settings should be applied to the full size framebuffer, so you don’t get distortions if/when you decide to crop overscan afterwards. I actually play with the init/last scanline values, it’s mednafen overscan settings. Some games use the full size (240px) while others don’t, ideally to get the best of the two worlds you would set this on a per-game basis, if you stick to one (say crop) some games will lose important information on the top or bottom (ie. PSX), on Saturn meanwhile you will get black bars most often, and you might decide to crop them so the game fills the screen.

I have already made a small database for some games, that I feed to the frontend and does the pertinent job; custom next-integer resolutions based on display, system and configured aspect ratio per game, plus a zoom variable (for letterboxed games). I think options like these should be within RA anyways. I’m adjusting to in-game values, but you have to be aware games (specially on the 32-bit era) showed different resolutions for intros, FMV, Start Screen… only Core Provided does set DAR dynamically.

Edit: As I observed there’s one core that isn’t consistent, at least for ST-V Titan, the Kronos core outputs some games at 448 and others at 480 pixels and this is automatic as the core doesn’t show overscan settings.

#12

Maybe this video can solve your aspect ratio doubts:

Basically, in 90’s the horizontal resolution always were stretched to the screen margins (4:3). But some resolutions were thinner or wider. So, in the present, all screens are “pixel aspect ratio fixed”. Then when you set 1:1 aspect ratio in the core settings you can see the image thinner or wider depending of game resolution.

The problem is. If you set 1:1 the emulation shows pixel perfect but in the case of SNES, you see “taller” images. If you set 4:3 the image is like in 90s but is stretched and can cause artifacts if shaders/filters aren’t applied.

About the difference between 4:3 and NTSC. There is no difference because standard screens in Ntsc are 4:3 display aspect ratio.

1 Like
#13

I would like to see custom cropping options for every edge.

Change how many pixels to crop on each side.

1 Like
#14

I do agree. The current overscan crop should be replaced with a “crop lines” for each side, so it also deals with the Master System width overscan.

@Juandiegous, thanks for the video. I made a thread on the topic a long time ago putting together all the available data on the subject and I’m mostly using those values. For example some Saturn games should be played at 3/2 DAR, Dreamcast PAL at 5/4, and so on. You also have to be aware to apply 4/3 to the full height (240px) frame, not the cropped one (usually).

1 Like
#15

Yeah, because no two games are the same when it comes to overscan, and it can get tricky to crop the borders with shaders and get them just right.

#16

just to add, the UI based overscan option never do anything but just do nothing. the core still has to decide how many pix to take or on what side. previously in fceumm, this used to remove 8px from all sides of NES which is not significant but takes up some essential status bar labels for Castlevania for one. SMB3, though not officially done can work (or look) better with 16px remove from left and right to remove that loading seams. IMHO.

#17

The gui/libreto ovescan crop is basically a signal that tells the core to crop overscan. It working or not depended on the core logic.

1 Like
#18

my point exactly. its just an on/off switch and just for two modes only in this case.

#19

The console cores are at least arguably in much better shape than the coomputer cores regarding this, maybe because the original emulators are somewhat lacking there. E.g. Vice changes aspect ratio depending on either NTSC or PAL setting, but the NTSC number of lines is rather large (247) with no option to crop. Hatari for Atari ST has some internal resolutions which allow for some limited control of borders, but seems to always assume square pixels etc.

#20

Is someone know how to set the fceux core (or any) to get a PAL aspect ratio? I mean I’d like to get that two black borders on the top and bottom with a proper main view position. I want to an exact feeling as I had years ago but all cores that I’ve tested wasn’t able to do that. Can someone help me?

#21

Some cores definitely change the aspect ratio, but that doesn’t necessarly translate into the same borders depending on the display.

You can set the scaling for anything however into the video output settings, then scaling and choosing custom for aspect ratio. E.g. for NES on a standard 1080p display you would ideally integer scale x4, then stretch horizontally (non-integer) to something like 1420 (assuming no horizontal overscan enabled).

#22

For emulation purpose I have an old laptop with 1366x768 resolution. I’ve tried some scaling but I have no idea how to set it right. In PAL games the top border is smaller then the other and all display is pressed between. So the first thing is what dimensions should have my screen (without borders) an then set it in the right position in the way I mentioned but I don’t know how to do it. And one more thing I’m gonna play ntsc roms slowed down to 50Hz just like that like it was on all famiclones. Please give me some advice because I completely don’t know how I should set all together.

#23

I don’t know how important vertical overscan is for PAL, for NTSC I usually turn it off and leave it on for PAL in core options. Basically, the vertical NES height for your screen should be 3x= either 672 or 720.

Pixel aspect for NES PAL is supposed to be like 1.38 Horizontally this means 3x 256 (no overscan) x1.38 = 1060. You could also just use 4x horizontal (1024) since there can be downsides from uneven stretching. As for positioning, if you have custom aspect and disable integer scaling, then you should see custom x and y position settings. NTSC roms slowed: I think this should work by just choosing PAL as a region in core options.

#24

Ok. Thanks. I’ll try and then let you know how it works.

#25

I set everything according to your advice and the result is near to what I expected. I don’t understand the only one thing, why emulators don’t imitate the PAL games correctly? After changing system region to 50Hz my screen was stretched and black borders can’t be seen. I have no clue how exactly PAL NES sends graphics to CRT TVs but every games that I’ve seen on original NES and famiclones had black broders (PAL consoles of course).

#26

I think most people don’t want borders and I believe by default RA is setup to use non-integer scaling and use core provided ratios. For NES, this means it fills the entire screen by default vertically (or almost if overscan is enabled in core options).

#27

There are two points that I think should be emphasized:

  1. Emulating overscan is important. For years Nestopia had the wrong aspect ratio because it ignored overscan. DOSBox devs lament that overscan has been overlooked up to this point, and now it’s challenging to implement it while there are programs that actually do make use of it.

  2. Cropping or ignoring overscan is something that shouldn’t happen in the emulation layer. It should happen in the presentation layer. There is no switch on a console or graphics card that turns overscan on and off. The existence of the overscan is intrinsic to the system. The ‘presentation layer’ can be handled by either the core or RetroArch or a shader. The question is who should handle it.

In my opinion, a shader implementing a cropping function is the most sane approach. It reduces risk of overscan routines interfering with other parts of the system, and it communicates to users that the existence of overscan is immutable, but the presentation is adjustable.

Cores should have a way to inform RetroArch what part of the picture is overscan, and it has to be dynamic, as this value can change depending on the video mode used.

1 Like
#28

If the current implementation of the “overscan” function in retroarch is dynamic and receives info from the core, then it should be possible to pass that information to the shader system. (With some code changes by our local wizard.)

If the “overcan” function is not dynamic, and/or does not receive info from the cores, then wouldn’t some functionality need to be added to each and every core?

It sounds to me like it has to happen on the mainstream emulator side first.