Prescaling for sharper hardware scaled/filtered images

RetroArch General
#1

Hello, all.

Thank you for all your hard work on this software which has rekindled my interest in emulation, aside from Dolphin, which I’ve more or less have kept kept track of, over the last few years. I spent quite a few hours over the past several weeks setting things up in my system, creating playlists, restoring old save files, confirming my old roms, adding 3D box art, etc.

One thing I spent quite some time on initially, was configuring the video output. I really like how RA provides a hub to manage the settings across the many emulators… one to rule them all. Working with the various settings, I realized that there is always a trade-off between:

  • image blurriness
  • correct (or at least, original display devices’) aspect ratio
  • pixel shape accuracy (uneven pixels)

Working with the SNES bsnes-accuracy core as an example, it seems there are three main options:

  1. Aspect ratio different from the originally intended 4:3 (old TV’s) but with a sharp image and evenly sized pixels

    • aspect ratio: 8:7 (PAR)
    • force integer pixel scaling
    • disable hardware filtering This setup produces a sharp image with consistent pixel shapes but does not fill the screen vertically and the image is laterally compressed compared to the original console’s 4:3 ratio as played on old CRT TV’s.

  2. 4:3 aspect ratio with sharp image but uneven pixels

    • aspect ratio: 4:3
    • do not force integer pixel scaling
    • disable hardware filtering This allows for a sharp image at the intended 4:3 aspect ratio but pixel shapes are modified to achieve this. This is more obvious on sections where there are diagonal lines of pixels. With this method, some are squares while other rectangles. Also, this method does not fill the screen vertically.

  3. 4:3 aspect ratio and even pixels but blurry image

    • aspect ratio: 4:3
    • do not force integer pixel scaling
    • enable hardware filtering In this case, the intended 4:3 aspect ratio and proper pixel shapes are achieved but at the cost of image sharpness.

Number 3 above is the method I am using right now and the blurriness issue is improved by enabling SuperEagle software filtering. However, the image is still noticeably softer than methods #1 and #2, especially on NES games (Nestopia core). I also tried playing with the multitude of shader options but they all alter the image in some way. The “sharpen” shaders where promising but create a bit of a ghosting effect around objects on screen.

I remember having struggled with this in MAME after I started using a fixed 4:3 output on games with hardware filtering enabled to simplify my arcade setup. However, MAME has a super-handy pre-scaling option that is applied before sending the frame to the video system. When I set this to 4x, the resulting image is very sharp, with even pixels and correct aspect ratio. I assume this is because the gfx card has more pixels to work with when scaling and interpolating the image to non-integer values. The parameter is described here; just search the page for “prescale”.

Also, back when I was using emulators in the Wii, this problem was resolved in SNES9X-GX and FCEU-GX with a similar approach suggested by eke-eke, the author of the Genplus GX port. Essentially, the image is prescaled as in MAME, and then the video hardware does its scaling magic. After this feature was implemented, I was able to get a sharp, 4:3 image with even pixels on those emulators as well.

I really feel that the prescale method would allow users to “have the cake and eat it too”, in the sense that we could have a 4:3 image with evenly proportioned pixels, filling the screen vertically, and without blurriness.

Would it be possible for Retroarch to implement something like cross-core, this or would this have to be done at the individual core level?

PS: After typing all this while waiting to have posting permission, I found this thread that asks a similar question. However, I don’t think the “sharp-bilinear” shader does the same thing I describe above because it still has the uneven pixel problem. Also, the “pixellate” shader creates ghosting around the edges of the sprites, just like the “sharpen” shaders.

Best regards to all.

#2

You are correct on your 3 points but I assure you that sharp-bilinear is doing exactly the prescaling you are describing. There’s one more, also in the ‘retro’ subdirectory, that you can try called aann.cg. It ends up looking very similar to sharp-bilinear and pixellate. With any of those, forcing integer scale will ensure 100% crisp pixels on the vertical axis (at the cost of black letterboxing) and slight blurring/antialiasing on the horizontal axis.

The issue is that, outside of 1:1 PAR + integer scaling, you will always have fractions of pixels and those have to be dealt with, either by rounding (i.e., making uneven pixels) or by blurring. Each of those shaders uses a different strategy to reach that compromise but the end result is the same and unavoidable. This is also an issue with scanlines at non-integer vertical scales.

#3

Thanks for your answer and your help earlier through PM.

