Suggestion for alternative handling of interlaced frames (WinUAE)

[dlfrsilver]

that's strange i did some tries, but i don't get the combing effect.

[Maren]

Alright, time for take 2

Make sure you're using Opera, Firefox or any other APNG-compliant browser and check the images above. From left to right: bottom field, top field and full frame through the Interlaced Screen Simulator at 50 fields per second (not smooth enough on browsers for sure but should give you a taste)

Now that WinUAE has gained the ability to overlay masks, I wonder if this approach sounds a lil more feasible than it did before.

I have simplified the process (theoretically at least) to allow it to employ certain functionality already available in WinUAE.

Here's the steps:

1. WinUAE detects which field goes where (bottom or top) and that's something it's been doing ok for as long as it's been capable of weaving fields into full frames.

2. WinUAE displays the first field (in this example, bottom field) doubles it's vertical resolution (Line Mode: Double) and places scanlines on the second line from bottom to top.

3. WinUAE displays the second field (in this example, top field) doubles it's vertical resolution (Line Mode: Double) and places scanlines on the first line from bottom to top.

That's pretty much it. Displaying the fields consecutively, doubling there vertical resolution and bobbing scanlines 1 line up and down is all it takes.

The 3 biggest showstoppers that I see right now:

1. I have no idea if WinUAE would be able to place the scanlines correctly as it can't even tell the boundaries of an image to begin with. This could be dealt with (partially) by allowing the user to modify the offset of the scanlines to suit a particular screen.

2. We're talking about bobbing an image 50 times per second! I wonder if a relatively modern system would be able to pull through.

3. Toni's lack of interest in interlacing

Cheers.

[Toni Wilen]

Why? whats the advantage?

There is also big technical problem. Interlace handling is not separate code path, it is impossible to just change interlace without affecting non-lace mode. I don't really want to touch that code, at least not now.

[Maren]

Advantages = no artifacts whatsoever, and, of course, the retro visual authenticity of a properly emulated interlaced screen over an inappropriately de-interlaced screen.

As for the technical reason, I cannot debate, I just don't know that much about the inner works of WinUAE in that regard, but what exactly would have to be changed that's likely to affect non-interlaced modes? WinUAE's perfectly able to display interlaced frames as consecutive fields (Line Mode = normal) EDIT: and double there vertical resolution too, via Direct3D filter.

That's probably a 100% unrelated to what you actually mean by "without affecting non-lace mode" but that's why I'm asking

[Maren]

It's been over a year since the "buffer" problem was discussed (previous page) and today I wonder, did you look into it? I'm not stepping back into that interlaced screen simulation lunacy, but the possibility of a different workaround does still interest me