New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.

[ghogan42]

@caver01 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

Thanks for the tip. I was playing with that number and saw no difference. Can you tell me what triggers retroarch to notice the new values? Do I need to switch the shader to something and then back? Enable/disable shaders? Restart the Pi? I was editing the file over the network, making changes, saving, and launching a game with no changes. Exit game, edit file, save, relaunch. Clearly, this was not enough.
Thanks! The curvature looks great and I don't see any moire patterns on my initial tests so far. I don't know how you managed to pull that off!

Either of the following should work to get your new settings:

1. Use "Load Shader Preset"in the GUI and reload the preset file. That's the GLSLP file. Not the GLSL file
2. Select a different shader in the GUI. Then select "Apply Settings". Then select the zfast_crt_curvature.glsl shader. Then select "Apply Settings" again.

The problem is that RetroArch likes to save it's own "glslp" files when you save settings and it writes the current parameter settings to those files. At that point retroarch doesn't even look in the glsl file anymore for the default settings because it's loading the ones it saved. And you won't see any indication in the UI that it's doing this either.

So if reloading the shader doesn't fix things, then you kind of have to hunt for rogue glslp files in the filesystem. You can probably wipe out any
"retroarch.glslp" that you find in subfolders of \RETROPIE\configs\all and any system specific ".glslp" files too. You'll only lose your saved shader settings if you do this and you should be back to a clean slate.

As for moire, we're honestly just kind of lucky. The scanline profile is computed with soft transition. And the pixels are not sharp in the y direction (we use something like this: https://www.shadertoy.com/view/XsfGDn) and the curvature is not as prone to moire as proper/correct barrel distortion would be. So you see very little moire at 1080p. If you drop to 720p you get some though. But I'm pretty happy with the result as far as moire goes, for sure.

@coldnpale said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

Hey everyone,
thumbs up for continuously improving shaders!
I just found out about your new shaders and wanted to ask, by using your shaders will I gain something as compared to the crt-pi shader? Better speed or compatibility with 1080p? On the other hand, do your shaders also trade something in return for the gains?
At the moment I am using crt-pi on a 1080p screen resolution. Most of my games seem to run fullspeed except for some psx games.
Thanks a lot and sorry if this simple question got already answered somewhere that I missed (I tend to get lost when discussions get too technical).

Hi, the reason these shaders exist is 100% because I started playing castlevania:sotn for the psx and got sound skipping in certain rooms at 1080p when it dropped below 60fps. So I wrote this shader aiming for 60fps at 1920x1080 (games stretched to the full 16x9 res) so that when I set it back to 4x3 (so the game is now actually 1440x1080 pixels) I would be completely free of slowdowns because of the extra headroom my shader has.

So the the punchline is: the standard versions of my shader is over 60fps at 1440x1080 so that psx should be at full speed (or at least it's not the shader's fault).
The curvature version is slower though. And is borderline 60fps at 1440x1080. But I can't do better at the moment. So it is what it is. Some people wanted it though.

[caver01]

@ghogan42 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

you kind of have to hunt for rogue glslp files in the filesystem.

Ok, a-hunting I will go. I am trying to do this WITHOUT using the RGUI. I don't really have an easy way to access it from my arcade cabinet build (hotkeys disabled, dedicated exit button, etc.).

[ghogan42]

@caver01 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

Ok, a-hunting I will go. I am trying to do this WITHOUT using the RGUI. I don't really have an easy way to access it from my arcade cabinet build (hotkeys disabled, dedicated exit button, etc.).

Oh I see. I guess a more foolproof way to do it would be to make a copy of the preset file (the glslp) with a different name. Then if you load that new preset retroarch will be forced to load your new settings because it will think it's looking at a new shader. But you still need to be able to load the new preset and not the old one. So if you're doing everything over the network you still could end up having to delete old glslp files or looking in the retroarch.cfg or other core .cfg to make sure it loads the preset you want it to. Retroarch config is little annoying once you've got a bunch of different configuration files around and you can't tell which one it's using!

Goof luck!

[dankcushions]

@ghogan42 would it be possible for you to add these to the retropie shader repository on github? https://github.com/RetroPie/common-shaders/tree/rpi (rpi branch)

that way, it will be included by default in retropie installations, and we can potentially start using them in the docs and scripts. if you want, i can add it for you, or talk you through adding them if you're new to git!

[ghogan42]

@dankcushions said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

@ghogan42 would it be possible for you to add these to the retropie shader repository on github? https://github.com/RetroPie/common-shaders/tree/rpi (rpi branch)
that way, it will be included by default in retropie installations, and we can potentially start using them in the docs and scripts. if you want, i can add it for you, or talk you through adding them if you're new to git!

