Ok. Thanks. I’ll try and then let you know how it works.
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).
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).
There are two points that I think should be emphasized:
-
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.
-
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
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.
RetroArch has a vestigial and now-deprecated “crop overscan” one-size-fits-all flag that cores can implement when they are libretro-ized, but that was not flexible enough, so we now recommend that cores implement their own cropping functionality via core options, so they can get as granular as they need without some procrustean frontend setup.
This would be difficult to communicate to the frontend and then to the shader backend in a uniform way for exactly the same reason we moved it to the core options in the first place.
3 Likes