Video Smoothing Yay or Nay?

dankcushions

@Concat it's called "HW Bilinear Filtering" in the retroarch menu, but video_smooth in the raw retroarch config.

it's a pretty unsophisticated approach to solving the 'jaggie' problem but some like it. personally, I much prefer shaders.

Floob

I agree with dankcushions, I think shaders have a much better result than using the smooth option.
Or if you want something even less CPU intensive you could try overlays that have scanlines built in.

ProxyCell

I'm not criticizing anyone here but is there any other benefit to using these smooters/shaders/overlay-ers and such? The plain-jane look appears to be crisper than the original to me and overall a bit more "clean and clear"

GreenHawk84

@ProxyCell , I agree with "clear" without any video setting enabled but the sprites/details appear a lot more pixelated to me. The smoothing blends the pixels together but at the cost of "clear."

Concat

A lot of retro graphics took advantage of old school displays and cables. The best example of this is dithering. Here's a good article about dithering: http://retro-sanctuary.com/comparisons - differing.html

Raw pixel-perfect video on an LCD does take away some of the retro charm for some people. Shaders can mimick some of it, but there's often a compromise somewhere. FYI, you can update the shader pack in retroarch to get tons more shaders to try. Some practically make the system freeze though because they are so resource intensive.

That said, I really only use shaders for handheld emulators. At least so far. I like to put an overlay on the handheld and fit the screen in the window, then I apply a shader or two to mimick the terrible displays on the era... like the Game Gear :) Gameboy in particular needs a shader imo.

caver01

@ProxyCell Those of us who remember games--especially arcade games--that were played on old CRT displays often want to re-create that look using shaders with scanlines and RGB triads. The effect also applies to TVs from a time long before plasma/LCD HD. The nostagia angle is strong, but there is also the fact that the games themselves were designed for that hardware. The color choices made by the pixel artists who "drew" the sprites often used techniques like dithering described above, or a specific colored pixel in a specific spot to give the appearance of detail, knowing how it would look when blurred onto a low-resolution CRT display. Reproducing that authentic look is what most people who want to use shaders are after.

Speaking for myself, I would use a CRT if not for the fact that they are big and heavy. For me, the convenience of flat screens outweighs my need for authenticity, but the shaders (and to some degree, smoothing) at least brings the image closer to how I remember it for most games.

ProxyCell

@Concat Thanks for that link! I think I understand it a bit better now! I believe I will use it later myself :)

Floob

@ProxyCell Here is another view on the scanline approach:
http://www.tested.com/tech/gaming/456719-best-crt-retro-games/

You can see examples here:

Scanlines

And a short video I made

caver01

That tested article is a nice one with some good images that make the case for some kind of effect to improve the image. Here is another that shows examples of using shaders to approximate NTSC images.

It's important to recognize that it's not all about nostalgia. The original artists had limitations at the time they were designing the graphics, but they knew how to work with what they had to produce nice visuals. Modern displays and resolution scaling actually breaks the original intentions of the design in some cases. Take the use of halftones for transparency, for example. This totally fails unless some kind of shader or smoothing is employed on modern displays.

ProxyCell

Thanks to all of you for the great examples! I was just having trouble seeing any significant difference before. I think I will give some "scanline" shaders a try.

GreenHawk84

@rbaker said in Video Smoothing Yay or Nay?:

@GreenHawk84 I think the pi-CRT horizontal and vertical scan lines are essential. It's so good and authentic with no loss of performance.

@Floob and @dankcushions , I really enjoy pi-CRT for all systems, but it does make it a little darker. Do you use pi-CRT for all systems as well? I tried the SNES scanlines but that one didn't do anything to the picture, I think it's broken.

rbaker

@GreenHawk84 It's crt-pi.gsl in retroarch that I use and everything looks great especially PS1 which looked horrible before. Tekken 3 plays and looks amazing for example and retroarch seems to know when vertical lines are needed.

GreenHawk84

@rbaker , yes that's the one I chose too. My only complaint is that it makes the overall picture a little darker. I wish there was a brighter option but it's still good.

davej

@GreenHawk84 said in Video Smoothing Yay or Nay?:

@rbaker , yes that's the one I chose too. My only complaint is that it makes the overall picture a little darker. I wish there was a brighter option but it's still good.

You can change some of the parameters to make the image brighter but they do have downsides.

Increasing MASK_BRIGHTNESS will make the phosphor mask emulation less obvious. If you're not bothered about phosphor emulation at all you could set MASK_TYPE to 0 which will disable it completely.

SCANLINE_WEIGHT governs how wide the dark lines are so decreasing it will brighten the image but makes scanlines less even.

SCANLINE_GAP_BRIGHNESS controls how bright the dark lines are. Increase this to brighten the image but the scanlines will be less prominent.

