VI: derive field timing from VI registers #2686

booto · 2015-07-02T16:42:11Z

Rather than hard coding field timing for PAL/NTSC/Progressive this should derive it from the values set in the VI registers.

This PR also adds an option to enable/disable the forcing of interlaced to progressive fields. The option is not exposed via the UI. It defaults to ON and when on forces interlaced video modes to emit full progressive fields. This restores the old force-progressive hack but makes it optional via INI edit.

PR created to trigger builds for testing.

Some problems:

~~% in title bar seems to be slightly off.~~
~~Interlaced signal gives the one-line-jitter problem (again)~~
~~save state version has been bumped, might need to be updated later on~~

mimimi085181 · 2015-07-02T18:41:45Z

Seems to fix this issue: https://code.google.com/p/dolphin-emu/issues/detail?id=7734 (Baten Kaitos Eternal Wings and the Lost Ocean Flickering in PAL version)

JMC47 · 2015-07-02T18:42:47Z

Sonic Mega Collection: Blue Sphere has severe flickering in this; works in Master.

JMC47 · 2015-07-02T18:50:49Z

FIXES NES PAL GAME AUDIO.

JMC47 · 2015-07-02T18:52:30Z

Virtual XFB is bugged on Super Smash Bros. (VC PAL), Real XFB and no XFB works

JMC47 · 2015-07-02T19:12:46Z

Fixes the Wind Waker PAL50 Hang.

JMC47 · 2015-07-02T19:20:33Z

Metroid Prime 3 no longer shits itself in Real/VirtualXFB

JMC47 · 2015-07-02T22:39:06Z

Metroid Prime 2/3 no longer suffer from the black bar glitch with XFB enabled.

Linktothepast · 2015-07-03T17:04:13Z

Actually it seems that all the abnormal speed issues with virtual console games are fixed by this one with no need for progressive scan either in the snes and genesis games that needed it for normal speed. Neo geo games also work fine with no speed issues.
https://code.google.com/p/dolphin-emu/issues/detail?id=7039
https://code.google.com/p/dolphin-emu/issues/detail?id=6466
The above issues are totally fixed.

shuffle2 · 2015-07-03T23:10:55Z

nice. can NTSC_FIELD_RATE + etc be removed now?

mimimi085181 · 2015-07-05T14:28:16Z

Ok, i did some more tests with Baten Kaitos. First, the flickering goes away(on master) when using an AR code to force the game to play at in 60/30 instead of 50/25 Hz mode. Also the small black bar at the bottom goes away in 60/30 Hz mode. I kinda expected this, because the NTSC version does not have flickering.

The screen wobbles with virtual xfb with this pr. That is already known, but it randomly decides to flicker as well. When it flickers, it flickers above the screen in 50 Hz mode, and below the screen in 60 Hz mode. This can only be seen in windowed mode, see screenshots:
https://drive.google.com/file/d/0ByQgqzsPdirYZEhxNW55X09KUzA/view?usp=sharing
https://drive.google.com/file/d/0ByQgqzsPdirYYnFnVHRKNFFJUjQ/view?usp=sharing

Could the randomness be related to the game changing between 25/50 Hz modes?

Could anything be related to the game using still pictures. I mean, the game does something weird with the nintendo logo at startup. If the window is resized, the logo does not change accordingly and stays at the same x/y position in the window at the same size. On master, the fps is 0(vps 50) at that time, and the logo does not flicker like the rest does.

Source/Core/Core/HW/VideoInterface.cpp

+	54000000UL,
+};
+
+static u64 s_ticks_last_line_start = 0;


shuffle2 · 2015-07-07T17:05:20Z

Could the randomness be related to the game changing between 25/50 Hz modes?

If the game changes modes (or does other things which could produce random/ugly output for a small time period), they should disable VI during that period, which results in a black screen since nothing gets drawn out. I'm not sure if this works correctly on dolphin.

Source/Core/Core/State.cpp

@@ -66,7 +66,7 @@ static Common::Event g_compressAndDumpStateSyncEvent;
 static std::thread g_save_thread;

 // Don't forget to increase this after doing changes on the savestate system
-static const u32 STATE_VERSION = 44; // Last changed in PR 2464
+static const u32 STATE_VERSION = 45; // Last changed in PR 2464


booto · 2015-07-07T18:36:44Z

@shuffle2 Yes, I've removed NTSC_FIELD_RATE et al.

MayImilae · 2015-07-26T08:31:28Z

Is this ready to go? It would be great in the progress report!

JMC47 · 2015-07-26T08:52:40Z

I think it needs to have the progressive hack put into it... It has a screen shaking issue in interlaced mode.

booto · 2015-07-28T12:29:05Z

Progressive hack added (see updated description in first comment).

Only issue I'm still aware of is the Baten Kaitos problem @mimimi085181 mentioned. Could we get some clear repro steps with settings/etc?

