Raspberry Pi friendly CRT shader

RetroArch Additions Shaders
#1

I’ve written a CRT shader optimized for Raspberry Pis. The main aim has been to get a shader running at 1080P@60Hz on the Pi’s GPU that still looks reasonably good. Even if you are not using a Raspberry Pi, it might be useful if you are using similarly low end GPUs.

Some of the configuration options can be set using the retroarch frontend, for others, the shader file needs changing.

You will have to overclock your Pi to get 1080P@60Hz and, in the case of Pi2s, change the gamma correction to use a faster but less accurate way of calculating it.

There’s documentation in the crt-pi.glsl file describing the various options, including which overclock settings to use.

Briefly the options include:

[ul]
[li]Scanlines [/li][li]Multisampling [/li][li]Gamma correction [/li][li]Screen curvature [/li][li]Bloom of brighter scan lines [/li][li]Selectable horizontal filtering [/li][li]Selectable shadow mask type [/li][/ul]

Most of the options, when changed from the default, will slow the shader down so that it might no longer achieve 1080P@60Hz. There are some options that let you trade visual quality for speed and you can always display at lower that 1080P.

The shader is in the attached file at the end of the post.

I hope you like it.

dave j

Some example screenshots:

1440×1080
1440×1080
1440×1080

1 Like
#2

This sounds like a godsend, I assume if it can run on a Raspberry Pi then Android tablets shouldn’t have any problems with it? Also have you considered more mask slot options such as CRT Lottes?

#3

That looks good. If you like, I can add it to my glsl-shaders repo, which gets pulled in alongside the auto-converted Cg shaders.

#4

This is fantastic! Runs great on my Sony Xperia Z4 Tablet :smiley:

crt_pi_cut_by_jelbo-d9ooems.jpg1024×687

#5

Anybody have an Nvidia Shield or some other similiar Android gaming box they can test the shader with? (preferably with settings maxed out) . I’ve been looking for a very basic gaming box that is capable of doing a decent CRT shader to go in the living room, so far none fit the bill except building your own hyperspin system on a Windows HTCP and i’d prefer something more basic and lightweight.

#6

[QUOTE=solid12345;33324]This sounds like a godsend, I assume if it can run on a Raspberry Pi then Android tablets shouldn’t have any problems with it? Also have you considered more mask slot options such as CRT Lottes?[/QUOTE] It should run on anything that supports OpenGL ES 2.0 or OpenGL 2.1. I’m actually developing it on a PC and doing performance testing on Pis. I’ve avoided implementing the Lottes shadow mask as doing it properly (with the SRGB bits) will slow the Pi down too much and a simplified version doesn’t look too good. Keep in mind that the purpose of this shader it to work fast and look good on Raspberry Pis. If it works on other things that’s a bonus but my efforts will be focused entirely on Pis.

#7

[QUOTE=hunterk;33327]That looks good. If you like, I can add it to my glsl-shaders repo, which gets pulled in alongside the auto-converted Cg shaders.[/QUOTE] Yes, but best delay a bit. I’ve managed to almost get it running fast enough on Pi2s to not need the gamma correction hack - they are dropping about 1 in 1000 frames at the moment. I’ll post an updated version when I’ve had a chance to do some more performance testing and either get it going a bit faster or come up with some tweaked overclocking recommendations.

#8

Sure. Just let me know when you’re ready :slight_smile:

#9

[QUOTE=solid12345;33349]Anybody have an Nvidia Shield or some other similiar Android gaming box they can test the shader with? (preferably with settings maxed out) . I’ve been looking for a very basic gaming box that is capable of doing a decent CRT shader to go in the living room, so far none fit the bill except building your own hyperspin system on a Windows HTCP and i’d prefer something more basic and lightweight.[/QUOTE] If you’ve got the sort of TV that insists on doing it’s normal video processing on the input signal even if it comes from a computer you might find you get moire artefacts - annoyingly mine does. If you can, I’d advise trying the shader on something else plugged into your TV before splashing out on some new equipment only to find you don’t like the picture.

#10

Here’s the updated version.

Those with Pi2s can help ensure the best performance by doing things that reduce CPU memory accesses such as using a faster emulator (e.g. snes9x_next rather than pocketsnes) and changing the audio resampler driver to ‘nearest’.

dave j

#11

Thanks for the update.

