Incorrect 1:1 Pixel Aspect Ratio causes scaling artifacts

[westonlast]

Use RETRO_ENVIRONMENT_SET_GEOMETRY when TurboGrafx-16 changes resolutions. #30

[Tatsuya79]

I can get a good vertical integer display by doing it like:
info->geometry.base_height = setting_last_scanline - setting_initial_scanline + 1;
It's dirty and needs a core restart.

I don't know how to code it in a cleaner way and respect the original ratio but if should be possible to change libretro.cpp only.

As a reference, mednafen stand-alone scales the picture like this in integer scale:
232 lines / 237 lines (can't go over last scanline 239)

[Tatsuya79]

There's probably no perfect solution for the width if pixels aren't square:
http://forum.fobby.net/index.php?t=msg&goto=2554&

[westonlast]

The scanline scaling feature of this core is incorrect in terms of Retroarch. Retroarch is supposed to do the scaling, not the cores, and Retroarch probably does a much better job using better scaling algorithms (and configurable) anyway. The change I made works in both dimensions if the user selects the core's maximum scanline option.

The core outputs to a fixed-dimension, worst-case, maximum-size buffer that the TurboGrafx-16 could ever use. The RETRO_ENVIRONMENT_SET_GEOMETRY API tells Retroarch to adjust it's scaling within the user's display area while applying the user's selected Aspect Ratio. By default, this core's aspect ratio ("Core Provided") is always 4:3, which might not be always correct in the first place.

I prefer playing emulators with 1:1 pixel aspect ratio because then I don't have to worry about the scaling algorithm used by the emulator, which is arbitrary. Crispy 1:1 sample-to-pixel looks great.

In other words, there definitely is a perfect solution. The pixels aren't square if the user chooses something other than a 1:1 aspect ratio in Retroarch's configuration. My change perfectly allows Retroarch to scale the width. The core's scanline scaling was broken before and after my change. It's a separate bug.

[Tatsuya79]

That's perfectly OK as long as everything is optional.
The scanline menu was broken before your commit in the sense that it forces a higher resolution inside a smaller frame buffer.

But prior to your commit, at non integer scale, we could use the scanline menu to remove lines and cut the black bars on top and bottom of the screen. That's not working after it.
Also 352 pixels wide games are off centred (as Ninja Spirit).
512 pixels wide mode gives a black screen (TV Sport Basketball "result board" before a match).

[westonlast]

The scanline scaling had and has incorrect scaling and thus artifacts. It was always broken. Sure, it might be broken differently now, but it's "breaking in the right direction." :P The fixed feature would adjust the values sent to RETRO_ENVIRONMENT_SET_GEOMETRY for line hiding.

Some dimensions don't work? Really? Are we sure that the game itself doesn't output an off-centered image or something? I tested the opening cutscenes from Ys Books I & II which use all sorts of crazy resolutions, and that works. If I had time, I'd check this out sooner, but ha.

[westonlast]

Pull Request fixing scaling of line hiding: #40

[westonlast]

This is still broken. I don't know when Retroarch's Online Updater builds a new core, but the reported Pixel Aspect Ratio is incorrect. The pixels are not square.

[Tatsuya79]

What did you notice?
Everything looks good for me here.

[westonlast]

Just boot up Ys Books I + II, or any game, actually. With the Aspect Ratio set to 1:1 (PAR), even the BIOS screen has non-uniform pixels. Since 1:1 (PAR) is incorrect, all other aspect ratios also have core-caused scaling artifacts, too.

[Tatsuya79]

I don't have Ys but tried Ninja Spirit and PC KID 2, I zoomed in in Photoshop, I see no problem.
Are you sure you didn't forget to put integer scale ON or something else?

[westonlast]

Integer scale is definitely on. I've tried this on two Windows computers and one Linux computer. If you can't see the fat and/or squished square pixels in a static image, observe some motion. The shimmering (caused by the scaling artifacts) is horrible. Make sure you're not using any pixel shaders or scanlines or anything.

[Tatsuya79]

I've tried it once again with PC Genjin 2.
I disabled all shader (I was using nearest before), updated the core, set 1:1(PAR) and integer ON.
I don't see any shimmering. I zoom the snapshot I took in Photoshop and 4x4 pixels everywhere (I'm on 1080p).
I'm on windows 7 x64 Nvidia GPU recent nightly from 2 days ago, core inital/last scanlines were on 3-242.

It was working for you before when we fixed it?

[westonlast]

Oh wow, I'm not sure what exactly I was smoking yesterday. It works fine... I forgot that Integer Scaling isn't saved in the Retroarch configuration, I guess? I'm sorry for wasting your time.

YES! Crispy pixels! Finally! (I hadn't tested the big change until this month.)

[andres-asm]

Integer Scaling does save to the config

[westonlast]

It was probably me getting confused with the Linux build, because the configuration file has to be changed manually. I was seeing ghosts, and frustration never helps. ;)