Reducing motion blur by forcing interlacing

[mark_k]

Over in this posting I attached an ADF containing two versions of the "Demons Are Forever" demo by D.O.C.. One is the original which uses non-interlaced mode. The other is a modified version which uses interlaced mode (I just set bit 2 in each BPLCON0 write in the copperlist).

That was a proof-of-concept to show that it can be fairly simple to patch a demo/game to force interlace mode. Many modern TVs and video capture devices don't work properly with non-interlaced component video. While the best video quality from a real Amiga could be achieved using an RGB to component video converter, unfortunately that might only work with interlaced modes. And most games and demos don't use interlaced mode.

Anyway. I noticed something about the forced-interlaced version which might be of interest for emulation. When using "double, fields+" line mode, the scrolltext at the bottom is much less blurry on my laptop screen than with the non-interlaced version.

Can anyone else see that effect? It should be more noticeable on LCD screens with a slower response time. The effect is probably similar to black frame insertion but doesn't require a 100Hz monitor. Might it be worth adding a "double, fields+"-like line mode for non-interlaced modes? It could make fast-moving scrollers easier to read.

[Does anyone know of any other demos with fast scrolling text that I could try patching to force interlace too?]

Edit to add: Here's a forced-interlaced patched version of the Jump Jet cracktro by Bamiga Sector One and The Kent Team. This is a good test for scrolling blur. You can independently change the scroll speed and direction of the foreground and background images by using joystick left/right (hold fire to change background speed).

[Toni Wilen]

Do you mean you only need option that forces BPLCON0 LACE bit always on?

[mark_k]

That would probably work fine for most programs. But for some very timing-sensitive demos, having the emulated machine output alternate long/short fields could introduce bugs/glitches.

I was thinking more of a new non-interlaced line mode option which would work like "double, fields+" does for interlaced modes. So as far as the emulated program is concerned nothing would change.

For Amiga non-interlaced frame n:

line 1 -> output line 1
         [output line 2 black]
line 2 -> output line 3
         [output line 4 black]
line 3 -> output line 5
         [output line 6 black]

And for frame n+1:

         [output line 1 black]
line 1 -> output line 2
         [output line 3 black]
line 2 -> output line 4
         [output line 4 black]
line 3 -> output line 6

[Toni Wilen]

Done (without GUI support)

linemode=<value>

static const TCHAR *linemode[] = {
	_T("none"),
	_T("double"), _T("scanlines"), _T("scanlines2p"), _T("scanlines3p"),
	_T("double2"), _T("scanlines2"), _T("scanlines2p2"), _T("scanlines2p3"),
	_T("double3"), _T("scanlines3"), _T("scanlines3p2"), _T("scanlines3p3"),
	0 };

row = none,double,interlaced frames, interlaced frames+
column = normal,non-lace scanlines, non-lace frames, non-lace frames+

(Weird method due to backwards compatibility)

[mark_k]

Thanks a lot, after testing it briefly that feature seems to work fine.

Edit: It seems there's a problem if I change the display buffering (e.g. from triple to no buffering). Then the new non-laced line mode reverts to scanlines (with linemode=scanlines3p3 in the config file). Also the lowest "not really there" line can flash between different colours (see the Demons Are Forever demo, set window height to >=576). Or that line can be brighter than the rest of the screen since it's always non-black. E.g. boot to Workbench 1.3 with the normal blue background. Would it be possible to make that fake line always black?

[mark_k]

A small issue I found testing that winuae.exe (2014-03-12 19:45). With the new non-laced line mode, the problem mentioned here happens again (top half of screen doubled in height for non-15kHz non-interlaced modes). It doesn't happen when I change to another line mode.

[Toni Wilen]

Useless for 99.9% users GUI option added and half-height bug fixed.

[mark_k]

Thanks. And I see there's also an even-more-useless "double, fields" non-laced line mode.

If you set line modes to Double (non-laced) and Double, fields+ (laced), the non-laced line mode is forced to Scanlines.

