Here are some photos, since screenshots aren’t real and because RA crashes whenever I try to take a screenshot 
2 Likes
I admit, I’m more familiar with CRT hardware than the nitty-gritty of shaders. But the waterfall blending in Sonic 1 is mainly a result of the Genesis’ particularly poor composite encoder. In other words, if you play Sonic Jam (Saturn port of Sonic 1) on a composite signal, then you won’t get the blended waterfalls unless it’s an extremely old TV even by CRT standards. So, wouldn’t that mean you couldn’t really have a “one shader fits all” solution? Unless shaders can be programmed to adapt themselves depending on the console.
3 Likes
Correct, a one size fits all solution is impossible.
Each console had it’s own unique composite output, and then each CRT had different comb filters, etc.
@DariusG has at least tackled the console part of the equation. The next step would be emulating the specific characteristics of particular comb filters, but that would be extreme accuracy, and not necessarily the best from the standpoint of pure image quality (it would be cool to see, though).
2 Likes
The Mame HLSL shader (ported to Retroarch) allows this to some degree, though I don’t know if it has quite enough flexibility to cover all the bases. E.g. there’s the “notch filter width” parameter, but nothing about comb filters. I’ve mostly used it to generate artifact colors for computers, others used it for Megadrive/Genesis effects (hence that preset in the NTSC folder).
2 Likes
Do note that there are distinctions among “Shaders”, “Shader Presets” and “Shader Stacks/Pipelines”. Not sure exactly which one you’re referring to.
The current NTSC Adaptive and further evolution of it in CRT-Guest-Advanced-NTSC currently does account for varying console video output scenarios.
It automatically selects 2 phase or 3 phase and merge fields on or off.
Then there’s the interlacing stuff which can also be enabled automagically.
While it may not yet account for all the differences between console output, remember this is an area which is always improving and evolving as more is learned and discovered. We’re seeing some newer developments in @DariusG’s shader at the shader level.
While the current state of development might mean that there’s currently no one-size fits all shader program, you can achieve the same one size fits all setup at the Shader Preset/Front end setup level which would basically do the same thing.
What I mean is that while you can’t yet load one slang shader or preset that does it all, you can have several shader presets which have been tweaked and optimized to take into account these differences we’re speaking about.
Each of these presets can then be saved as Core/Game/Directory presets in RetroArch and this would allow for them to be automatically loaded when you switch systems.
So maybe not one shader or shader stack but definitely one shader preset pack/collection can be designed and adapted to fit all or at least many different scenarios.
This was exactly what I set out to do when creating my “Console Specific” presets. Now every preset I create is console specific. Of course there’s nothing preventing one from using any preset with any Core.
So unless the Saturn Core automatically Triggers 2 phase to be On and Merge Fields to be Off, the rainbow and transparency effects are not going to look like the Sega Genesis Model 1’s poor Composite Video Output.
By the way, you can also accomplish a similar setup using Video Filter presets instead of or in addition to Shaders/Shader Presets.
2 Likes
maybe we need the core to output some info to the shader if the resolution is not enough, info like if it PAL or NTSC (and even SECAM), also it will be better if it tell the sub-type of these like PAL-N and NTSC-J
and console system type (IIRC NES and genesis that has special form of composite signals)
1 Like