crop overscan is always enabled about genesis-plus-gx HOT 9 CLOSED

Can you report this issue on the upstream repo? https://github.com/ekeeke/Genesis-Plus-GX

from genesis-plus-gx.

"crop overscan" is a RA specific option, I have no idea what it is supposed to do or how it works with core image output but I hardly see how it could be a core issue since this is completely transparent for the core.

That's said, Genesis Plus GX let you enable/disable color borders emulation through "core settings" so maybe that's what you misconfigured.

from genesis-plus-gx.

I'm fairly certain this is a core issue. I've already reported this to the RA staff and they told me to report it here. This doesn't have anything to do with core options or color borders.

from genesis-plus-gx.

As explained here and unless I'm missing something, I hardly see why anyone would think such specific resolution or upscaling could be caused by the core. The frontend is supposed to handle all these stuff so I think it's more logical to first investigate issue on that side or the way frontend is being used / configured before dispatching it to the core, right ?

from genesis-plus-gx.

Seeing your comment here: http://libretro.com/forums/showthread.php?t=2767&p=22201&viewfull=1#post22201, I think I understand your problem:

As already explained, the default resolution for Genesis is 320x224 , NOT 320x240 so if you upscale it in retroarch to 1280x960, there is no way you can have a fullscreen image WITH INTEGER SCALING.

1. Picodrive forces the parameter info->geometry.base_height to 240 lines and never changes it although the image being sent to retroarch for display is only 224 lines.

I am not sure how retroarch internally deals with "geometry" size (whatever that means) and rendered image size (passed to retroarch through video_cb) when they do not match but since you say Picodrive is fullscreen with integer scaling ON, this means it first upscales the rendered image to the defined "geometry" width/height THEN only it applies integer scaling up to your output resolution.

This is NOT integer scaling anymore though because it's still 224 lines upscaled to 240 (then eventually multiplied to 480, 720, etc) and you will got scaling artefacts unless filtering is applied somewhere.

2. Genesis Plus GX correctly updates info->geometry.base_height using RETRO_ENVIRONMENT_SET_GEOMETRY callback to match the actual image height

Default image height being 224 lines when borders are not emulated, rendered image is therefore upscaled vertically to 448, 672, 896, etc... unless you disable integer scaling, leaving blank lines in your output window.

Even if you enable top/bottom borders in core settings to get a 320x240 image then try to make Retroarch "crop" the extra blank lines to get fullscreen image, it will still require non-integer scaling because 960 is NOT a multiple of 224.

I hope this makes it clearer to you as to why it's not a core "issue" but the way Retroarch deals with image upscaling (as much as I understand it myself , but it seems nobody really knows anymore how these stuff exactly works or at least can explain it clearly ?).

If you want a fullscreen image with no borders (although these borders exist on the real thing and could be partially or even fully visible on some TVs), you need to use a resolution that is a multiple of 224 vertically (if that exists) or you have to disable integer scaling.

What Picodrive is doing is a hack that forces scaling of the original image to 320x240 regardless of his original size, which is not correct and force non-integer scaling even when it is disabled in retroarch options. It might work for you in specific case but it should be exactly the same as Genesis Plus with integer scaling disabled and output filtering.

from genesis-plus-gx.

Okay, this makes a a lot of sense, thank you for taking the time to explain it to me.

I guess the borders were always cropped off on a CRT which is why I didn't think they were part of the image, and I've always seen emulators do the same thing, but this was probably on CRT monitors.

One thing which still confuses me though is that I don't see any scaling artifacts present on picodrive with integer scale on at full screen with a resolution of 640x480. I don't understand how that's the case if it's starting at 224. I guess I'm just not seeing the artifacts because of the low resolution? I do notice scaling artifacts on all resolutions above 640x480.

I think the solution here is to set a custom resolution in RA like you suggest. In theory, this shouldn't be any worse, in terms of scaling artifacts, than selecting one of the standard resolutions (640x480, 960x720, etc).

This is a front end issue. There should be an option that both crops the borders and simultaneously corrects the resolution so that the image appears as it would have on a CRT. One of the things hurting the user experience is all the fussing one has to do with resolutions and video settings. But, that's not your concern, I'm just going on a tangent, now. Thanks for your reply.

from genesis-plus-gx.

One thing which still confuses me though is that I don't see any scaling artifacts present on picodrive with integer scale on at full screen with a resolution of 640x480. I don't understand how that's the case if it's starting at 224. I guess I'm just not seeing the artifacts because of the low resolution? I do notice scaling artifacts on all resolutions above 640x480.

Probably yes. There is also likely some filtering applied when the rendered image height (224 lines) is first upscaled to what retroarch thinks is the "nominal" video height (240 lines, as configured by the core), which is probably an independent process from the upscaling to your selected screen resolution on which integer-scaling option is applied.

One of the things hurting the user experience is all the fussing one has to do with resolutions and video settings

To be fair, this is still very unclear to me how retroarch exactly works regarding screen output and I never really got someone able to explain me clearly how "nominal" video height/width is used VS image buffer height/width returned by the core , how it deals with the desired aspect ratio to upscale horizontally / vertically (especially when pixels on emulated consoles or even some target platforms are not "square" like typical computer or LCD screen pixels), where and when options like "integer scaling" or "crop overscan" are applied, etc...

This makes dealing with this kind of issue kinda confusing and frustrating, not only for users but core maintainers as well :-/

from genesis-plus-gx.

Crop overscan is a deprecated option in RetroArch that is used by the core (with RETRO_ENVIRONMENT_GET_OVERSCAN, which is considered obsolete: libretro-mirrors/libretro-arb#9) to determine whether to show or hide overscan.

Most cores are now just using core options to determine overscan settings, including Genesis Plus GX, since this allows more flexibility and allows the change to be made immediately with RETRO_ENVIRONMENT_SET_GEOMETRY.

I don't think there's any issues with Genesis Plus GX overscan core option implementation, nor with base_width/base_height reporting. There is an issue in RetroArch with the window size not updating when SET_GEOMETRY happens in a core, but it works fine in fullscreen, and toggling back to windowed mode updates the window size.

from genesis-plus-gx.

Yeah crop overscan is mostly deprecated, just not officially.
We're (unoficially) trying to move away from that.

from genesis-plus-gx.