[mark_k]

I've been trying to figure out the reason for the garbage/flickering bottom line with the "double, fields+" non-laced line mode. At least, there's flickering/garbage with the DOC Demons are Forever demo. Just booting to the Kickstart 1.x insert Workbench screen (white background) the lowest output line is always white instead of alternating black/white/black on successive output frames. [By lowest output line, I mean the bottom single pixel row of the ~576-pixel tall output image, i.e. the lower half of the bottom Amiga scanline; not the bottom whole Amiga scanline.]

You mentioned before that the last non-black scanline output by the Amiga is always colour 0. Could the handling of that behaviour not consider the double,fields+ line mode? That would explain the always-white bottom line at the insert WB screen. The Demons demo probably has colour 0 at bottom of frame changing hence the flickering there.

Am I correct in thinking that this code handles the double, fields+ non-interlaced line mode? In custom.cpp/hsync_handler_post():

} else if (!interlace_seen && doublescan <= 0 && currprefs.gfx_vresolution && currprefs.gfx_pscanlines > 1) {
	lineno *= 2;
	if (timeframes & 1) {
		lineno++;
		nextline_how = currprefs.gfx_pscanlines == 3 ? nln_lower_black_always : nln_lower_black;
	} else {
		nextline_how = currprefs.gfx_pscanlines == 3 ? nln_upper_black_always : nln_upper_black;
	}
} else if ...

Not that I really understand the code much, but I can't see anything obviously amiss there.

[mark_k]

(Not related to the previous post, just some rambling about the goal of reducing motion blur...)

Reducing motion blur doesn't have to be achieved by simulating normal interlacing.

For example, instead of normal interlacing, it would be possible to instead simulate "vertical" interlacing. There alternative pixels on each output scanline would be black. So:
frame n:
[pixel 0] [ black ] [pixel 2] [ black ] [pixel 4] ...
[pixel 0] [ black ] [pixel 2] [ black ] [pixel 4] ...

frame n+1:
[ black ] [pixel 1] [ black ] [pixel 3] [ black ] ...
[ black ] [pixel 1] [ black ] [pixel 3] [ black ] ...

Or you could even simulate "diagonal" interlacing:
frame n:
[pixel 1] [ black ] [pixel 3] [ black ] [pixel 5] ...
[ black ] [pixel 2] [ black ] [pixel 4] [ black ] ...
[pixel 1] [ black ] [pixel 3] [ black ] [pixel 5] ...
[ black ] [pixel 2] [ black ] [pixel 4] [ black ] ...

frame n+1:
[ black ] [pixel 2] [ black ] [pixel 4] [ black ] ...
[pixel 1] [ black ] [pixel 3] [ black ] [pixel 5] ...
[ black ] [pixel 2] [ black ] [pixel 4] [ black ] ...
[pixel 1] [ black ] [pixel 3] [ black ] [pixel 5] ...

There could be a couple of benefits to those ways of doing it. Horizontally-scrolling text looks good with normal horizontal interlacing. Presumably vertically-scrolling graphics (e.g. Pinball Dreams/Fantasies?) would look better with vertical interlacing than horizontal. And maybe with diagonal interlacing, both horizontal and vertical scrolling parts could look okay???

Those methods could be used without doubling the image height, unlike horizontal interlacing. I wonder what the result would look like if the black pixels were, rather than being an Amiga low-res pixel (so e.g. 2 or 4 PC screen pixels), a single PC pixel.

Writing code to specially handle both those cases would probably be too much hassle. But if it were possible to specify different D3D overlay images for alternate frames, that could allow those methods and more to be tested with no other code changes. (Or just a checkbox to invert the mask image on alternate frames.)

[Toni Wilen]

Originally Posted by mark_k

I've been trying to figure out the reason for the garbage/flickering bottom line with the "double, fields+" non-laced line mode.