Although it doesn’t have your focus, as you pushed the the Pi(2) to the max with this shader, do you think it would be possible for me to manually add another shader pass that adds a little ‘smear’ to it, like an existing Composite or NTSC shaders, while somewhat maintaining it’s speed edge?

Many existing shaders are too heavy for even recent Android devices, and your shader plays very nice on my tablet/phone and serves as a good basis. Though I love the look of it, a bit of imperfection added to it would make it… perfection :wink:

#12

The reason the mobile GPUs have problems running so many shaders in retroarch is to do with how fast they can access memory. Desktop GPUs, which retroarch shaders have typically been written for, have very fast memory access but, because accessing memory by GPUs is power hungry, mobile GPUs use a different design approach that minimises the amount of memory accesses they have to do to save power. Details of the approach here if you’re interested.

The multiple pass rendering technique that retroarch uses is pretty much the worst case scenario for mobile GPUs because it needs lots of memory accesses.

If you are going to try adding a ‘smear’ pass, make sure you use one that outputs the same resolution as its input (i.e. at the game’s native resolution) and put it before the crt-pi shader. This will minimize the increase in memory accesses and so reduce the amount of slow down.

dave j

#13

Hi everyone !

I love shaders :slight_smile: So much progress was made on the Pi front ; not so long ago, to get a reasonable performance, I had to use Squid’s mame4all and fba ports which only had bilinear filtering (scanlines were broken).

Anyway : my question is : whenever I choose a pixel shader in RetroArch (Lakka / Raspberry Pi 2 but also on my Kubuntu Linux box), the setting is forgotten. Is it possible to set a global pixel shader ? I really spent some time and couldn’t find how to do it. I searched the forum too !

It looks so amazingly better with one. It should be default, as in other distros like Happi Game Center :slight_smile:

Thanks again to everyone !

Edit : I’m not sure I put this message in the right forum. Or maybe I should start a new topic.

#14

@bidinou Probably better as another thread but no biggie. It depends on whether you use per-core configs, overrides or neither. If you use per-core configs, there’s no way to set a global shader as it will load up an entirely new config for each core. If you use overrides (or neither per-core or overrides), just set it in your retroarch.cfg and you should be good to go.

The relevant options from your retroarch.cfg should be: video_shader_enable = “true” video_shader = “/path/to/shader.glsl§”

@dave j I forgot about this entirely but just got it added to my repo. It should start showing up in the online updater very soon.

#15

Thanks for this very performance based shader. I’ve been struggling with finding a suitable shader that looked good on my TV with a lower end laptop hooked up to it and this is the best one for my tastes so far.

#16

HI ! I love this shader. Set it as default under RetroPie (if it’s indeed the one bundled with it – I wonder why they do not choose one as default :slight_smile:

I have just a tiny complaint : it doesn’t seem to behave well with vertical games (strange vertical lines). Or maybe it’s due to my using a 1280x1024 monitor ? (as it’s in a cabinet)

Thanks again :slight_smile: cheers

#17

The monitor resolution is not an issue - I have one the same size.

Can you post a picture of the problem somewhere? Also, I’ve noticed a problem with MASK_TYPE 2, so can you let me know if you are using that.

#18

OK, I’ll do it ASAP. I’m using the pi-crt as it is bundled in the current RetroPie (no tweak). I notice the issue for instance in Cave games with libretro-fba-next. Thanks :slight_smile: I’m remember having a similar issues with a CRT shader for sdlmame on my PC. It was then supplied in two versions : horizontal and vertical, which is not such a problem as MAME can have a distinct config file for vertical games.

#19

Hi ! Here’s an example of the problem on vertical games : http://www.hostingpics.net/viewer.php?id=646097IMG2269.jpg I’m using the defaults, so mask type 2. Using a 1280x1024 screen, latest retroarch, with crt-pi shader :slight_smile:

Sometimes some weird lines can also be visible in horizontal games, but it’s much less obvious.

#20

It looks like a severe version of the banding artefacts you get when you have a resolution that doesn’t match integer scaling and there aren’t enough screen pixels per game scan line to even them out (you really need 4x or more for that to work well). It’s possibly made worse by being vertical as the scan lines line up with the 3 LCD colours of the display rather than crossing them as happens with horizontal screens. Things to try that might help:

Use integer scaling if you can.

Decrease the value of SCANLINE_WEIGHT and/or increase the value of SCANLINE_GAP_BRIGHTNESS. These will reduce the prominence of the scan lines but should reduce the banding.