Raspberry Pi friendly CRT shader

RetroArch Additions Shaders
#81

Yes. You should get even scanlines when using 4x integer scaling. If you’re not, that’s puzzling and trying to figure out what is going on there before looking at non-integer scaling makes sense.

Also dave, seeings you have done such an awesome job getting this running on a RPi, and chance of give a handheld shader a go for systems like the Gameboy, Gameboy Advance, Lynx, PSP etc?

I never used handheld gaming devices so I don’t have any nostalgia for them nor any idea how they are supposed to look so it’s unlikely I’d investigate that. Maybe someone could try running the existing shaders through the GLSL optimizer dankcushions mentioned.

#82

Regarding integer scaling, how do you enable x5 scaling, as this seem to work well and only cut off 3% of pixel rows, apparently this one option the Nes Mini will use?

#83

I think the only way to do it in RetroArch is by using a custom viewport. Disable crop overscan and set it to 1600x1200 if you want 4:3 or ~1371x1200 if you want 8:7 PAR.

#84

And this is with Integer scaler enabled?, as i have changed custom view point width and height but it doesnt make the screen larger?

#85

Hi Dave, this shader works really great, thanks! Can you tell me how you worked on it ? Do you have a setup where you can live test your shader on the Pi while writing it ? I would like to learn by hacking around some of the shaders that don’t work on the Raspberry Pi but i don’t know what environment to use.

#86

[QUOTE=Dinofly;46210]Hi Dave, this shader works really great, thanks! Can you tell me how you worked on it ? Do you have a setup where you can live test your shader on the Pi while writing it ? I would like to learn by hacking around some of the shaders that don’t work on the Raspberry Pi but i don’t know what environment to use.[/QUOTE] I develop shaders on a PC running Linux rather than on a Pi. I only use a Pi for performance testing. I have a Qt application I’ve knocked together to make editing shaders easier but the only thing it really provides that Themaister’s RetroArch GLSL shader viewer doesn’t is the ability to select output image size by common screen sizes (so you can easily test non-integer scaling). If you use the GLSL shader viewer, you’ll have to add the following line at the start of every shader because WebGL has different defaults to regular OpenGL ES:

precision highp float;

For performance testing I do the following:

In Retroarch, turn on logging. It will print out either the frames per second if you have threaded video off or the number of frames displayed and skipped if it’s on. These can be used to judge performance. It is very useful to ssh from a PC into a command line on the Pi and run Retroarch from there. Once Retroarch is running it takes input from the Pi’s keyboard but the ssh session shows the debug output from Retroarch whilst it’s running.

I also run the 240p test suite’s drop shadow test. This is an easy test for dropped frames.

If you are developing shaders for the Pi, it’s important to note that the tile based GPUs such as the Pi’s take a massive performance hit with multipass shaders. On the Pi this means multiple passes are out. You might be able to merge multiple passes into one shader but this is likely to have other performance implications. I’d advise sticking to single pass shaders.

#87

Thanks a lot for you answer ! I’ll try to learn about GLSL and hopefully i’ll be able to fix some non working shaders for the Pi. For now i try to understand what each pass of the handheld/console-border/dmg-2x.glslp preset does. Applying only the first one gives me a blue screen, even on my Mac. I have to apply at least 5 pass to get something. This makes me wonder how an actual image can be retrieved from the 5th pass if it disappeared in the first one. But i’m off-topic, maybe we can discuss shader development somewhere else :slight_smile:

#88

[QUOTE=Dinofly;46326]Thanks a lot for you answer ! I’ll try to learn about GLSL and hopefully i’ll be able to fix some non working shaders for the Pi. For now i try to understand what each pass of the handheld/console-border/dmg-2x.glslp preset does. Applying only the first one gives me a blue screen, even on my Mac. I have to apply at least 5 pass to get something. This makes me wonder how an actual image can be retrieved from the 5th pass if it disappeared in the first one. But i’m off-topic, maybe we can discuss shader development somewhere else :)[/QUOTE]

Understanding shaders that have been autoconverted from cg can be difficult because the outputed code obscures what was intended and you end up with lot of variables called things like _TMP57 or _a0019. It can help to look at the original cg versions.

There’s no way a Pi is going to be able to run a six pass shader at a reasonable speed even if you can get it to work. See post #12 for an explanation. Stick to single pass shaders until you have a good understanding of what is going on. Even when you do understand multiple passes, to get them running reasonably on a Pi you’ll have to convert them to a single pass.

#89

for anyone interested, i’ve created a set of .cfg overrides that choose the crt-pi-vertical.glslp variant for vertical games in mame2003. see here: https://retropie.org.uk/forum/topic/4046/crt-pi-shader-users-automatic-usage-of-crt-pi-vertical-in-vertical-games-in-lr-mame2003

the locations used are for retropie, so everyone else should put them in /your-config-dir/MAME 2003/

#90

Hi! thanks for this great shaders.