I am not yet sure where it comes from but it most likely is line that should not be drawn, line that only appears in interlaced modes (last odd line), something gets confused with "fake interlace" in progressive modes and draws line that isn't there.

[Toni Wilen]

Flickering last line should be fixed now. Not 100% sure about the fix..

I don't think I'll bother with extra weird modes so soon

[mark_k]

After writing a little test program that loops writing to COLOR00...

On alternate frames, the last line is either correct (changing colour from left to write as the test program runs), or on frames where it should be all black, it's the same as colour 0 at the right edge of the previous (last real) scanline. So effectively it latches the colour 0 value from the last real scanline.

[Toni Wilen]

winuae.zip updated, at least in my own test program last line now toggles correctly.

[mark_k]

Thanks, the non-laced double, fields+ line mode seems to work fine now.

However the change seems to have introduced a small glitch in the interlaced double, fields (not fields+) line mode. In the screenshot the second-to-bottom line is black; it should be grey.

Edit: Also, when using non-laced double, fields line mode (which should appear identical to the usual double line mode), the bottom output line is all black; it should be colour 0. Compare the two other screenshots.

So in summary, for the double, fields line mode:
- interlaced: second-bottom line is black
- non-interlaced: bottom line is black

[mark_k]

Originally Posted by mark_k

Writing code to specially handle both those cases would probably be too much hassle. But if it were possible to specify different D3D overlay images for alternate frames, that could allow those methods and more to be tested with no other code changes. (Or just a checkbox to invert the mask image on alternate frames.)

I'm thinking of looking into whether writing a shader to experiment with that would be possible.

Does the shader know what frame number is being rendered? Or can it keep variables across frames?
For example I could try the equivalent of this in shader-language (which at this point I know nothing about ):

// Code gets called once per output frame
val++;    // val is static, value remembered from the last frame
if (val & 1)
    {render all odd-numbered pixels on each scanline black}
else
    {render all even-numbered pixels on each scanline black}

[Toni Wilen]

Originally Posted by mark_k

So in summary, for the double, fields line mode:
- interlaced: second-bottom line is black
- non-interlaced: bottom line is black

I can't duplicate. I tried WB with max overscan and last line was always correct.

Some adjustments done, don't know if they help.

Originally Posted by mark_k

IDoes the shader know what frame number is being rendered? Or can it keep variables across frames?

No but global variables should work in shader code.

[mark_k]

Originally Posted by Toni Wilen

I can't duplicate. I tried WB with max overscan and last line was always correct.

Some adjustments done, don't know if they help.

For me, WB overscan setting didn't matter. I could boot a WB disk, change non-laced line mode between double and double, fields and see the lowest line go black when in double, fields mode.

But anyway, whatever you tweaked in the latest winuae.exe (today 15:45) seems to have fixed it, because that problem is gone now.

Edit to add: With the latest winuae.exe the double, fields+ line modes are pretty much perfect. The only thing which could be improved is what happens when the Amiga output changes from interlaced to non-interlaced. But that's so minor it's probably not worth bothering with.

Explanation: Depending on the value of (timeframes & 1), the first non-interlaced Amiga field/frame may be rendered in the same way as the previous (last interlaced) field. So there may be two successive output frames where lines 1, 3, 5, ... are all black (or two with lines 2, 4, 6, ... black). Depending on the display, that could cause a minor brief flash/flicker.

On my laptop screen, I could see the effect by booting an interlaced Workbench, setting background colour to white, then opening a custom screen (also with white background). Flipping from interlaced WB to non-laced custom screen, I can just notice a brief flash some of the time. Other times there is no flash, when the "field order" (for want of a better phrase) matches up.

The fix would be to, if you've just switched from interlaced to non-laced, make the first non-laced output frame render in the opposite way to the previous (final interlaced) field, thus maintaining the odd/even/odd/even black lines cadence.

There is a similar issue for non-laced to interlaced switching, but there the effect is unavoidable since you don't have a choice about how to render each field.