Please do not post a support request without first reading and following the advice in

Video Smoothing Yay or Nay?

  • 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: - 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.

  • @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.

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

  • @ProxyCell Here is another view on the scanline approach:

    You can see examples here:


    And a short video I made

  • 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.

  • 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.

  • @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.

  • @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.

  • @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.

  • @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. ;)

  • @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!

  • 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 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 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.

  • Global Moderator


    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.

  • @dankcushions said in Video Smoothing Yay or Nay?:


    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 about this to see if there's any hints...

  • Global Moderator

    ~~@Dochartaigh you're on the right track, but you should change these values:

    see here for an explanation:

    IGNORE, see @davej's post below

  • @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. I'll start with the maximum value, then switch to the minimum value if that doesn't work.

  • @dankcushions said in Video Smoothing Yay or Nay?:

    @Dochartaigh you're on the right track, but you should change these values:

    Don't change the #define values - it won't have any effect. They are a) a hang over from before I found that the menu parameters worked with GL shaders and b) what I use during development in my shader test program which doesn't support menu parameters.

    see here for an explanation:

    This post explains the easiest way to change the values.

  • @GreenHawk84 I prefer to have smoothing on large screens as the image appears less pixelated, but on smaller displays I prefer a sharper unfiltered image myself.

  • @davej said in Video Smoothing Yay or Nay?:

    This post explains the easiest way to change the values.

    OK, so in game I hit Select+X for the RetroArch menu (and so it doesn't crash turned OFF threaded video: Settings > Video > Threaded Video > OFF), then went back to Quick Menu > Shaders > Menu Shader Parameters > then held “right” to turn up “Bloom factor” for literally 2 minutes 30 seconds (I kid you not ;) and bumped up Bloom factor from 1.5 to 5 and saw a noticeable difference! (not that I’m going to keep to this way - but at least I know it works)

    So after that change I was able to “Save Shader Preset As” and saved that as “crt-pi-new.glslp”. I then pointed my retroarch.cfg to that new file (instead of the old “crt-pi.glslp”). That file looks like this now:

    shaders = "1"
    shader0 = "/opt/retropie/emulators/retroarch/shader/shaders/crt-pi.glsl"
    filter_linear0 = "true"
    wrap_mode0 = "clamp_to_border"
    mipmap_input0 = "false"
    alias0 = ""
    float_framebuffer0 = "false"
    srgb_framebuffer0 = "false"
    CURVATURE_X = "0.100000"
    CURVATURE_Y = "0.150000"
    MASK_BRIGHTNESS = "0.700000"
    SCANLINE_WEIGHT = "6.000000"
    BLOOM_FACTOR = "5.000000"
    INPUT_GAMMA = "2.400000"
    OUTPUT_GAMMA = "2.200000"

    So if people are like me, and edited their retroarch.cfg to have crt-pi work on everything universally, it's easier to just edit crt-pi.glslp with the lines they want to change, right?

    Thanks again for your help - I'm now off to see how to best tweak these settings to get it to be just a little bit lighter on my monitors.

  • @Dochartaigh said in Video Smoothing Yay or Nay?:

    So if people are like me, and edited their retroarch.cfg to have crt-pi work on everything universally, it's easier to just edit crt-pi.glslp with the lines they want to change, right?

    It might be better to edit your retroarch.cfg to use your crt-pi-new.glslp in case crt-pi.glslp gets overwritten when you do an update.

Log in to reply

Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.