You may be able to piggyback on ‘absolute’ and just grab the first framebuffer size to feed into the values. It would probably need to be named something other than “original”, since that name is used for a bunch of other stuff, but maybe “native” or whatever else.
To be clear I’m fine with the decovergence @guest.r, my issue is the static/film grain effect rofl.
Also completely understand that not everything can get the same amount of attention, nor does it need too tbh.
A better deconvergence implementation is already under testing. 
Some criticism about film grain sounds reasonable though. Is it too fine or too saturated? Feedback is welcome.
Sweet about the decovergence, tbh I was happy that you resplit the settings for it (horizontal and vertical RGB being separated from each other).
I’ll go test in a couple minutes just to be a precise with my complaints as possible, but from what I remember from testing the grain effect last night is when I got it setup high enough to notice from where I was sitting, it was desaturating/washing things out. (May just be nitpicking, as I actually didn’t get into fine detail testing yet lol.)
there are a few different ways to do grain, RGB vs luma-only, additive vs subtractive vs multiplicative, etc. I’ve personally had the best luck with making tiny offsets to the texcoords at sample time instead because it’s more of a static-y look than film grain-y, and it doesn’t affect any of the colors or black levels / white point / whatever.
New Release Version (20.05.2021-r1):
Notable changes:
- New deconvergence pass implementation, masks are less prone to smear with different offsets.
- Dynamic deconvergence added as suggested by @rafan.
- Warp/curvature function optimization.
- Edit: small bugfix
Download link:
https://mega.nz/file/wxx2wZ4Z#hnF0QXgQMvjcJJLTZtbscoPpQ3WjvpZ6xpn1wVZrBLw
About noise, maybe i should adjust the noise resolution, since it can get quite fine with increased resolution. I guess current noise generating function can be used in many ways, as @hunterk discussed.
I’m liking the dynamic deconvergence, very nice 
There seems to be one issue with the deconvergence however, see below shot in which I used exaggerated setting (only static deconvergence as example) vertical blue at -7 and strength max.
The deconvergence seems only to be applied to lines that have black around them, all vertical white lines remain unaffected by the deconvergence setting.
EDIT: on 100IRE test screen the issue is more clearly seen, settings are for both horizontal and vertical blue deconvergence -7 and strength at max. White square remains unaffected, only border to black shows the deconvergence.
Thanks for the link 
That’s normal as coordinates for separate RGB components pick up ‘maximum’ value while not at edges, and if you combine them you get RGB(1.0, 1.0, 1.0), which means the color white. If you want some sort of scanline color effect, you can tweak the offsets or use ‘Scanline Color Deconvergence’.
Edit: if it’s the other issue about not ‘shadowing’ over black colors, then it can be corrected. The deconvergence implementation as the last pass is pretty much balancing around color vs. mask accuracy.
I was trying to match the convergence from the video of the retrotech guy, as in the caption from below
and thought at first glance that the vertical deconvergence in the shader wasn’t being applied for the vertical white lines, but upon closer inspection that appears to be an optical illusion. When zooming in on the shader ouput (in paint) and making the bright scanlines more defined (scanline shape bright to 1.30-1.50) the deconvergence is there
.
Been playing a bit more with it and dynamic convergence works really nice 
Maybe it would be useful, if possible, to have one configuration option added, that is whether or not the deconvergence is mirrored or not versus the middle of the screen. Currently when you enable dynamic it both creates deconvergence towards the edges but also mirrors deconvergence left/right and top/bottom. It would be useful if the latter could be a separate switch?
New Release Version (20.05.2021-r1):
Notable changes:
- New deconvergence pass implementation, masks are less prone to smear with different offsets.
- Dynamic deconvergence rearranged as suggested by @rafan.
- Two deconvergence modes, one without ‘dark deconvergence’ and one including it.
- Edit: small fix
Download link:
https://mega.nz/file/5sRmATZS#-srK5I1dftB8aPx4O7WGJZwvqxNkCA8nPZREbGYrhP0
I’m overall more pleased how the deconvergence pass is working now, although it might require some adjustments if changing masks. As i already mentioned, it’s not a straightforward implementation, but it works quite nice.
actual CRT owners: spend hours trying to eliminate deconvergence
CRT shader users: spend hours trying to add deconvergence
Shhhh, my sweet summer child, we all be crazy, don’t question just accept. ROFL
I’ve been trying the new deconvergence modes, but I’m not sure what to think as I’m running into some things that you may help with.
One example is that if I only deconvergence red on a single pixel pure red line than some sort of ghost image appears of the red line, whereas with previous versions it would move the entire red line without any ghost image remaining.
My understanding of deconvergence is that for the primary colors the whole beam should move position. With the ghosting in the shader it’s like part of the electrons / beam move while the rest remain in their old place. This is especially happening for decon. strenght < 1.50. For > 1.50 strength some sort of accumulation effect takes place that brightens the whole beam. Both don’t look very good?
It would be nice if you could load up below 256x224 testimage and deconvergence -only- red in the shader for various offsets/strength and see whether the result is what should be expected.
I think with the old deconvergence the red lines would move postion only, without any ghosting or accumulation?
test-image 256x224

