SNES Blargg NTSC Filters

bounty

#1

Various NES and SMD/Genesis libretro cores have Blargg’s NTSC filters incorporated into them, as core options. It is also my understanding that the stand-alone version of bsnes has said filters built-in, as well, though I haven’t used it. Is there a reason why none of the SNES libretro cores have those filters built in? If not, I’d love if they were added and would be happy to make a bounty, though I don’t know how to do that right now.

I am aware that there are shaders available, Themaiser’s I believe, and find them to be good, though I’ve read that their portability comes at the cost of them being less accurate? Either way, they do not work at all on Lakka, on my Raspberry Pi, whereas the built-in filters in ‘Nestopia UE’ and ‘Genesis Plus GX’ work perfectly on my raspberry pi, with no noticeable slow-down even.

I’d be most interested in seeing these filters added to the ‘bsnes’ and ‘Snes9x 2010’ cores since they are what I am using on my PC and Raspberry Pi, respectively, but I would be happy if they were added to as many of the SNES cores as possible, really. What are people’s thoughts on this? Is this possible? Is it a huge amount of work? How much do you think it’s worth, bounty-wise?


#2

You’ll find the Blargg filters for SNES under Video -> Video Filter.


#3

We already have the S/NES NTSC filtering available in the ‘video filters’ in settings > video.

Themaister’s shader is very accurate, modeling all of the signal de/modulation and whatnot. The main drawback is just that it requires a pretty beefy (by embedded standards) GPU.


#4

Thanks for the fast reply, both of you! I didn’t really know about the video filters section. This works on the Raspberry Pi great! I guess I can set a config override so that this doesn’t appear on other cores? However, there doesn’t seem to be any video filters to enable on my PC. Can I download them from somewhere? Also, only the SNES filters appear on my Raspberry Pi but I’m assuming that’s because they’re otherwise available in their respective cores?


#5

Themaister’s shader is very accurate, modeling all of the signal de/modulation and whatnot.

I was under the impression that Blargg’s is more accurate/specific to each individual system. That’s more what I was getting at. Themaister’s shader is great and I would use it on my Raspberry Pi if it worked.


#6

It’s hardcoded for specific resolutions, which is why it’s not one-size-fits-all, not because it’s more accurate. It actually has some drawbacks vs the shader(s), such as color banding caused by some of the optimizations.

The video filters should be packaged with your installation. If you look in your RetroArch folder, under filters > video, do you see a bunch of DLL libraries?


#7

That’s good to know about the shaders, thank you!

The filters directory is entirely empty, even of sub-directories, on my PC. It’s worth noting that I am using Linux.


#8

Ah, ok, on linux it may be a separate package (if it’s packaged at all). How did you install? package manager? universal package? something else?


#9

The problem was with the flatpak package. I just tried the official PPA and the filters were included. Is there somewhere I can report the missing filters in the flatpak package?


#10

Yeah, @RobLoach is the guy who works on the flatpak, IIRC.


#11

Yeah, @RobLoach is the guy who works on the flatpak, IIRC.

Should I just message him, then?

Going back to the original topic of this thread, I think it would still be really cool if some or all of the SNES cores had the filter built in, if for no other reason than consistency with other emulator cores and the convenience of not having to have a config override for SNES cores. Is there a good reason for not doing it for SNES, when it’s already built into NES and SMD/Genesis cores?


#12

Upon further testing, though they appear and can be enabled, the Blargg SNES filters actually appear to not work at all on my PC. I don’t know if this is a Linux issue or perhaps an issue with my Intel graphics drivers/chip but the Blargg filters built into ‘Nestopia UE’ and ‘Genesis Plus GX’ work nicely. Just to be clear, this is using the default settings of the PPA package.

edit* default settings, other than enabling the filter, of course!


#13

Hmmm, okay, I’ll take a look.


#14

Update on that. It DOES appear to work on Genesis Plus GX, though it causes some weird issues, which I expect is normal, considering it’s the wrong system.

