Quote:
Originally Posted by Toni Wilen
I think it simply means it fails to recover if frames mismatch at least once. Nothing happens if fields match when switching to interlace.
Unfortunately I am not sure when I can test real interlaced modes again. ( http://eab.abime.net/showpost.php?p=810833&postcount=11 unless that one supports real interlace. I don't want to mix red and green drivers..) |
Ah you've taken the green pill
. That's a very nice card. Wouldn't know if it supports interlace. It should if you can connect through HDMI (
http://www.hdmi.org/learningcenter/glossary.aspx) as that supports interlace (1080i). I tried to replicate it with my ATI through HDMI and I can set my desktop to 1080i interlace mode, by selecting 25hz or 30hz in the windows screen resolution panel.
But if I try to make WinUAE switch between 1080p and 1080i to simulate my CRT config by changing the displaydata lines to:
displaydata=25,t=lace,pal,lace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double,gfx_refreshrate=25
displaydata=50,t=lof,pal,nlace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=none,gfx_refreshrate=50
then it either returns a black screen after the screenswitch to interlace in D3D, or an error with DirectDraw. But maybe after taking a green pill, this will work?
Possibly as a backup plan, if the above doesn't work (and assuming you also won't be having access to real interlace anytime soon again). Would it be possible to have the interlace code from 2.4.0 brought in behind a commandline switch? As that 2.4.0 code was tuned to work very well with a real CRT..
Quote:
|
I wouldn't care much about CPU% because method to calculate changes all the time and some waits may have been replaced with busy waits (no buffer = busy waits are usually better. Minimum wait is 1ms, which is very long time)
|
Ok, that's understable. I thought I'd mention it, just in case.