Sure. I looked at some instructions for git that covered forking/committing changes/filing pull requests and it seemed reasonable. So I can give it a try on Friday probably. I need to make a couple of changes to the shaders first anyway to clean up a couple of things.

Is there some kind of preferred license that you guys prefer? I don't really care so if you wanted bsd or something instead of gpl then I could do that. Just whatever is convenient for you. Or if there are any project guidelines that I'd need to follow for the code. Although it seems like shader code is like the wild west as far as coding standards because so many shaders end up in every emulator under the sun.

[dankcushions]

@ghogan42 i think it's all up to you! retropie-setup script license is here: https://github.com/RetroPie/RetroPie-Setup/blob/master/LICENSE.md (GPL i guess?)

the crt-pi license is GPL: https://github.com/RetroPie/common-shaders/blob/rpi/shaders/crt-pi.glsl

GPL would seem a safe bet.

[AndrewH]

Hi, is there a 'vertical' version of the CRT shader, as there is for the current default crt-pi shader?

I've read through the thread, but don't see any prior mention or discussion.

[ghogan42]

@andrewh said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

Hi, is there a 'vertical' version of the CRT shader, as there is for the current default crt-pi shader?
I've read through the thread, but don't see any prior mention or discussion.

There isn't at the moment, but it will take a one line change to fix the aperture mask for vertical games. If you turn the mask down in the settings you get this:

donpach: https://drive.google.com/open?id=1d9_o940L7KdNpm2k7u22H26sGjLcUkYf

which seems pretty okay. But I'll make vertical versions of the standard and curved versions with fixed masks before I do the pull request to the retropie git repository.

[Rion]

@ghogan42 Sweet!

[ghogan42]

@dankcushions said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

@ghogan42 i think it's all up to you! retropie-setup script license is here: https://github.com/RetroPie/RetroPie-Setup/blob/master/LICENSE.md (GPL i guess?)
the crt-pi license is GPL: https://github.com/RetroPie/common-shaders/blob/rpi/shaders/crt-pi.glsl
GPL would seem a safe bet.

Did the thing. I suppose we're now to the point where I'm told just how badly I screwed up the pull request. But hopefully it's not too bad. Anyway, I guess I have a branch on my own repository now:

https://github.com/ghogan42/common-shaders/tree/zfast_shaders

Edit: The current version of the shaders are in the RetroPie common-shaders git repository here: https://github.com/RetroPie/common-shaders/tree/rpi

If you update to the newest shaders, you might want to wipe out any of my files from your shader directories. I made a new LUT texture and changed the name so that it's clear from the filename what shader it goes to. Also the defaults for the curvature shader are a little different. And there are now vertical versions of the shaders with correctly rotated aperture masks.

As usual, let me know if there are any problems. I had to move some file locations around to match the retropie standards, so it's possible that something broke that I don't know about.

[MSP430]

Hi ghogan,
nice to see someone still puts effort into shadres for the Pi.
I have several small questions regarding your shaders.

For whom do you recommend the lcd-version and for whom the crt-version?

As far as I understand it is best to multiply the resolution (probably lines as colums are weird) by a whole number (eg: 2, 3, 4) so the original pixels get sized up consistently. Shaders add dark lines (?) so the optimum should be [pixel per original pixel] + number of dark lines per original line. What ist this "magic number" for your shaders? (I hope someone understand this ...)

Is there any reason not to use your RPi3 shaders on a RPi0?

[cosmo0]

@msp430 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

For whom do you recommend the lcd-version and for whom the crt-version?

The LCD versions are for the handheld systems : Game Boy/Color/Advance, PSP, Atari Lynx, Gamegear... it replicates the "pixels are slightly apart" effect on the original hardware.

The CRT versions are for all the systems which were plugged into a CRT TV. It replicates the "TV screen display is a light beam" effect on the original hardware.

As far as I understand it is best to multiply the resolution (probably lines as colums are weird) by a whole number (eg: 2, 3, 4) so the original pixels get sized up consistently. Shaders add dark lines (?) so the optimum should be [pixel per original pixel] + number of dark lines per original line. What ist this "magic number" for your shaders? (I hope someone understand this ...)

The "multiply" thing is to have a pixel-perfect resulting image. You don't count the scanlines for that.

If you want the sizes for each systems, here they are: https://github.com/cosmo0/retropie-overlays/blob/master/RESOLUTIONS.md

Is there any reason not to use your RPi3 shaders on a RPi0?

