Possible bugs with crop overscan and integer scaling in snes9x next, picodrive

RetroArch General
#1

Not sure if this is the appropriate forum for this. I had another thread going but it kind of fizzled after going OT, so I thought I’d start a new one.

The problem I’m experiencing is that crop overscan’s behavior appears to be reversed in snes9x next- enabling crop overscan reveals black borders on all sides of the screen, while turning it off hides the black borders but results in uneven pixel scaling. Crop overscan turned on should hide the borders while preserving pixel scaling, right?

In Genesis, the problem I’m seeing is that I can’t get even pixel scaling at resolutions higher than 640x480. Anything higher results in scaling problems regardless of if crop overscan is turned on or not (crop overscan doesn’t appear to do anything in picodrive). This hasn’t been a huge deal, since the only reason you would need HD resolution on the raspberry pi is to use shaders, which don’t work very well on the pi anyway. I’ve opted to just use the scanline overlay, so I’m fine with 640x480, but it still seems strange that scaling is not correct at a higher resolution like 960x720.

here are the versions I’m using:

SNES: 1.1 - SNES9X Next v1.52.4

Genesis: 1.1 - PicoDrive 1.91

#2

In testing this, snes9x-next seems to totally ignore my overscan cropping setting and always crops, leaving improper scaling. Non-next snes9x respects the setting, but puts the top and bottom overscan all on the bottom (at least in super mario world) o_O The scaling is correct on it, though, when cropping is disabled.

Picodrive doesn’t have any response to crop overscan (dunno if that’s even something genesis/md had any issues with), but it also draws the window the wrong size as compared with genplusgx. However, I had to toggle fullscreen back and forth with genplusgx once the game had started to get the correct window size and scaling (I recall this being a known issue related to how it initializes games or somesuch).

#3

[QUOTE=hunterk;22052]In testing this, snes9x-next seems to totally ignore my overscan cropping setting and always crops, leaving improper scaling. Non-next snes9x respects the setting, but puts the top and bottom overscan all on the bottom (at least in super mario world) o_O The scaling is correct on it, though, when cropping is disabled.

Picodrive doesn’t have any response to crop overscan (dunno if that’s even something genesis/md had any issues with), but it also draws the window the wrong size as compared with genplusgx. However, I had to toggle fullscreen back and forth with genplusgx once the game had started to get the correct window size and scaling (I recall this being a known issue related to how it initializes games or somesuch).[/QUOTE]

I can get proper scaling with snes9x-next only if I set Retroarch’s render resolution to 960x720 or 640x480, and if I leave crop overscan ON. However, this results in letterboxing, while crop overscan OFF removes the letterboxing but results in uneven scaling no matter what resolution is selected. So there might be more than one issue, here. “On” behavior needs to be swapped with “off” behavior, and there is a scaling problem when overscan is actually cropped.

I can get perfect scaling on picodrive if I set the resolution to 640x480. Anything else results in uneven scaling. This is problematic because many shaders need HD resolution. Is this just how picodrive is written? Not a huge deal for low-performance platforms that likely aren’t using shaders, but I’m curious about this.

#4

Is there a different sub forum I should submit this to? Am I right in thinking that there is a bug in snes-next?

What about picodrive? Is it just not designed to run at higher resolutions? It would be nice to get it to scale correctly at 960x720 so that shaders looked right. Is this a bug or just a limitation of picodrive?

#5

You could open issues about it on the cores’ respective git repos

#6

Well, I did this and the guy for Genesis Plus GX insisted it was a front end (Retroarch) issue, and closed the issue. :-/

On closer inspection, Genesis plus GX looks like it’s drawing the window the wrong size- it’s displaying the full frame but it’s being compressed vertically so that you see the letterboxing that you normally only see with crop overscan ON. Strange.

#7

[QUOTE=Nesguy;22179]Well, I did this and the guy for Genesis Plus GX insisted it was a front end (Retroarch) issue, and closed the issue. :-/

On closer inspection, Genesis plus GX looks like it’s drawing the window the wrong size- it’s displaying the full frame but it’s being compressed vertically so that you see the letterboxing that you normally only see with crop overscan ON. Strange.[/QUOTE] Isn’t setting Borders to Full in the core options the same as crop overscan off? That enables the colored border the Genesis would display in the overscan area.

#8

In PicoDrive, the image fills the 4:3 area without any letterboxing.

In Genesis plus GX, the image is compressed vertically so that it is letterboxed by the same amount as when crop overscan is enabled.

I just don’t understand why the image isn’t vertically scaling to fill the entire area, the way PicoDrive does. Which is correct?

