The Neo Geo AES over composite. I was expecting it to look worse since Neo Geo is really meant for RGB. The AES is different from the other 16-bit consoles because it doesnât derive its master clock from the subcarrier (or vice versa). Instead it has a completely separate master clock and subcarrier oscillator.
The result is a nice blend with no flicker, assuming my derivationâs accurate.
The SNES presets are now in the Libretro shader pack. I will be adding other systems over time, hopefully without needing to change any of the shader code at this point. Before I do that, I think I will make a few generic presets that will be stable for any input size, framerate, so they can be used with cores I havenât made a preset for.
I am considering trimming the number of shaders in the shader pack down because there are a lot of variants for each system. I have already decided to limit consumer presets to one per system per region (usually composite). People could download the full pack themselves.
Be warned that online updater never delete files from userâs storage.
FYI I updated the bezel code which will now account for having a display aspect ratio other than 16:9. It will be in the next update which will be done on a weekly basis, probably Thursday or Friday.
For now RA scaling should be set to 16:9.
I updated the OP as the old one was very out of date. I included information for all the parameters. The debug parameters are not official and may change at any time. I wanted to note some things about performance:
The RGB presets (usually the ones in the professional folder that donât have any suffix, e.g. sfc.slangp) are the fastest performing. In order from fastest to slowest it goes RGB > S-Video > Composite > RF, with each step in performance being approximately exponential.
The bezel glow is a huge performance sink. If you set the Bypass glow setting (at the very bottom of the parameter list) to 0, you can get that performance back. The bezel itself can also be bypassed for further performance benefit as they are large textures.
I did try your snes preset but with PS1 game
seems good but the phosphor decay seems out of control
I know that I need to play with the settings, but normal users usually dont, they may try the shader/preset and if they find that it has some artifacts they will mark it as âbadâ
also, why it has to be a preset for 1080 and another for 2k etc� is it hard to make the shader work in adaptive way with the screen resolution?
I also dont like the idea of having preset per console, but currently that has reasons, and I hope that the Libretro developers will find a solution in the future
The expectation I have for ânormalâ users is to use a matching preset or ask me to make one for them which I will happily do as time allows. Getting the timing parameters right is highly technical, and there isnât really any way to stop things from blowing up if the wrong values are set. If you load up the wrong preset I would actually hope it looks terrible so you know itâs wrong right away (I even considered making the screen magenta, or show warning colors when certain things go outside of the intended range, but for now havenât done that).
The parameters are listed roughly in order of easiest to understand to most advanced/esoteric. But the reason for having parameters instead of putting the info into the shaders and selecting with some kind of lookup function is to at least allow someone who is familiar with the system but not familiar with shader programming to modify that aspect themselves (i.e. emu devs). The parameters are also very important for the development itself. I need to be able to see changes in real time for debugging.
The presets will work for other display resolutions, I test it on 1920x1200 as well. The current presets are optimized for 4K. There have to be separate presets for SDR, WCG, (HDR in the future) because they fundamentally work differently.
Even if we had all the uniforms, we would still need individual presets for RGB, S-Video, Composite, RF because people have different preferences for the signal format. These shaders are different than something like Blarggâs composite shader where the different options are just different mixes of the same noise model. In Scanline Classic, there are different pipelines for each signal type, and there are currently three different composite techniques because there were, in real life, different ways composite video was encoded.
When the generic presets drop this week, you will be able to compare and see how different the shader result is when the system timing is not set correctly.
well, I dont mind having more parameters, itâs on the contrary, I like to have many options, but I talk about a balanced default settings for the end user
itâs fine, but isnât there are way for shaders to know if HDR being used? maybe it also need some uniforms variables?
that fine, but I prefer to have auto option in shader to select between S-Video, Composite, RF based on the console (like if the âcableâ option set to auto and if it NES it will select RF internally and if it Genesis it will select Composite ETCâŚ), and the same Logic can be used to select between CRT mask types
all of that above will be nice in case of generic preset which should make live easier for general users who are not deeply involved in technology, and also for those who want something that works with minimal intervention on their part
I dont mind having individual presets if there are a generic preset, also I like to have presets that represents specific CRT TV sets or CRT Monitors etc⌠and that will be nice for preservation too
Testing RGB mode with Intel Iris Xe Graphics on a laptop at 1920x1200, I can get close to full speed with the Vulkan driver (and the laptop isnât plugged in) and reducing glow diffusion, glow radius. D3D12 performs a bit worse.
In composite mode, a mix of bezel and the composite processing becomes the bottleneck, turning off the bezel can get to 50 fps.
In RF mode, the RF processing becomes the bottleneck.
Will test how going on AC mode improves things.
With AC, I can get very close to full speed with the glowing bezel, but still about 10 fps short.
in that case maybe it worth adding a lite version of upcoming generic preset 
for weak devices
@anikom15, I canât get it to work. Any recommendations or prerequisites? Which directory should I extract this shader preset to?
Are you using the RetroArch downloader? Everything is in bezel: https://github.com/libretro/slang-shaders/tree/master/bezel
Update to 6.1.1 should come to Libretro distribution shortly.
I forgot to mention that the framing has been improved. You can set RAâs aspect ratio to âFullâ for the best framing of the image: the display will be filled without cutting off the viewport. The bezel shader crops and letterboxes as needed to get the best possible view.
If you notice any poor cropping or distortion, please let me know.
Hey, I took your generic preset for a quick spin immediately after loading my 1080p CRT-Royale Preset and the transition between them was relatively smooth, which is a good thing.
Hereâs a comparison at 4K using my 4K CRT-Royale Turbo Duo Smooth Fine Preset and the Scanline Classic Generic preset with no Bezel nor Curvature, set to Aperture Grille Mask at 400TVL. I lowered the Phosphor Mantissa B & G to 30 because I felt it was a bit too much at 100.
CyberLab CRT-Royale preset
CyberLab modified Scanline Classic Generic preset
Thank you! You know, I feel like the phosphor effect was not this strong previously. I donât know whatâs going on 
I will probably fix it internally.
The signal pipeline before CRT simulation is done in a weird resolution. I wonât get into why I do it this way, but I found that I needed to oversample by 2x to get the comb filter and PAL delay filter to work, but these are only used in two shaders. I can probably get a performance benefit by not oversampling the other shaders. I will be experimenting with that. The next release will have significant improvements for RF, but is more demanding. I am hoping that eliminating the oversample for the RF portion can reduce that impact.
I noticed in my shader that normal bilinear texture sampling (texture()) caused artifacts if I didnât oversample significantly. When I look back 227.5 chroma periods for the comb filter, the point I am sampling is often in between samples and so needs to be interpolated. I was able to reduce the oversampling by using better interpolation (a Lanczos kernel). Itâs a tradeoff: the interpolation is more expensive, but I need far fewer samples and that makes the other passes faster.
I got a chance to try your shader again (from slang-shaders rather than your repo).
When I try uhd-4k-sdr/consumer/gen.slangp, I get an error:
[ERROR] [slang]: Unknown semantic found.
[ERROR] [slang]: Failed to reflect SPIR-V. Resource usage is inconsistent with expectations.
I think Iâve seen this error before when I reference a uniform or push constant that isnât defined in the parameters. It looks like the issue might be in bezel-base.slang, but I donât see anything obvious. Iâm using Retroarch 1.19.0 (I know, kind of old) with Vulkan on Linux.
This issue should be fixed in the next update. The Vulkan compiler is more strict than the D3D12 compiler. I switched to doing primary development on Vulkan for this reason, although D3D12 is what I use daily for RA because it seems to be more stable.