edit* to be super clear, this is the SNES Blargg filter enabled through video -> filters in settings, not the ‘Genesis Plus GX’ built-in filter, which always works and doesn’t have issues.

Comparisons below:


#15

Upon further testing, the Blargg SNES filters do not behave properly on the Raspberry Pi, either. You’ll have to forgive me for not noticing sooner. I’m using the Raspberry Pi with a CRT and it is actually hard to tell when the filters are on or off. However, I just tested out Kirby’s Dream Land 3 and, if I go into areas that use hires transparency, such as is used in Sonic The Hedgehog 2 for the waterfalls, the resolution goes funny, exactly like in my above screenshot from ‘Genesis Plus GX’ on my PC. The rest of the game displays normally but it is hard to see if the filter is working or not. On my PC the filter does not appear active at all on Kirby’s Dream Land 3, even in areas with hires transparency.

The SNES Blargg filter behaves identically when using ‘Genesis Plus GX’ and ‘Nestopia UE’ on my Raspberry Pi as it does on my PC, meaning that it works on ‘Genesis Plus GX’, though the horizontal resolution is messed up as expected, and does not work at all on ‘Nestopia UE’.

To clarify, the built-in filters for ‘Genesis Plus GX’ and ‘Nestopia UE’ definitely do work on Raspberry Pi, the waterfalls in Sonic 2 and coins/flagpole in Mario being my go to places to test them. The difference is clear, even on CRT.

Unfortunately, only the “in-core” filters appear in screenshots from my raspberry pi, which otherwise all appear as if no filter is applied, even when the SNES filter appears to be having an affect on my CRT. I’m not sure why that is. Sorry for all my rambling. I hope it’s somewhat coherent!


#16

yeah, the genplusgx thing is to be expected. I assume that, if the CPU filter is doing the same thing on an SNES game, it’s only tuned to exactly 256 px width and can’t handle the high-res 512 px mode, which isn’t good.


#17

Just another reason to use Themaister’s filters/shaders… lol

Perhaps I’m coming at this from the wrong direction. Themaister’s shaders already work nicely on SNES, on PC. Though, actually, the hires transparency isn’t perfect in Kiryby… It’s better in Sonic 2. Maybe the resolution change isn’t happening properly for some reason?

Do you think it would be better to try and get Themaiser’s shaders working on Raspberry Pi, instead? I’d be just as happy to make a bounty for that. Perhaps they could somehow be ported as a video filter or perhaps the shader can be forked for Raspberry Pi. It doesn’t even load right now. I’m wondering if that’s because of Lakka running Retroarch in KMS mode. There’s a good chance it would be horribly lagged if it did work, too, I think. What are your thoughts? I just want nice/accurate NTSC distortion on SNES, on my Raspberry Pi. I’m not too fussed over how that’s achieved, to be honest.


#18

I’m pretty sure the RPi GPU isn’t up to the task, unfortunately. There’s also the issue of the shader uses a special GPU capability that often isn’t available on mobile GL.

Snes9x2010, at least, has had the NTSC filter stripped out of it, and it’s nontrivial to add it back in. We could see about enabling it in snes9x mainline, though.


#19

Snes9x2010 seems to be the default core on Raspberry Pi, on Lakka, right now. Maybe we could start there and see if and how well that works on Raspberry Pi and whether the same issue occurs with hires mode. In an ideal world, I’d like to be able to use Blargg on my PC, as well, without being stuck on Snes9x instead of bsnes.

edit* I think I might have misunderstood what you meant a little. I’d be perfectly happy with Snes9x mainline, instead of Snes9x2010.

edit 2* I can see why Snes9x2010 is the default. Performance for Snes9x mainline is pretty poor on my Raspberry Pi 2. Still, it sounds like it could be a good place to start if it’s easy enough to implement.


#20

What’s the problem on the Flatpak package? Mind making an issue over at https://github.com/flathub/org.libretro.RetroArch ?