magumagu · 2015-07-28T19:05:55Z

"Force Progressive Output" isn't a useful option to expose in the UI. I mean, it's useful in theory, but there isn't any point without actual interlacing support.

phire · 2015-07-29T07:07:15Z

I have to agree with magumagu, the option doesn't even do what it says, the main force progressive hack stays enabled.

booto · 2015-07-29T15:58:55Z

I'm wondering if progressive has actually ever worked properly? I'm assuming I've made a silly mistake somewhere, but here's what I've found:

In current master (567d0b2...)
I've enabled progressive mode, VI BeginField logs confirm it's in progressive. I'm on Windows, and added a GetTickCount() value to each of those lines. This is a timestamp from an arbitrary start point in milliseconds.

Here's a filtered extract of the log:

25:30:871 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 002D92A0 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056688
25:30:895 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056719
25:30:932 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056750
25:30:968 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 002D92A0 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056782
25:30:997 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056813
25:31:028 HW\VideoInterface.cpp:541 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | ACV 464 | Field Progressive | WindowsTickCount: 14056844

The milliseconds between frames: 31, 31, 32, 31, 31.

This corresponds to 1000/31 ~ 30-ish Hz. For Progressive (480p) we'd expect 60Hz...

Looking at the code,

Progressive is not interlaced so m_DisplayControlRegister.NIN is 1, so fields is 2 (??!).
See: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/VideoInterface.cpp#L441

Progressive frames are emitted at line 1 of the scanout.
See: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/VideoInterface.cpp#L560

The number of lines "virtually scanned out" is s_lineCount * fields.
See: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/VideoInterface.cpp#L584

It looks like the second field is being counted through, but nothing being scanned out.

A similar log generated in this PR:

51:18:328 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 002D92A0 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Odd | WindowsTickCount 15604156
51:18:344 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Even | WindowsTickCount 15604171
51:18:360 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 002D92A0 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Odd | WindowsTickCount 15604187
51:18:377 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Even | WindowsTickCount 15604202
51:18:394 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 002D92A0 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Odd | WindowsTickCount 15604218
51:18:410 HW\VideoInterface.cpp:547 W[VI]: (VI->BeginField): Address: 00243280 | WPL 38 | STD 40 | EQ 12 | PRB 48 | ACV 464 | PSB 38 | Field Even | WindowsTickCount 15604234

The milliseconds between frames: 15, 16, 15, 16, 16.

This corresponds to 1000/16 ~ 60-ish Hz, in the ballpark of what's expected.

JMC47 · 2015-07-29T16:15:57Z

Progressive Scan + XFB outputs only half the frames in master (and this PR.) Perhaps related?

Try playing F-Zero GX with it, it's full of sadness. Same with Wind Waker.

JMC47 · 2015-07-29T19:51:03Z

Did a lot more testing and determined that the framedrop bug for Progressive Scan + XFB is fixed in single core within this Pull Request, but dualcore is broken still. @phire I think this is the only thing blocking virtual/hybrid XFB from moving toward default.

Testing wise, LGTM.

JMC47 · 2015-07-30T01:21:07Z

SyncGPU + RealXFB + Progressive works as well, as per @phire's request to test it.

booto · 2015-07-30T02:56:43Z

@magumagu @phire The last sync removed the option from the UI.

JMC47 · 2015-07-30T03:27:40Z

I found out that the Dualcore + RealXFB problems were due to it maxing out my GPU. Damn. There are literally no more problems/regressions with this, full LGTM this time.

JMC47 · 2015-07-30T03:38:44Z

As I say that, I found a regression. Sonic Mega Collection games, such as Sonic And Knuckles suffer from constant flickering.

phire · 2015-07-30T03:49:09Z

Oh, one final think we need to solve before merging is the mystery of why FifoCI is rendering double frames.

I didn't think Fifoplayer touched VI at all.

BhaaLseN · 2015-07-30T10:26:07Z

Does the Fifo-Log include all those fields? Maybe they were actually interlaced or something, which now works correctly?

degasus · 2015-07-30T10:32:39Z

fifo logs don't have the VI at all, only the XFB copy. That's why XFB is disabled on replaying fifo logs. So I wounder what's wrong here. I guess it's because of our (crappy) frame replay on avi dump: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/AVIDump.cpp#L231 We try to get a constant FPS there. Maybe this is wrong with the new VI code.

phire · 2015-07-30T10:40:39Z

While FifoPlayer has a very slightly different idea about cycles per frame.

JMC47 · 2015-07-30T17:35:59Z

Couple of things I noticed.

Virtual XFB on OpenGL still has stuff showing up below the bottom of the screen. D3D isn't doing it, so, I can't ponder a guess as to why.

Sonic Mega Collection is still flickering. That's not good. At least Master + PR NoXFB are the same (flickering), but for some reason there's a regression on Virtual and RealXFB causing them to flicker too.

magumagu · 2015-07-31T18:45:54Z