Increasing BLOOM_FACTOR will brighten the image at the expense of reducing the already limited bloom effect.

If all that fails, you can always turn the brightness up on your screen. ;)

caver01

@davej I was just reading this thread and thinking, well, there are parameters one could adjust to affect the darker areas, since it's basically these effects that are removing color from the display and darkening the overall image to simulate the CRT. But then I thought I wouldn't know what to suggest changing.

Your CRT shaders are fantastic and the main reason I am using libretro cores. Thanks for optimizing them for the Pi!

Dochartaigh

I too both LOVE the CRT-Pi Shader, but also find it too dark. I don't want to adjust my monitor's brightness as it's perfect on everything I don't use CRT-Pi on, the general RetroPie interface, and things like watching movies on Kodi on the Pi....so I started to mess around with the settings in "crt-pi.glsl" in "opt/retropie/configs/all/retroarch/shaders/shaders"

I'm wondering if someone can help me out here as no value I change seems to do anything.

Up on top of "crt-pi.glsl" there's these values:

#pragma parameter MASK_BRIGHTNESS "Mask brightness" 0.70 0.0 1.0 0.01
#pragma parameter SCANLINE_WEIGHT "Scanline weight" 6.0 0.0 15.0 0.1
#pragma parameter SCANLINE_GAP_BRIGHTNESS "Scanline gap brightness" 0.12 0.0 1.0 0.01
#pragma parameter BLOOM_FACTOR "Bloom factor" 1.5 0.0 5.0 0.01
#pragma parameter INPUT_GAMMA "Input gamma" 2.4 0.0 5.0 0.01
#pragma parameter OUTPUT_GAMMA "Output gamma" 2.2 0.0 5.0 0.01

I'm assuming the values on the right are the choices I can make (for instance changing MASK_BRIGHTNESS from it's stock 0.70 up to 0.0, then the next level of brightness after that is 1.0....then I don't really know what 0.01 is for...).

So anyway, I focused on changing the code for the values below (mostly MASK_BRIGHTNESS, then input and output gamma...but really tried everything I could through trial and error):

#define MASK_BRIGHTNESS 0.70
#define SCANLINE_WEIGHT 6.0
#define SCANLINE_GAP_BRIGHTNESS 0.12
#define BLOOM_FACTOR 1.5
#define INPUT_GAMMA 2.4
#define OUTPUT_GAMMA 2.2

I remove the # symbol on the front when I change a value of course. I've literally tried changing these values about 30 different ways and don't see a difference on-screen whatsoever. I'm rebooting the entire system between changes (or at least restarting EmulationStation - I've tried it both ways). I've tried the number values listed on top, then going crazy and using values like 10 (even went negative!). Still, no visible change.

Any help?

There's also a note in the file which says:

GAMMA enables gamma correction using the values in INPUT_GAMMA and OUTPUT_GAMMA. FAKE_GAMMA causes it to ignore the values in INPUT_GAMMA and OUTPUT_GAMMA and approximate gamma correction in a way which is faster than true gamma whilst still looking better than having none. You must have GAMMA defined to enable FAKE_GAMMA.

...which Gamma is usually overall darkness/lightness, correct? This would be ideal but I don't know how to define Gamma, or which value to change gamma to, then which value to change fake_gamma to in order to pump up the brightness.

dankcushions

@Dochartaigh

I remove the # symbol on the front when I change a value of course.

klaxon :)

the hashtag shouldn't be removed here - it's not representing a comment in GLSL syntax. just change the value. i think you want to lower the SCANLINE_WEIGHT value btw. loop for posts by @davej as he addressed this somewhere.

Dochartaigh

@dankcushions said in Video Smoothing Yay or Nay?:

klaxon

Dammit, I thought you ALWAYS remove the # if you're editing a value in these config files (at least that's what's done on many of the other config files).

I went through Davej's posts and besides his post above talking about what each value is about, I can't find anything on how to actually change values in the crt-pi.glsl file itself.

Anyplace else I should look? I'm currently going through the 13 page topic on libretro.com about this to see if there's any hints...

dankcushions

~~@Dochartaigh you're on the right track, but you should change these values:
https://github.com/RetroPie/common-shaders/blob/rpi/shaders/crt-pi.glsl#L30

see here for an explanation: https://retropie.org.uk/forum/topic/3460/scanlines-shader-opacity/4~~

IGNORE, see @davej's post below

Dochartaigh

@dankcushions

Thanks! That's what I was editing the other night but I removed the # symbol (incorrectly) which is probably why I wasn't seeing any difference on-screen. I'll try it again tonight and report back.

Also, this little nugget of wisdom from those links will help - the numbers to the right of the first few lines of code are: default value, minimum value, maximum value and change amount. ...so I'll start with the maximum value, then switch to the minimum value if that doesn't work.