In Raspberry Pi’s Lakka version, where do I need to save the shader files and how can I enable them? Thank you!

#91

You should already have them. Just go into a game and then go back into the menu and look for ‘shaders’ at the bottom of the ‘quick menu’. Once there, go to ‘load shader preset’ and then navigate to the ‘crt’ directory. You’ll see a bunch of *glslp files, and crt-pi.glslp should be one of them.

#92

Hi Hunterk, thanks for your prompt reply. You are right, I could find it and it works great!

Coming from the 8-Bit era, this is the way I want too see the screen :slight_smile: Thanks again! Juan

#93

HI ! I have a question for the crt-pi author :slight_smile: Although this shader was meant for a low-end machine, it’s still my favorite CRT shader, even for use with a regular PC. Is it possible to make a slightly heavier but improved version that would automatically rotate the mask for vertical games, and possibly work better with non integer scales ? I guess both require more GPU power. Would be the perfect CRT shader for me :slight_smile: Or maybe there is already something equivalent, but I don’t really like the other CRT shaders, for some reasons I cannot define… Or maybe I didn’t search properly :slight_smile:

#94

[QUOTE=bidinou;49847]HI ! I have a question for the crt-pi author :slight_smile: Although this shader was meant for a low-end machine, it’s still my favorite CRT shader, even for use with a regular PC. Is it possible to make a slightly heavier but improved version that would automatically rotate the mask for vertical games, and possibly work better with non integer scales ? I guess both require more GPU power. Would be the perfect CRT shader for me :)[/quote] The reasons for not having an auto-rotating version were covered when we first discovered the issue with vertical games. You could always write your own, the information needed is in the original discussion on page 4 of this thread. dankcussions has also produced a set of game specific configs for MAME ganes that need the vertical shader, perhaps you could use those instead.

Improving the look with non integer scales, we are basically talking scanlines here, will take a LOT more GPU power. Well over half the effort in producing crt-pi was spent trying to produce good looking and fast scanlines. Adding more calculations will particularly affect performance because multisampling, which you need to make it look good, means the calculations get done multiple times.

Or maybe there is already something equivalent, but I don’t really like the other CRT shaders, for some reasons I cannot define… Or maybe I didn’t search properly :slight_smile:

I used crt-geom as the initial target for what I wanted crt-pi to look like, have a look at that.

#95

Hi Dave ! Thanks for your kind reply.

Okay, I understand. crt-geom (combined with xbr level 2) is apparently too much for my GPU when using double buffering instead of triple buffering, which is important to me. But I guess it doesn’t play along with non integer scales properly anyway !

Meanwhile, I’m quite happy with the result of xbr + crt-pi. It’s the first time I feel I can play with no eyestrain. And 320x240 games look stellar again in 2016, what a relief :slight_smile: I will try tweaking the shader for vertical games and if I cannot reach 60 FPS I’ll add specific config files :slight_smile:

Thanks again !

Edit : after tweaking for a few more hours (going to bed !!), I settled with the xbr level 2 + crt-lotte combination, with non integer scaling, there is no scanlines related artefact. Actually, I love it ; I hadn’t realized I had to set a scale value to make it look OK. A value of 3 gives a great result (but requires triple buffering), while a value of 2 gives a little blurry picture. It looks super gorgeous to me, even on a big screen. And I’ve been using emulators for 20 years. (oh man) As for vertical games, I gave up scanlines and only use xbr.

Edit : as I realize I mentioned it several times in several places, I created a distinct thread about my performance issue : http://libretro.com/forums/showthread.php?t=7372 ; sorry.

#96

EDIT : forget my question ! “save game overrides” from the main Retroarch menu does work. Pfew :slight_smile: The path is : ~/.config/retroarch/config/FB Alpha/game.cfg

In retropie I remember override .cfg files could be put in the same roms directory. Will see if I can tweak the settings because ~/.config/retroarch needs root access and is not accessible from samba etc. Obviously it’s just a dumb setting so I shut up now :wink:

#97

Is it possible to make this Shader work on Ouya (Tegra3)? I’m using it on my raspberry pi already and really love it. It just looks perfect for my taste. Unfortunately it doesnt work, when i select it on my OUYA.

#98

We would need a log to know what’s actually causing the issue. On Android, you need to either use a logcat app (I’ve had good luck with the free .logcat) or through adb logcat debugging with an attached PC.

#99

Unfortunately i have no access via PC as i dont have a micro usb cable available. tried some logcat apps, this is all i got:

http://pastebin.com/yPVaFfFt

After selecting the crt-pi shader it seems as it doenst load anything. missing files? wrong paths?

i just made a small video: https://www.dropbox.com/s/dvtevdg74gg20cl/Video%2030.10.16%2C%2016%2025%2020.mov?dl=0

most other shaders load properly.

#100

That’s just what it does when a shader fails to compile. That log didn’t contain any RetroArch info, unfortunately.