Homepage › Forums › RetroPie Project › Video Output on RetroPie › New crt-pi shader version
- This topic has 12 replies, 5 voices, and was last updated 8 years, 8 months ago by mydriaze.
-
AuthorPosts
-
01/11/2016 at 16:49 #113677davejParticipant
Following the launch of the Pi Zero, I thought I’d see how fast I could get my Pi friendly CRT shader going on Pis with BCM2835 chips. After some extensive rewriting this is the result.
The good news is, with the default shader config, it will do 1080P@60Hz on a Pi 1/Zero if you overclock it using raspi-config to the Turbo setting.
The bad news is it runs slower on a Pi2! This seems to primarily be down to the slower maximum memory speed of the Pi2. You’ll need to overclock your Pi2 with raspi-config to the Pi2 setting but even with that the default shader settings won’t quite allow 1080P@60Hz. All is not lost though. There is a FAKE_GAMMA setting in the crt-pi.glsl file which uses a faster, but not so accurate, method of implementing gamma correction. If you uncomment out this line (remove the // at the start) it will speed up the shader enough to get 1080P@60Hz. If you’re using a lower resolution, you might not need to do this.
Visually it’s almost identical. Scanlines are a bit more pronounced – but that’s something some people had asked about anyway. I’ve also added options for sharper horizontal filtering and shadow mask type.
There is documentation of all the options in the crt-pi.glsl file, which I’ve reproduced below:
SCANLINES enables scanlines. You’ll almost certainly want to use it with MULTISAMPLE to reduce moire effects. SCANLINE_WEIGHT defines how wide scanlines are (it is an inverse value so a higher number = thinner lines). SCANLINE_GAP_BRIGHTNESS defines how dark the gaps between the scan lines are. Darker gaps between scan lines make moire effects more likely.
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. If you have a Pi2, you’ll need to enable FAKE_GAMMA if you want to get 1080P @ 60Hz.
CURVATURE distorts the screen by CURVATURE_X and CURVATURE_Y. Curvature slows things down a lot.
By default the shader uses linear blending horizontally. If you find this too blurry, enable SHARPER.
BLOOM_FACTOR controls the increase in width for bright scanlines.
MASK_TYPE defines what, if any, shadow mask to use. MASK_BRIGHTNESS defines how much the mask type darkens the screen.
dave j
01/11/2016 at 20:40 #113702FloobMemberThanks very much for the work davej. Looking forward to testing it out.
Would you say this shader is suggested to be used in place of your original whether or not you have a Pi2? Or is the original better in any way for Pi2 users?Thanks again for your time.
01/11/2016 at 22:12 #113711davejParticipant[quote=113702]Thanks very much for the work davej. Looking forward to testing it out.
Would you say this shader is suggested to be used in place of your original whether or not you have a Pi2? Or is the original better in any way for Pi2 users?Thanks again for your time.
[/quote]
The new shader, even with full gamma correction, is faster on all Pi versions and so should be considered a replacement for the original.dave j
01/12/2016 at 20:04 #113823InsecureSpikeParticipantplease forgive my foolishness, how can i use the settings above?
thanks
01/12/2016 at 20:56 #113834FloobMemberPut this in the relevant system based retroarch.cfg
video_shader = /opt/retropie/emulators/retroarch/path.to.shader/crt-pi.glslp video_shader_enable = true
making sure you have copied the files to the folder indicated (and keeping the sub folder as per the zip file).
Or you could use this tool to do it for you. I’ll update it soon to include this updated version01/13/2016 at 00:01 #113849InsecureSpikeParticipantawesome! thank you
01/23/2016 at 16:39 #114857davejParticipantI’ve managed to speed this up again. It will do 1080P@60Hz on a Pi2 with the proper gamma correction as long as the CPUs aren’t doing too much memory access. It’s often OK but if you run anything too taxing it drops about 1 in 1000 frames – you’ll probably have trouble noticing it.
Since it’s limited by the CPUs and the GPU fighting over which can access the memory, if you can reduce CPU usage, it’ll be more likely to succeed. Using faster emulators (e.g. snes9x_next rather than pocketsnes) and changing the audio resampler driver to ‘nearest’ both help. Using simpler games means the emulator has to do less work and helps too! ;)
For other Pis, it might allow emulators to run a little faster but won’t make much difference.
There are no changes to the visible output.
@gizmo98
I’ve posted this to the libretro forum as some people there use Pis and the shader is also useful for people using phones/tablets. They are going to include it in their GLSL shaders pack so, when it appears there, it will make sense to use that version rather than distribute it twice.davej
01/23/2016 at 16:58 #114863gizmo98Participant@davej
Do you have a link to the libretro glsl shader pack? I know the libretro cg shader repo (https://github.com/libretro/common-shaders). But there is no glsl repo on github.We have converted this repo with nvidia cg toolkit and provide these shaders with an own repo (https://github.com/RetroPie/common-shaders).
Just another question. Is this shader compatible with standard OpenGL? Old versions didn’t work.
01/23/2016 at 19:23 #114883davejParticipantYou can find them at: https://buildbot.libretro.com/assets/frontend/shaders_glsl.zip (My shader hasn’t been added yet.)
It should work with standard OpenGL. It certainly works on my Linux PC with AMD’s drivers.
dave j
01/23/2016 at 19:35 #114884gizmo98ParticipantOk. This zip file looks like a converted cg shader repo like our own glsl repo.
It did not work on linux with intel drivers. I will try again.
03/07/2016 at 09:05 #119441mydriazeParticipantHello Davej,
On the RetroPie/common-shaders repo, the file was added on the 13/01. Is this the last version or the one you gave in this thread is the latest one?
03/07/2016 at 12:49 #119453davejParticipant[quote=119441]Hello Davej,
On the RetroPie/common-shaders repo, the file was added on the 13/01. Is this the last version or the one you gave in this thread is the latest one?
[/quote]The most recent version in this thread is the latest one.
dave j
03/07/2016 at 23:15 #119494mydriazeParticipantThanks for your reply. :) Do you know why no one uploaded it in the shaders folder on Github (for the retropie github I mean)
-
AuthorPosts
- The forum ‘Video Output on RetroPie’ is closed to new topics and replies.