English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 10 March 2014, 20:45   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
Reducing motion blur by forcing interlacing

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).
Attached Files
File Type: zip TKT_BS1-CrJumpJet_lace.adf.zip (110.7 KB, 71 views)

Last edited by mark_k; 10 March 2014 at 21:25.
mark_k is offline  
AdSense AdSense  
Old 12 March 2014, 16:00   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Do you mean you only need option that forces BPLCON0 LACE bit always on?
Toni Wilen is online now  
Old 12 March 2014, 16:19   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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:
Code:
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:
Code:
         [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
mark_k is offline  
Old 12 March 2014, 20:50   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Done (without GUI support)

linemode=<value>

Code:
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)
Toni Wilen is online now  
Old 12 March 2014, 22:27   #5
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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?

Last edited by mark_k; 12 March 2014 at 22:38.
mark_k is offline  
Old 13 March 2014, 11:44   #6
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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.
mark_k is offline  
Old 15 March 2014, 09:07   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Useless for 99.9% users GUI option added and half-height bug fixed.
Toni Wilen is online now  
Old 15 March 2014, 11:20   #8
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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 is offline  
Old 21 December 2014, 16:33   #9
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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():
Code:
} 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 is offline  
Old 21 December 2014, 17:06   #10
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
(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.)
mark_k is offline  
Old 22 December 2014, 16:29   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Quote:
Originally Posted by mark_k View Post
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 is online now  
Old 22 December 2014, 20:15   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
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
Toni Wilen is online now  
Old 22 December 2014, 20:31   #13
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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.
Attached Thumbnails
Click image for larger version

Name:	pic1.png
Views:	136
Size:	18.9 KB
ID:	42517   Click image for larger version

Name:	pic2.png
Views:	132
Size:	18.9 KB
ID:	42518  
Attached Files
File Type: lha colour_loop.lha (763 Bytes, 41 views)
mark_k is offline  
Old 23 December 2014, 15:03   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
winuae.zip updated, at least in my own test program last line now toggles correctly.
Toni Wilen is online now  
Old 23 December 2014, 16:22   #15
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
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
Attached Thumbnails
Click image for larger version

Name:	pic3.png
Views:	100
Size:	10.1 KB
ID:	42528   Click image for larger version

Name:	non-laced_double.png
Views:	98
Size:	10.5 KB
ID:	42530   Click image for larger version

Name:	non-laced_doublefields.png
Views:	105
Size:	10.5 KB
ID:	42531  

Last edited by mark_k; 23 December 2014 at 17:09.
mark_k is offline  
Old 23 December 2014, 16:44   #16
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
Quote:
Originally Posted by mark_k View Post
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:
// 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}
mark_k is offline  
Old 23 December 2014, 17:40   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,518
Quote:
Originally Posted by mark_k View Post
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.

Quote:
Originally Posted by mark_k View Post
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.
Toni Wilen is online now  
Old 23 December 2014, 18:09   #18
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by mark_k; 23 December 2014 at 18:51.
mark_k is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
120Hz Monitor HOWTO: Reduce motion blur in WinUAE! mdrejhon support.WinUAE 24 15 September 2014 11:59
PAL filter blur+offset Photon support.WinUAE 2 02 March 2014 00:20
Reducing icon image tool fc.studio support.Apps 0 07 August 2007 08:26
Forcing old programs to higher resolution BiL0 New to Emulation or Amiga scene 6 30 April 2006 11:02
Forcing games to take up full screen? Mojo2000 New to Emulation or Amiga scene 2 09 February 2003 15:59

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:00.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.28464 seconds with 12 queries