Modifying WinUAE's scanlines line mode

[mark_k]

I've been trying to modify the "scanlines" line mode to give a kind of interlace simulation effect. The effect I want to achieve is, in interlaced modes alternate lines are output as black. I seem to remember Toni not wanting to implement this, hence my so-far-unsuccessful ham-fisted attempts...

So for example:
field n: line1, black, line3, black, line5, black, ...
field n+1: black, line2, black, line4, black, line6, ...

The result should look similar to a real 1084 monitor, including flicker. Best seen with vsync enabled of course. [For what it's worth, some professional/broadcast monitors have a similar feature, to allow 1080i input to be viewed without deinterlacing on the 1080p screen.]

Currently "scanlines" line mode displays interlaced modes the same as "doubled" line mode. That is, like a flicker fixer on a real Amiga does. So horizontally-scrolling text has a "comb" artifact on the edges of the letters. (There is also a brightness mismatch since non-interlaced modes have every other line black, but interlaced modes have no lines black.)

The main reason for this is to (hopefully) allow programs/demos which look awful both with and without "remove interlace artifacts", to be experienced similarly to a real Amiga with CRT TV. A good example is Multiscroller by Celtic which has many lines of scrolling text, each moving at a different speed. Most lines are illegible in WinUAE.

Anyway, I've tried a few things but haven't managed to get the effect I want.

First I noticed that in hsync_record_line_state() there is

case nln_lower:
	if (state[-1] == LINE_UNDECIDED)
		state[-1] = LINE_DECIDED; //LINE_BLACK;
	*state = changed ? LINE_DECIDED : LINE_DONE;
	break;
case nln_upper:
	*state = changed ? LINE_DECIDED : LINE_DONE;
	if (state[1] == LINE_UNDECIDED
		|| state[1] == LINE_REMEMBERED_AS_PREVIOUS
		|| state[1] == LINE_AS_PREVIOUS)
		state[1] = LINE_DECIDED; //LINE_BLACK;
	break;

I tried replacing the two = LINE_DECIDED with = LINE_BLACK as suggested by the commented-out parts, but that didn't work.

Next there is this code in custom.cpp:

if (doflickerfix () && interlace_seen > 0) {
	lineno *= 2;
} else if (currprefs.gfx_vresolution && (doublescan <= 0 || interlace_seen > 0)) {
	lineno *= 2;
	nextline_how = currprefs.gfx_vresolution > VRES_NONDOUBLE && currprefs.gfx_scanlines == false ? nln_doubled : nln_nblack;
	if (interlace_seen) {
		if (!lof_current) {
			lineno++;
			nextline_how = nln_lower;
		} else {
			nextline_how = nln_upper;
		}
	}
}

I tried replacing nln_lower and nln_upper with nln_nblack but that didn't work either.

Is there any simple change I could make without needing extensive knowledge of WinUAE internals to achieve the effect I want?

[Toni Wilen]

I think I'd like to implement this now because it probably would work nicely with black frame insertion and lightboost monitor

Unfortunately it isn't easy change, display emulation is built to "remember" matching odd/even line and it gets really confused (resulting in corrupt output) if lines aren't built that way.

[Toni Wilen]

Done, at least I think so, it looks like it is working.. Usual winuae.zip url.

Manually change config file "gfx_linemode=double2" to enable it.

EDIT: It really seems to work quite nicely. Also GUI option added.

[mark_k]

Yep it seems to work great. How does it look with black frame insertion too? I don't have the hardware to check that.

There is a half-brightness issue, the opposite of that with the old scanlines output mode; interlaced modes appear at half the brightness of non-laced modes. With the old scanlines mode, non-laced modes are half the brightness of interlaced modes. (Basically, IMHO it would be better to make non-laced modes show the same as non-laced modes in scanlines output mode.)

I did notice in the Celtic Multiscroller demo, that some lines of text have comb/fringe artifacts but others don't. E.g. the slowest-moving line. Is that visible on a real Amiga & CRT monitor?

Looking at the WinUAE source, it seems WinUAE notes which scanlines are unchanged since the previous frame to avoid having to render every line. Does that still work with this interlace simulation? Since now the corresponding scanline in the previous output frame will always be black; you'd have to look two fields back to check for a match.

I was thinking of other ways to implement this feature. It could be done with a shader I suppose, providing shaders know whether each field is odd or even.

[Toni Wilen]

Originally Posted by mark_k

Yep it seems to work great. How does it look with black frame insertion too? I don't have the hardware to check that.

I only quickly checked and it made it more sharper as expected.

There is a half-brightness issue, the opposite of that with the old scanlines output mode; interlaced modes appear at half the brightness of non-laced modes. With the old scanlines mode, non-laced modes are half the brightness of interlaced modes. (Basically, IMHO it would be better to make non-laced modes show the same as non-laced modes in scanlines output mode.)

I plan to add separate options for non-lace and lace modes, something like:

"Normal" and "Scanlines" stays the same.
Old Doubled gets separated in "non-lace" and "interlace" settings:
"non-lace" has doubled and doubled+scanlines options.
"Interlaced" has old-style progressive conversion and new alternate lines options.

(Need some nice and sort names..)

I did notice in the Celtic Multiscroller demo, that some lines of text have comb/fringe artifacts but others don't. E.g. the slowest-moving line. Is that visible on a real Amiga & CRT monitor?

Haven't tested yet but I'll assume it is demo problem because other interlaced scrollers seem to work fine.

Looking at the WinUAE source, it seems WinUAE notes which scanlines are unchanged since the previous frame to avoid having to render every line. Does that still work with this interlace simulation? Since now the corresponding scanline in the previous output frame will always be black; you'd have to look two fields back to check for a match.

It has to render all lines every field continuously to support this mode, there is no other way, at least without major rewrite.

I was thinking of other ways to implement this feature. It could be done with a shader I suppose, providing shaders know whether each field is odd or even.

Interlace is core feature, shaders aren't the correct way to do this.

[amilo3438]

The best and probably only way to get rid of scanelines interlace issues in window mode is to use normal line mode with small tweaks ... check in attachment!

Yeah, no scanelines mode then, but also no scaneline interlace issues!

With this new "double, interlace" line mode in latest test winuae.zip version I got something mixed with black scanelines and a lot of flickering (f.e. pic.1)!

[Toni Wilen]

Originally Posted by amilo3438

The best and probably only way to get rid of scanelines interlace issues in window mode is to use normal line mode with small tweaks ... check in attachment!

Yeah, no scanelines mode then, but also no scaneline interlace issues!

With this new "double, interlace" line mode in latest test winuae.zip version I got something mixed with black scanelines and a lot of flickering (f.e. pic.1)!

You missed the point, the point was to reduce artifacts by emulating interlace just like interlace, including flickering.

normal mode = you just lost half of vertical resolution..

EDIT: flicker free non-artifacting interlace is not possible. There are only different solutions that have different kind of artifacts.

[amilo3438]

Originally Posted by Toni Wilen

You missed the point, the point was to reduce artifacts by emulating interlace just like interlace, including flickering.

normal mode = you just lost half of vertical resolution..

Yeah, its sort of trade-off ... but also dont remember on a real amiga on interlace modes to have any of black lines on screen?! ... just flickering

The best what would like to see is something like: "scaneline, interlace" mode ...

and that would mean "scanelines" is in not interlace resolutions, in interlace then same as "double, interlace" ... if possible!?

[Toni Wilen]

Originally Posted by amilo3438

Yeah, its sort of trade-off ... but also dont remember on a real amiga on interlace modes to have any of black lines on screen?! ... just flickering

The best what would like to see is something like: "scaneline, interlace" mode ...

I thought so but results are worse. Not erasing (=making it black) previous field makes interlaced scrollers unreadable, again, different kind of unreadable but still unreadable.

[Toni Wilen]

Originally Posted by mark_k

I did notice in the Celtic Multiscroller demo, that some lines of text have comb/fringe artifacts but others don't. E.g. the slowest-moving line. Is that visible on a real Amiga & CRT monitor?

Tested, fast scrolling text is impossible to read on CRT (old 14" Philips TV monitor) too. Scrolling text is not "CRT" sharp, only very low speed scrollers look fine.

[Toni Wilen]

New options (config-file only so far) added: gfx_linemode=

double2 = doubled and alternating+blacking interlace at 50Hz (like previously)
scanlines2 = scanline non-lace and same interlaced as above
double3 = doubled and alternating only at 50Hz
scanlines3 = scanline non-lace and same as double3 interlace.

Only difference between double3 and normal double is frame rate, normal doubled interlace display refresh is 25Hz, double3 is same as double with refresh rate of 50Hz (and with different artifacts)

[amilo3438]

scanlines3 =

When emu is running and scrolltext is moving it looks just fine = can read it

(p.s. not important but when pause the emu got same results as on "scanelines" line mode = means not possible to take screenshot how it looks when working fine)

[Toni Wilen]

Originally Posted by amilo3438

scanlines3 =

When emu is running and scrolltext is moving it looks just fine = can read it

It is not always fine, for example Shed Tears / Ozone slideshow scroller looks quite bad in this mode. (btw, you missed that last segment of scroller was broken in b12 and older )

(p.s. not important but when pause the emu got same results as on "scanelines" line mode = means not possible to take screenshot how it looks when working fine)

It is an optical illusion, interlace makes things interesting

double2/scanlines2 of course is "wrong" when paused because both fields are never visible at the same time.

[amilo3438]

Originally Posted by Toni Wilen

It is not always fine, for example Shed Tears / Ozone slideshow scroller looks quite bad in this mode.

To me it still looks better on scanelines3 then on scanelines ... probably an optical illusion.

Originally Posted by Toni Wilen

(btw, you missed that last segment of scroller was broken in b12 and older )

its impossible to check everything in every beta! ... btw. what scroller?

Originally Posted by Toni Wilen

double2/scanlines2 of course is "wrong" when paused because both fields are never visible at the same time.

of course its "wrong", also didnt like how scanelines2 mode behaves.

[Toni Wilen]

It looks like monitor refresh rate make big difference.

double2/scanlines2 and Shed Tears / Ozone slide show image + scroller visible:

Standard 60Hz: weird flickering, it is not interlace flickering but something different. Some kind of beat frequency? Looks bad.

100/120Hz (and lightboost active): "normal" interlace-like flickering left, looks quite nice.

what scroller?

The one that is on top of interlaced slide show images.

[mark_k]

Some more thoughts about interlacing issues.

Suppose the user has their PC desktop set to an interlaced mode, e.g. 1080i. In that case running WinUAE in the normal doubled line mode should provide simulated interlacing, providing WinUAE is properly synchronised with the PC output. Whether the sync is PC odd ⇔ Amiga odd & PC even ⇔ Amiga even or the opposite will actually depend on the vertical position of the emulation window. In other words, whether the odd Amiga lines are on odd PC lines, or if even Amiga lines are on odd PC lines. Running WinUAE with simulated interlacing, it will be important to match this correctly, otherwise the emulation window contents could appear as all black.

Regarding the different display options in GUI, there could be two pairs of radio buttons (or maybe drop-down lists?). One for non-interlaced and the other for interlaced modes. You could have a tooltip saying that vsync is recommended for simulated interlacing.
Non-interlaced: scanlines / line doubled
Interlaced: simulated interlacing / "flicker-fixed" (/ maybe also remove interlace artifacts if you want to move that setting there)

An idea for an alternative way to implement scanlines/simulated interlacing. (Or is this the same as a shader???) You'd have the emulation output the same as the current doubled line mode. But on top of the emulation output there would be a 1x2 pixel texture (repeated), top pixel transparent and bottom black, or vice versa depending on the field type. That would get you the scanlines effect (for non-laced) and interlace simulation (for laced modes) for free. And the rendering optimisation for unchanged interlace-mode scanlines would still work. With normal line mode that should still work to give the same effect, albeit without rendering optimisation for interlaced modes. Would that technique work for DirectDraw as well as D3D?

You could also emulate a long-persistence monitor by changing the opacity of the black pixel; e.g. with 50% opacity the previous field's lines would show at half brightness.

About the comb artifacts in some lines of scrolltext in that Celtic demo. After thinking about it for a bit, that's normal and unavoidable for some scroll speeds. Moving one pixel every two fields has artifacts:

       Field1 Field2 Field3 Field4 Field5
row1    X      blk    X-1    blk    X-2
row2    blk    X      blk    X-1    blk
row3    X      blk    X-1    blk    X-2
row4    blk    X      blk    X-1    blk
row5    X      blk    X-1    blk    X-2
row6    blk    X      blk    X-1    blk

There the "front/first" rows are always the odd lines. In contrast, moving one pixel per field there is no fringing/comb artifact, since the "front/first" lines alternate each field:

       Field1 Field2 Field3 Field4 Field5
row1    X      blk    X-2    blk    X-4
row2    blk    X-1    blk    X-3    blk
row3    X      blk    X-2    blk    X-4
row4    blk    X-1    blk    X-3    blk
row5    X      blk    X-2    blk    X-4
row6    blk    X-1    blk    X-3    blk

(X-n denotes horizontal position, blk denotes black)

Originally Posted by Toni Wilen

Standard 60Hz: weird flickering, it is not interlace flickering but something different. Some kind of beat frequency? Looks bad.

if that was running a 50Hz/PAL demo non-vsynced with 60Hz PC desktop, then yes that looks awful!

[mark_k]

Has anyone got any more good examples of demos (or whatever) which use interlace, whose appearance is poor when the output is flicker-fixed or remove interlace artifacts is used?

Now we have interlace simulation, you could emulate the Haitex X-Specs LCD shutter glasses (assuming the user has a PC with LCD shutter glasses too -- or maybe a 3D display???). For example in this post nujack attached a picture of a cube. When viewed in interlace mode with 3D glasses, the odd fields would go to the left eye and even to the right (or vice versa) thus creating the 3D illusion since each eye sees a different image.

[amilo3438]

Just have checked latest (todays) winuae.zip ...

So yesterdays "scanlines3" = "scaneline2" in this new version ?!

Just wondering, the option "Remove interlace artifacts" is needed only for "scanelines" or "double, frames" interlace mode, but is not needed in two other modes, right ?
Asking that as its still possible to select the option in any of interlace modes?!

[mark_k]

After reading the WinUAE 2.7b13 changelog and re-reading some of Toni's posts in this thread, a question about the old flicker-fixed interlaced modes.

If I have it right, with the old mode ("Double, frames" in the latest beta) WinUAE builds frames from two successive interlaced fields, then outputs each frame twice. Compare that with the new "Double, fields" mode which works the same as a real Amiga with flicker fixer. There each output frame consists of the current and previous fields.

I'm just wondering, was there supposed to be any benefit in in the old "Double, frames" mode? Which field does WinUAE treat as coming first in building a complete frame, odd or even? Are there any cases where it looks better than "Double, fields" mode? And I think the increased latency could be a disadvantage for games (not that many games use interlaced mode, but anyway...).

I can imagine a specific case of scrolling text where "Double, frames" could look better (no fringing artifacts but moving at 25fps instead of 50fps). But even on a real Amiga with or without flicker fixer, there would be artifacts (see my post above about 1-pixel-per-field scrolling). And whichever field order WinUAE uses when building frames may not match that used by any particular program.

Edit to add: Compare the mouse pointer on an interlaced Workbench. Move the mouse in a circle. With Double, frames mode there seem to be more mouse trails/ghost images than with Double, fields.

[Toni Wilen]

I don't know, it has been like this before I knew about UAE and I never really cared about interlace much until recently.