red hor. and vert. deconvergence at +7, strength 0.5
red hor. and vert. deconvergence at +7, strength 4.0
Don’t sit on your ears ^^. 
Deconvergence is very easy if you don’t have to mess with mask accuracy. The coordinate shift is authentic, but the image layout is also considered.
‘Old’ mode is still available as negative deconvergence strength, as it has some benefits.
It looks quite nice on the test pattern:
I’m old mate, you have to be really load or i’ll miss these haha 
‘Old’ mode is still available as negative deconvergence strength, as it has some benefits.
I tried negative strength earlier, but then it gives a green ghost image when deconverging only red on a purely red image.
Below is the pure red boundary on the 240p grid test. If I only deconverge red and negative deconvergence strength, then a green ghost image appears? Is that also part of the tradeoff?
Personally I think that’s too much off a tradeoff, as for me it’s too far off what’s happening in a real CRT.
Did the old implementation behave the same? I can’t remember it doing that, but I may have missed it.
You are free not to use it then. Hi-res and fast versions have other implementations of the horizontal deconvergence, maybe you’ll find some peace there.
actual CRT owners: spend hours trying to eliminate deconvergence
CRT shader users: spend hours trying to add deconvergence
Yeah that’s a funny contrast.
The thing is that in real CRT’s there’s no such thing as “perfect” convergence. Even “perfectly” calibrated sets have some deconvergence errors still, mostly found towards the edges I guess.
https://forums.arcade-museum.com/threads/perfect-convergence-is-it-possible.477649/
It’s the minimal deconvergence that’s an integral part of a CRT screen / technology that’s just always there, however good the set may be calibrated, that is useful to simulate with a shader for added authenticity.
Adding deconvergence is not about making the screen more “crappy”, it’s just about getting the best possible representation of a “well calibrated” CRT output trough a shader (read: guest-advanced ), which thus preferably is able to simulate that minimal part of imperfectness of a properly calibrated CRT.
You are free not to use it then. Hi-res and fast versions have other implementations of the horizontal deconvergence, maybe you’ll find some peace there.
tbh I would mostly find peace in a touch of true to life dynamic deconvergence, for the reason mentioned in the reply to nesguy above. For now the green shadowing on red deconvergence in the shader is a bit of a hold back for me to use it in my gameplay setup, but given how good the shader in general mimics CRT output it’s definitely no big thing.
For now the green shadowing on red deconvergence in the shader is a bit of a hold back for me to use it in my gameplay setup, but given how good the shader in general mimics CRT output it’s definitely no big thing.
Please don’t misuse the settings: 
Dunno what’s happening on the other side, but these patterns are quite easily achievable. I tried different combinations and it works quite nice.
Edit: Humbar is on it’s way. 
Is ART
Literally
The emulation of a real screen …is a true art.
"emulate the image of an electronics image " here, in retroarch/libretto forums…
and…not only electronic image to emulate, because somes different CRTs secreens/monitors.
The scence of this plaisure of shaders, is…that. when you play a game… retroarch load a filter ramdonly…predefined inside your favorites. In the true is not only a filter, is their rotation, of your predefined, perfect, choosed filters. ( filter or same filter with different mask or configuration or dynamics)
As when in the old times you play those games, most provably in different screens CRTs monitors, home…saloon arcade places, computers …
Greetings.
All with dynamics. ( right mouse for full screen to see the images big)












