Crt shaders questions

The old cpu filter API was just removed from git yesterday, so if your version was compiled after that, it will indeed be missing. There is a new API that should allow for better, faster filters that feature multithreading and SIMD acceleration but I don’t know if any have been written for the new API yet.

Personally, I prefer shaders to cpu filters for a number of reasons: 1.) most emulators are CPU-bound, so keeping it as free as possible makes sense, 2.) the GPU is generally just idling during emulation, so you may as well use it for something… 3.) shaders are compiled at runtime, which makes them a.) easy to modify by users and b.) portable to other systems (that is, you don’t need to compile separate packages for 32- and 64-bit Linux/Windows/OS X, Android, iOS, PS3, etc.)

no, mine is version 1.0.0.2, it should work then. I’m tried loading it from the cfg file and from a cgp preset.

it would be nice to mix it with a scanline shader, like crt-geom-interlaced-curved.shader for instance.

Cgps won’t do it. You need to add a line, video_filter = /path/to/filter.filter

Yes I did, and got an error dialog about invalid image (…)

Ah, I think you’re running into another limitation of the old CPU filters: they only work with a certain color format, so if you’re on a platform that outputs an incompatible format, they won’t work at all.

bitdepth you mean? or something related to graphics card? I own a quadro, maybe that’s why?

Blargg’s NTSC filters also only work well for the platforms they were designed for. AFAIK he made filters for NES, SNES, Master System, and Genesis. So far most of these have been implemented into libretro cores (NES NTSC on Nestopia, and both Master System and Genesis NTSC on Genesis Plus GX) as core options, which is nice. The glaring exception, however, is the SNES NTSC filter library. None of the Snes9x or bsnes cores have implemented it, which means to use them, you HAVE to specify them in the config file. And now with the API overhaul, there is no longer any way to use them without staying on an older version of RetroArch.

A solution could be to bake them into RetroArch as part of the new API, but the issue with this is that they ONLY work well for SNES. You can use them for NES and the few 256 pixel mode Genesis and PS1 games that exist, but it wouldn’t really be accurate to do so. Ideally, they should have been added to either Snes9x and bsnes, and I am very surprised they have not, considering Snes9x mainline still has them, and bsnes used to as well.

wow that’s great, I didn’t know that since I barely played mega drive. I find RA’s ntsc filters top notch, but their scanlines are subpar when compared to crt-geom or halation. If filters are within Genesis Plus GX core then it can be used for Sega CD as well. And put a crt shader “on top”.

As for bake NTSC filter inside RA, well those pretty much cover what RA can emulate (desktop consoles). NES, Snes, Master System, Genesis, Sega CD and PS1. The only one that I use that stays out is 32x. MAME and FBA don’t need NTSC. Maybe they could bake the current Genesis filter as well so it works on more games (and probably PS1?).

I said it before but I think that building the shading system in a more modular way (basically as retroarch) can optimize coding. Trying to make signal only shaders, and crt only shaders, in a way they can intercommunicate without clashing. We don’t even have shaders for color correction, but there are tons of artistic shaders and more of little to no use. I’m thinking a bit in a way like SweetFX, where you can “more or less” set the guidelines of your shader.