I will give those a try, but it sounds like there is always some blurring effect to contend with. Mind you, with the method I’m using now (#3 in my list and “SuperEagle”), I’m getting a decent compromise that I can live with. RA is amazing and I’m not criticizing it maliciously. I just can’t leave the thought that when I do this in MAME and in the aforementioned Wii GX emulators, the result seems achieve everything without compromise. I recognize the challenge of fitting a discrete number of pixels to a different shape screen. I just can’t figure out what is being done in those other emulators that we can’t have in RA.

#4

No problem, I wasn’t trying to jump down your throat :slight_smile:

I don’t think there’s any magic going on with MAME or the Wii GX emulators. There’s only so many ways to skin this particular cat.

If you like SuperEagle, have you tried xBR?

#5

If you are referring to what the images in this post demonstrate, I admit it looks very interesting although quite a departure from the original graphics. I am initially going for somewhat unadulterated graphics, which SuperEagle seems to provide, at lest to my untrained eye. I do need to consider other choices because the original pixelated graphics don’t hold up so well in today’s HD displays. On MAME I’ve been using a combination of HLSL effects to simulate CRT arcade monitors to some extent.

I’ll have to play some more with xBR and other RA shaders.

#6

Pixellate seems the closest to 3x or 4x MAME prescaling to me. I’ve tried the other shaders in the retro directory, but the blur was much more noticeable in those. Pixellate’s blurring to scale up to 1080p is very subtle and I don’t really see it unless I’m really looking for it:

2DP9duN.png1234×1080

#7

I think I’ve found my self a new setup, thanks to Awakened. I don’t know why I had discarded pixellate before or if I had looked at it with the same settings I did last night, but it is a better compromise than HWF and SE to my eyes now. While it is true that there are some artifacts in the image if you look at it very closely, realistically this is not noticeable in-game and at my normal viewing distance. The big benefit is how sharp the image looks, even vs. my former settings. I can force the aspect ratio beyond 1:1 and the pixels appear consistent enough.

I also looked again at sharp-binlinear but try as I might, the pixels are not even when you force the aspect ratio to 4:3, regarding of other settings.

Finally, I played around with other shaders . I can’t say I’m down with the fancy ones that really alter the image, like xbr. It’s a matter of taste, of course, but the end results is too different from the original intent of the image for me. I also looked at the CRT shaders and I’ve set aside crt-easymode or crt-easymode-halation as my prime alternatives if I want that CRT TV look.

Anyway, it looks like I have a winning setup now. Thanks everybody for the tips.

On a side note, I noticed that GLSL versions of the same CG shaders run slower on my system to the point that I can’t run games with the bsnes_accuracy core full speed with most of the GLSL shaders I tried. This is on a relatively decent computer with G3258 @ 4.2GHz and R9-280 that serves me well for PC gaming. Is there some software-level translation going on there that makes GLSL slower?

#8

The GLSL versions are converted by a script that produces really ugly code that may be slightly slower but shouldn’t be wildly so. The more likely culprit is poor OpenGL performance from the AMD driver, which is an ongoing issue with their Windows driver. In general, there’s no reason to use the GLSL version over the Cg versions on platforms where the Cg Toolkit is available.

#9

Awesome. Thanks for the feedback. I was using the CG versions of the scripts after realizing the speed difference, and now I’ve learned why. I do know that Dolphin works quite badly on my system when I use the OGL video backend whereas other people report good results, so your explanation has shed some light on that as well.

#10

CRT shaders don’t look as good on the Accuracy core anyways since it outputs at 480 vertical resolution for all games instead of 240. The CRT shaders are all designed for 240 content. There’s barely any compromise in noticeable accuracy using the Balanced core instead to get 240 output and faster emulation.

#11

Thanks for the tip. I haven’t noticed any performance hiccups with bsnes_accuracy when not using glsl but I will stick with bsnes_balanced to avoid second-guessing myself about whether the shaders are working correctly.

#12

This seems like a decent place to mention that the Pixellate shader is no longer on the libretro repo. This is sad as it’s my favorite. Anyone know what happened? Was it replaced by a similar shader?

#13

It’s still there. All of the ones that accentuate the pixels were moved into the ‘retro’ directory. Here’s the preset the for it:

and here’s the shader itself:

#14

Oh, wow, totally missed that. I thought I did a deep search of the retroarch directory, but apparently not. Thanks!