That’s how interlacing works, odd lines odd frame, even lines even frame, for example. If odd lines are yellow and even lines are black, what else should we get? I checked for some references and gdv interlacing is - interlacing. But it’s a rare case and loading screens or similar with this composition are quite rare.
It’s getting late here though, but you must introduce a new variable, since h_sharp is a parameter.
Hint:
float h_sharp2 = h_sharp;
if (interb1) { h_sharp2 = h_sharp2 / 2.0; }Sure that’s how it works on real CRT.
I think the below points in the direction of what is happening.
The high resolution of interlace is a CRT illusion, a real CRT alternates the odd and even frames with a slight vertical offset for the even frame. So your brain composites these odd and even fields into one image, effectively giving the impression of 30 double height “high resolution” images / frames per second.
The reality is that the CRT is still running at 60 fps progressive (low res 240p) rate, but by this trick of alternating odd and even frames with slight vertical offset for even frames it creates this high res illusion. Which works in the mind because of image retention.
Check this: http://firecontrolman.tpub.com/14102/css/Interlaced-Scan-14.htm
I think we haven’t factored in the emulator author. I think the UAE core with resolution automatic default to double line mode for interlace, which is an artificial composition of [odd+even] frame. It caches two frames at a time (one odd one even), compositing this high resolution [odd+even] image.
So the shader gets fed an already composited image of [odd+even], which is double height. It’s like my example image, the odd and even frames are composited in one frame already. I don’t think this is a rare or extreme case, it’s just the way the emulator author is simulating / handling the interlace case by compositing two frames (one odd, one even) into one high res frame. The difference being that the emulator turns 480i (CRT illusion of odd+even alternating 240p) into hardcore 480p.
Maybe it’s useful to add a mode4 that accounts for this possibility where the shader is being fed the composite of and odd and even frame, like my example image is. As a conclusion I don’t think the example image is a rare case, it’s probably a good example of how the UAE core interlacing mode works.
EDIT: after a bit more thinking it may the that you’re not simulating the vertical offset for the even frames. Please see the link in this post, on real CRT the even frames with even lines have a slight vertical offset. So odd and even are not only alternating, but even frames have this slight vertical offset. If you would simulate this I think the correct effect will appear with your mode 1 for the example image.
In the below link there’s some useful information: it says the vertical offset [for the even fields] is 0.5 lines.
In other words when relating to shader content, this would be half a line offset for the even fields/frames in the shader source image, or equivalently [0.5 * y-scale-factor] vertical offset for the even lines/even frames in the final shader output.
Is this offset for the even frames implemented already in the shader?
My hunch is that when this is implemented you’ll notice a “virtual” resolution increase for interlace mode 1 and 2 in your shader with most interlaced content. I think it will also pass my test image for mode 1: it will no longer be epyleptic seizure inducing black/yellow strobing, but you’ll probably be able to discern the actual back and yellow alternating scanlines with proper interlace shimmering like on real CRT 
Link to article here: In defense of interlaced video
@guest.r How do I disable the artificial brigthness, when I increase the Mask Strength ?
Example (CRT Mask = 5, Mask Strength (0, 5-8) = 1.0, Mask 5-7 Low Strength = 2.0) :
CRT-Geom for comparison (Mask Strength = 1.0) :
I’ll leave it for now, since i’d have to make too major changes to achieve 0.5*line shift. It roots in the resolution and coordinate management which allows only integer line shifting. You can get a fake shift though. Looks very similar.
It’s a test case, more or less… I was writing about this to @rafan, that it causes confusion when shader automatically compensates some situations. I’m about to remove the brightness corrections too with masks. Will release the version today i think.
I tried with additional shifts and it doesn’t look nice. Actually, the interlacing was/is working properly shift-wise in the shader, because the 0.5 line shift is already implemented. But i know what’s buggering some more advanced users, namely the uniformity of the odd or even frames with some patterns. That’s why i added an additional interlacing mode, which handles the mentioned patterns. Looks nice.
Updated: New release version (20.12.2020).
Notable changes:
Download link:
https://mega.nz/file/I1wiwaDZ#XVWPj-ymf6cMRBAorJEmmBILbUFKnUUROOcCBy61Z2w
Thanks for the update, but…
Sorry if this is going to dissapoint, but mode 4 is as buggered as mode 1 and 2 ( 
)
Personally I think you could do away with both mode 1, 2 and 4 as they are all faking it and borking the output.
If you load up for example something like true pinball on PS1, I immediately notice that for mode 1, 2 and 4 the resolution is lost. I put some effort below to hopefully convince you of this. The image shows a new test that has the image broken out in odd and even frame and the composite frame, and output for the shader interlace modes 0 to 4.
For mode 1, 2 and 4 the output of the even and odd frames is plain wrong. I’m also not believing the offset is there for these modes.
I just want to stress I love your shader, but you’re right that the fake interlace is buggering me, Sorry 
. I do much appreciate your effort to try and improve it and listen to us old buggers though 
.
I’ll keep using the 480p mode 3 (it’s fine to use and no output is broken or lost), maybe somewhere down the line you can get this interlace output right.
View/download below image and watch at true size (it’s a 1600x1800 image), only then the lost detail for odd and even lines can be compared for mode 1, 2 and 4.
You should really check some other crt shaders with interlacing before making such claims. The only difference with my implementation is that i added some smoothing, because the transitions would be to sharp otherwise. You can start with crt-easymode halation and crt-royale.
Personally I don’t care for other shaders. I’m disappointed though that your hiding behind other people’s implementations for this,even if they are wrong.
I understand now this interlace thing does not have your real interest. But I would appreciate it if you could download my 1600x1800 image and tell me where I’m wrong on mode 1 and 4.
There’s nothing particularly complicated about interlacing. NTSC bandwidth can push ~240 lines at 60 Hz (non-interlaced/double-strike mode) or ~480 lines at 30 Hz by splitting the 480-line image into 2 sets of ~240 lines (480i/interlaced mode; each set of lines is called a ‘field’). CRTs depend on persistence of vision and phosphor decay to hide the flicker and jitter inherent to interlacing.
Modern displays straight-up can’t show interlaced content, so the 480i image has to be deinterlaced, and there are many ways to do this. Most emulators do the simplest method, called ‘weave’, whereby the individual fields hang around for 2 frames each. This provides a stable 480p image but with horizontal line artifacts called ‘combing’ in places where the 2 sets of fields show different things (e.g., high-motion areas).
The interlacing shader and most of the interlacing-aware CRT shaders simulate interlacing by offsetting their scanlines by 1 pixel each frame, which covers up half of the woven fields and hides the combing artifacts at the cost of interlacing-type flicker (which some monitors really, really don’t like and can cause image persistence)
The next simplest deinterlacing method is called ‘bob’, whereby you line-double each set of fields to 480p and then show each set for one frame. This avoids the combing and results in true 60 fps, but the screen shakes up and down by 1 pixel each frame (this is the 0.5 offset you referred to, but line-doubled to 1 pixel). You can mitigate bob’s shaking by blending the previous frame with the current frame, but this leads to some slight ghosting (this is what the ‘bob-and-ghost’ shader does).
And that’s about it for methods that are reasonably easy to implement in shaders. There are other, more robust methods, like yadif et al. but those require a lot more analysis of previous frames and large numbers of pixels.
That’s lacking some arguments i think. The best argument i can imagine is, if you could write or whatever a working interlacing shader as a proof of concept. My implementation is like from the book, display odd lines in one frame (they are doubled, ofc), next display even lines in next frame, but with an offset of 0.5 doubled line thickness for perseverance of information. As i wrote, i took some liberty to interpolate the lines, because they were too hard for crt standards. There are currently two modes which do proper interlacing, which are 1 and 4. I added 2 more, because they both work with the interlace trigger. And that’s it i guess. I did compare it with other visualizations and it’s using a similar method. But i’m interested why it’s called wrong for sudden.
My interest is that the implementation is meaningful. I’m not showing off interlacing modes for paper writers. 
I asked if you could take a look at my 1600x1800 image and tell me where I was wrong on mode 1 and 4. If you’d have taken a look and at least tried to give me an answer to that specific question it would have helped the debate. Hiding behing other ones implementations and talking about paper writers does not help.
You wonder why I call mode 1 and 4 wrong. If you’d taken a look at my extensive explanation and image you’d already understood. I’ll just repeat the specific section then because you do seem interested.
Just tell me how you think alternating the two below images (which are the odd and even output of your shader for mode 1 and 4, which are alternating)
Will result in this image (the source image, which is shown on a real CRT in all its detail):
It is never going to happen. The result of your alternating images for mode 1 and 4 only results in a epileptic seizure inducing flickering thing that can’t ever resemble the interlaced source image above because the odd and even frame output is borked by the shader.
I’ll just dismiss the paper writers thing. I hope with the above you now understand that mode 1 and 4 are broken.
Interlacing isn’t perfect and you are picking some rare cases where the information loss is more apparent. If you’r display has no issues with extensive flickering, then you can play in super nice smooth experience, providing the source is in higher resolution. I was happy asap with the implementation, unless the content was 30fps. Hence the modes 2 and 3.
Your explanation is lacking some experience with solving the problem on a code level. As i mentioned, i’m happy with the interlacing mode if the content is in higher resolution. You are not happy with a worst scenario test case. I can’t help you here.
Therefore i made the ‘baked’ mode, it’s working very nice, screenshots are possible too. But you actually see less information.
To sum it up, you found some bad scenarios for interlacing i have in my shader and are pushing too hard while disregarding. I can’t help you here, because it’s nice with 99% of the high res retro games, if you’r display hasn’t quirks.
I guess that’s it for today regarding new versions. I actually found a flaw in trinitron mask brightness tuning thanks to @DevilSingh. It’s always compensated with brightboost dark if too bright, to answer the question. 
Updated: New release version (20.12.2020 - r3).
Notable changes:
Download link:
https://mega.nz/file/AwhEhboQ#VX2Nvyi8g8kKTj9HWHQh6jeXvU2FjUgxpTo0prh-eJU
OK I checked a number of interlace shaders from the repository, amongst others the ones you mention above (they both fail the test).
The only interlace shader I encountered that passes the test (with honors) is @hunterk 's “interlacing” shader.
Could you possibly adapt this interlacing shader to the GDV shader? Maybe you find the result good enough also. It’s in the “misc” folder.
https://github.com/libretro/slang-shaders/blob/master/misc/interlacing.slang
Updated: New release version (22.12.2020 - r2.1).
Notable changes:
Download link:
https://mega.nz/file/89ogDSha#x5Bg2rGt5LYgaCmk3h5TVtDrID0lQ2eR29DHzf_Ecqk
Edit: scanline/mask bug fixed, thanks to @Tatsuya79
Using the same preset as before updating my scanlines (type 2) are visibly darker and thicker.
Have some parameters strength changed?
It’s a silly bug. Two variables were still (re)declared inside of an if statement code, and as they don’t count as main-global, they weren’t passing the values further. Should be fixed now.
Yup, all good now. My before/after screenshots are similar. 
Thanks for the update. Very nice update to the interlacing 
I happened to download your 2.0 release of today earlier with the added interlace mode 3 and love it a quite a bit actually, super nice. With the 2.1 release I noticed you removed it in favor of a bit stronger mode 2.
Would really like it if you could bring back that mode 3 from the 2.0 release of today. It’s close to a homerun 
Edit: I’m refering to this one : if (interm == 3.0) { res = res1 * max(ii, 0.5); }