#9

[QUOTE=Nesguy;22190]In PicoDrive, the image fills the 4:3 area without any letterboxing.

In Genesis plus GX, the image is compressed vertically so that it is letterboxed by the same amount as when crop overscan is enabled.

I just don’t understand why the image isn’t vertically scaling to fill the entire area, the way PicoDrive does. Which is correct?[/QUOTE] For me on Windows, both cores fill the entire vertical area with letterboxing on the sides to keep the aspect ratio. That’s with default core options, integer scaling off, crop overscan off and running at 1920x1080.

#10

but then you have scaling artifacts… :frowning:

This is on Linux:

PicoDrive will fill the vertical area with integer scale ON at any integer scale resolution (640X480, 960x720, etc). However, there is a problem with it actually applying integer scale at resolutions above 640x480.

Gen Plus GX ignores crop overscan and instead draws the window at the same size as if crop overscan was enabled- which squishes the image vertically.

:frowning:

#11

Okay, I spoke with a dev, ekeeke, and the answer to all of this is that the black borders are actually a part of the output frame of both the SNES and Genesis. With an analog signal on a CRT TV the picture was stretched vertically so that no borders were visible. The output frame is 320x224 for Genesis and 256x224 for SNES so there’s no way to get it to fit fullscreen with any of the standard resolutions with integer scaling on.

I tried setting a custom resolution with integer scale on, but this still results in scaling artifacts. So the only thing to do is just live with the letterboxing on SNES and Genesis (integer scale should never be off), and accept that this is inevitable when playing these old games on a fixed-pixel display with a digital signal (or emulator which reproduces the full signal).

The “bug” in Picodrive is just a hack that changes the output frame size to 320x240, which causes problems with scaling, particularly at higher resolutions.

Case closed. :slight_smile:

#12

Right, the active area for both is 224 scanlines and then 8 lines of overscan on top and bottom. Those lines are still there on an old TV, you just wouldn’t usually see them because they fall in the potential overscan area, the actual size of which varied from TV to TV.

‘Crop overscan’ is supposed to chop off those 16 overscan lines at the cost of stretching. It seems genplusgx is using a core option instead, which I think is going to be the norm in the future, since ‘crop overscan’ can be different for even 2 games on the same system (e.g., some NES games put garbage in the left or right side overscan, while some put it in the bottom, etc.).

Snes9x-next still has no way to handle showing the full frame, AFAICT, and regular snes9x puts all 16 px at the bottom of the screen, which gives correct scaling but is also wrong. Picodrive seems to be in the same boat as Snes9x-next with no core option and no response to ‘crop overscan,’ so funky scaling is unavoidable there.

With genplusgx, turning on the border core option to top/bottom shows the full frame, but there’s still something weird going on insofar as, in windowed mode with borders off, the scaling is wrong when you start but it gets fixed when you rebuild the context (by toggling fullscreen, for example). That’s unrelated to your issue, though.

#13

I was able to fix the scaling artifacts with custom resolutions by setting retroarch render resolution to “output” and my monitor resolution to native (1080p). Then I followed the normal steps and I I can now get custom resolutions with integer scaling and no artifacts.

#14

So this is why the phosphor mask is all messed up in anything other than 320x240?

bsnes-mercury

Mupen64Plus at 640x480:

They look fine in PS1 games:

#15

Yeah, for bsnes, try using balanced instead of accuracy (if that’s which one you’re using) because accuracy uses the 512-px high-res mode all the time. For mupen, you can try upping the internal resolution as long as the output res is 320x240.

#16

Not sure what you mean by this. The core options only have one setting to change resolution

#17

Ah, I was thinking of PPSSPP, which has them separate. You can achieve the same thing by setting a first shader pass to the stock.cg shader at an absolute scale of 320x240. That’s a bit of work for extensive shaders like crt-royale (is that the one you’re using?), though, since you have to increment the numbering of each of the subsequent passes by 1 in the cgp.

#18

Yea, it’s Royale.

Apparently the phosphor mask resizes itself if I use mask_triad_size_desired_static instead of mask_num_triads_desired_static which is what I was using to take those screenshots.

Now it looks fine:

However I’d like to know more about that stock shader. Does it provide any general benefits? Wouldn’t the pixels be squashed or widen?

#19

Ah, yeah, that looks much better :slight_smile:

It usually looks fine but can sometimes have negative side effects, such as warped pixels caused by non-integer scaling. Dealing with it within the shader is better in this case, since it’s designed with that option. Some of the other CRT shaders aren’t as configurable and so the first scaling pass would be the only way to get the phosphor stuff looking right.