magumagu@f93c87e contains a corrected implementation of the ForceProgressive option.

JMC47 · 2015-08-04T18:32:13Z

Fixes Hydroventure (Fluidity PAL) in PAL50 mode.

JMC47 · 2015-08-10T17:01:12Z

Virtual XFB is 100% broken in the latest version of the PR. Jitter bug is still there in RealXFB.

Edit: Virtual XFB is broken only with force progressive off.

booto · 2015-08-12T11:40:36Z

Force-progressive being disabled while interlaced output is being emitted is expected to be broken at the moment. Earlier, it would force the effect of 'force progressive' to happen anyway. Now it actually tries to send the correct interlaced parameters to the code that scans out the image, but that code doesn't handle it properly (...yet). This is the effect of magumagu's patch mentioned above.

JMC47 · 2015-08-12T17:03:29Z

Fair enough then.

Bugfix: TargetRefreshRate uses rounded result NTSC's 59.94 was becoming 59 with integer division.

degasus · 2015-09-01T13:01:15Z

LGTM

JMC47 · 2015-09-02T12:40:58Z

LGTM. Sonic may need interlacing support, and this fixes a ton of other games.

VI: derive field timing from VI registers

booto force-pushed the field-timing branch from 5346225 to a6c02ac Compare July 2, 2015 16:49

booto force-pushed the field-timing branch 2 times, most recently from 465f5bf to 8e74842 Compare July 7, 2015 11:45

neobrain reviewed Jul 7, 2015
View reviewed changes

Source/Core/Core/HW/VideoInterface.cpp

54000000UL,

};

static u64 s_ticks_last_line_start = 0;

This comment was marked as off-topic.

Sign in to view

Linktothepast mentioned this pull request Jul 7, 2015

[WIP] Video: respect stride of efb copies to xfb #2720

Merged

comex reviewed Jul 7, 2015
View reviewed changes

booto force-pushed the field-timing branch 2 times, most recently from 53bcfcf to 4ea30db Compare July 7, 2015 18:29

phire mentioned this pull request Jul 21, 2015

Aspect Ratio/VI Scaling FIx #2765

Merged

booto force-pushed the field-timing branch 2 times, most recently from 48658a9 to fb83ddc Compare July 27, 2015 12:38

booto force-pushed the field-timing branch 2 times, most recently from df4d6dc to 187ab67 Compare August 10, 2015 06:37

booto added 4 commits September 1, 2015 20:24

VI: derive field timing from VI registers

480dbb2

VI: Restore forced-progressive hack with option

acc9a74

Bugfix: TargetRefreshRate uses rounded result NTSC's 59.94 was becoming 59 with integer division.

VI: Adjust forced-progressive hack per magumagu's suggestion

8d6c39a

FifoPlayer: Use VI derived timing, not hardcoded 60Hz

f6e4a8e

booto force-pushed the field-timing branch from b64f9b6 to f6e4a8e Compare September 1, 2015 12:36

booto changed the title ~~[WIP] VI: derive field timing from VI registers~~ VI: derive field timing from VI registers Sep 2, 2015

phire added a commit that referenced this pull request Sep 2, 2015

Merge pull request #2686 from booto/field-timing

ecbb83f

VI: derive field timing from VI registers

phire merged commit ecbb83f into dolphin-emu:master Sep 2, 2015

phire mentioned this pull request Sep 12, 2015

[WIP] Used a NTSC framerate of 59.94hz #1927

Closed

VI: derive field timing from VI registers #2686

VI: derive field timing from VI registers #2686

Conversation

booto commented Jul 2, 2015

mimimi085181 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

JMC47 commented Jul 2, 2015

Linktothepast commented Jul 3, 2015

shuffle2 commented Jul 3, 2015

mimimi085181 commented Jul 5, 2015

This comment was marked as off-topic.

shuffle2 commented Jul 7, 2015

This comment was marked as off-topic.

booto commented Jul 7, 2015

MayImilae commented Jul 26, 2015

JMC47 commented Jul 26, 2015

booto commented Jul 28, 2015

magumagu commented Jul 28, 2015

phire commented Jul 29, 2015

booto commented Jul 29, 2015

JMC47 commented Jul 29, 2015

JMC47 commented Jul 29, 2015

JMC47 commented Jul 30, 2015

booto commented Jul 30, 2015

JMC47 commented Jul 30, 2015

JMC47 commented Jul 30, 2015

phire commented Jul 30, 2015

BhaaLseN commented Jul 30, 2015

degasus commented Jul 30, 2015

phire commented Jul 30, 2015

JMC47 commented Jul 30, 2015

magumagu commented Jul 31, 2015

JMC47 commented Aug 4, 2015

JMC47 commented Aug 10, 2015

booto commented Aug 12, 2015

JMC47 commented Aug 12, 2015

degasus commented Sep 1, 2015

JMC47 commented Sep 2, 2015