Yes: it will be too slow. The pi3 is juuuust fast enough, any lower hardware (pi2, pi1, pi0) will have low framerate.

[ghogan42]

Everything @cosmo0 said is right. There is a slight possibility that a rpi2 could run one of these. Maybe only at a lower resolution than 1080P, though.

I did specifically write these so at 1080P you wouldn't have to use integer scaling or manually set the screen sizes. All of the screenshots are at 1080P with standard settings (4:3 aspect or core aspect, integer set to off, etc).

@cosmo0 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

@msp430 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

For whom do you recommend the lcd-version and for whom the crt-version?

The LCD versions are for the handheld systems : Game Boy/Color/Advance, PSP, Atari Lynx, Gamegear... it replicates the "pixels are slightly apart" effect on the original hardware.

The CRT versions are for all the systems which were plugged into a CRT TV. It replicates the "TV screen display is a light beam" effect on the original hardware.

As far as I understand it is best to multiply the resolution (probably lines as colums are weird) by a whole number (eg: 2, 3, 4) so the original pixels get sized up consistently. Shaders add dark lines (?) so the optimum should be [pixel per original pixel] + number of dark lines per original line. What ist this "magic number" for your shaders? (I hope someone understand this ...)

The "multiply" thing is to have a pixel-perfect resulting image. You don't count the scanlines for that.

If you want the sizes for each systems, here they are: https://github.com/cosmo0/retropie-overlays/blob/master/RESOLUTIONS.md

Is there any reason not to use your RPi3 shaders on a RPi0?

Yes: it will be too slow. The pi3 is juuuust fast enough, any lower hardware (pi2, pi1, pi0) will have low framerate.

[MSP430]

@cosmo0 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

Is there any reason not to use your RPi3 shaders on a RPi0?

Yes: it will be too slow. The pi3 is juuuust fast enough, any lower hardware (pi2, pi1, pi0) will have low framerate.

I thought shaders are calculated in the GPU. As all PIs have the same GPU there should be no difference.

[cosmo0]

@msp430 said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

I thought shaders are calculated in the GPU. As all PIs have the same GPU there should be no difference.

I didn't know that...

However, since the RAM bandwidth is shared between the GPU and the CPU, maybe that makes a difference?
If not, then yes, the performance would be identical on all pi. That would be a good news :)

[dankcushions]

pi3 and 0's GPU v3d part is clocked 20% faster than pi2 & 1, and yes the system bandwidth will be better in pi3.

in my experience it's the system bandwidth that's the bottleneck with these kind of shaders. you can find some genesis/nes games that would hammer the bus so much that crt-pi would drop frames.

[Riverstorm]

@dankcushions said in New CRT/LCD shaders for RPI3. They run at 60fps at higher resolutions and are configurable.:

in my experience it's the system bandwidth that's the bottleneck with these kind of shaders

The GPU and frequencies/speeds (gpu_freq & v3d_freq) are identical between the 3 and Zero. The CPU and RAM are quite different.

The thing that pops to mind is v6 vs v8 which is 32 vs. 64-bit architecture. Is any of the code written for 64-bit on the Pi 3? If it's math heavy maybe some calculations fall back to the CPU which is 20% faster by default than the Zero. Quad core vs single if there is any multi-threading and double the RAM which is a shared pool, L2, caching, data-path size, etc.

If they are 32-bit single-threaded apps I would be curious as to the bottleneck but maybe you can't treat one "component" in isolation as the culprit as the processor is a few generations older. It would be great to run these on a Pi Zero.

[Darksavior]

Can anyone share their zfast crt standard settings to make it look like the crt-pi shader?

[NightRune]

@ghogan42 Is it normal to have stuttering in games after adding an overlay on top of your shaders?

• If i just use zfast_crt_standard or zfast_crt_curve Shader everything runs smoothly.

• If i just use the Retrorama overlay (or any other) everything runs smoothly.

• If i run both together i get slowdown in all games (very visible on Sonic 1 where the clouds or palm tress passing by on the background stutter). I still get 60fps but the game is no longer smooth.

Have tried this on 2 different Raspberry Pis with Retropie 4.3.15 @1080p

Any ideas?

[cosmo0]

@NightRune
Yes, overlays + shaders stresses the GPU a lot (a lot more than it should, certainly).
I have seen somewhere (on this forum or at libretro's, I can't remember) a calculation on the GPU load between shaders, overlays, and a combination. Using shaders + overlays multiplies the load, not add.

The only solution I found is to set the resolution to 720p (as seen in my overlay pack, which uses these shaders). Since the games are so low-res anyway, I don't think it changes much.