Dolphin, the GameCube and Wii emulator - Forums

(08-04-2017, 02:36 AM)degasus Wrote: [ -> ]Yeah, I agree. For further investigation, I suggest to use XFB emulation and to patch dolphin to print a frame number on the screen.

Good: a frame number overlay would help; it seems to me that Retroarch prints the framenumber together with the FPS.
Why do you suggest XFB emulation?

(08-04-2017, 02:36 AM)degasus Wrote: [ -> ]The Wii doesn't support 30fps scanout, it just repeats each frame twice. And this is controlled by the game, so it *might* be accurate - but unlikely.

For the sake of clarity, I did all my tests with GameCube’s Zelda.

(08-04-2017, 02:36 AM)degasus Wrote: [ -> ]While you're at it, it might be a good idea to also visualize those variables: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/SystemTimers.cpp#L200 - They are responsible for syncing the emulated time with the real time.

It seems a great idea to me.  These stats could be printed with the Graphics->Advanced->Debugging->Show Statistics checkbox enabled.
By the way I checked Dolphin’s logs and I didn’t see any COMMON system too fast or slow log, so (abs(diff) > max_fallback) condition is never met; maybe else if (diff > 0) Common::SleepCurrentThread(diff); is the cause?

(08-04-2017, 02:36 AM)degasus Wrote: [ -> ]It allows to run the emulation faster for a few milli seconds if we're behind the real time. So aabbccDDDEffgg should be a common pattern, not the other way around...

I see... but in my video I encountered the reverse pattern: AABBCC[color=#ff3333]DEEE[/color]FFGGHH. Is it possible that a wrong timing evaluation during C frame (believed CCC instead of CC) sets a chain effect that speeds emulation during D frame (displayed once) and then, for compensation, slows emulation during E frame (displayed three times)?



Best regards.
Locutus73

Can you try overclocking the emulated CPU to 200% and see if this happens?

I just tried it myself, there is indeed some subtle stuttering. The Wii version doesn’t suffer from this though, it's perfectly smooth (for a 30 fps game).
The stuttering in you video is pretty heavy compared to what I have. Perhaps it is because of V-Sync, or the capturing software. I have a G-Sync monitor, so any stuttering that I see in exclusive fullscreen mode cannot be some V-Sync or refresh rate judder.
What I see is less pronounced than you, but there's definitely some micro stuttering in some key areas.
I'd fire up my Wii to make sure but the only copy I have of Twilight Princess GameCube is factory sealed.

Edit : judging by old YouTube video of the intro capture on a real GC/Wii, there is no stuttering whatsoever. And stuttering is present on old videos captured with Dolphin. So it is an emulation problem.

Let's turn it up a notch. What happens if you do a frame-dump using Dolphin's framedump feature? Does the video it outputs have the stutter?

(08-04-2017, 07:03 AM)Locutus73 Wrote: [ -> ]Good: a frame number overlay would help; it seems to me that Retroarch prints the framenumber together with the FPS.
Why do you suggest XFB emulation?

We call the "scanout" emulation XFB. Without it, we just scan out all framebuffer copies which are in the format the hardware is able to scanout. This is a big hack, but it simplifies a lot and removes latency. With virtual XFB, you should see 60 fps. With also enabled GFX stats, you should see that there is one hard frame and one easy frame. So those repeated frames are now easier to distinguish.

By the way, without scanout emulation, our scanout isn't synchronized well to the real time. So it *might* be too fast.

(08-04-2017, 07:03 AM)Locutus73 Wrote: [ -> ]It seems a great idea to me.  These stats could be printed with the Graphics->Advanced->Debugging->Show Statistics checkbox enabled.
By the way I checked Dolphin’s logs and I didn’t see any COMMON system too fast or slow log, so (abs(diff) > max_fallback) condition is never met; maybe else if (diff > 0) Common::SleepCurrentThread(diff); is the cause?

The default max slowdown is for 40 ms, so you should not reach this in gameplay at all. But a few ms are very common.
The second condition throttles the emulation if it is too fast. We try to sleep for 1 ms, but if your host OS won't shedule dolphin for a long time, this might happen as well. But errors of this kind won't scan out a frame too early.

Thanks to all, I’ll consolidate my answers here.

(08-04-2017, 10:25 AM)JMC47 Wrote: [ -> ]Can you try overclocking the emulated CPU to 200% and see if this happens?

If you see post #8 I tried and the stutters remain.

(08-04-2017, 02:00 PM)Shadorino Wrote: [ -> ]I just tried it myself, there is indeed some subtle stuttering. The Wii version doesn’t suffer from this though, it's perfectly smooth (for a 30 fps game).

I just tried the Wii version and the stutters remains. To be honest each run is different, but statistically there are sections of the intro with more stutters than others; Wii intro seems to be less affected, but stutters are still there.

(08-04-2017, 02:00 PM)Shadorino Wrote: [ -> ]The stuttering in you video is pretty heavy compared to what I have. Perhaps it is because of V-Sync, or the capturing software.

If I disable VSync I get unbearable (at least for me) screen tearing. I used NVidia ShadowPlay in order to capture and, honestly, the resulting video is faithful to what I saw on my display. When I disable NVidia Experience Overlay (so ShadowPlay) as I do normally, I get the same stuttering. I could use my AverMedia Live Game Portable, but it’s capped at 1080p30.

(08-04-2017, 02:00 PM)Shadorino Wrote: [ -> ]I have a G-Sync monitor, so any stuttering that I see in exclusive fullscreen mode cannot be some V-Sync or refresh rate judder.
What I see is less pronounced than you, but there's definitely some micro stuttering in some key areas.

With variable refresh rate monitors the stuttering is less evident (this is their purpose), but, in theory, a really accurate emulation should produce a 30/60Hz refresh rate with G-Sync.

(08-04-2017, 02:00 PM)Shadorino Wrote: [ -> ]Edit : judging by old YouTube video of the intro capture on a real GC/Wii, there is no stuttering whatsoever. And stuttering is present on old videos captured with Dolphin. So it is an emulation problem.

Excellent… I mean bug replication is the key to bug fixing.
In the past shader cache compilation could have introduced ambiguity in stuttering analysis, but now, with Exclusive Ubershaders and powerful GPUs I think we can rule out any ambiguity and devs will be able to shave off the last imperfections.

(08-04-2017, 05:41 PM)JMC47 Wrote: [ -> ]Let's turn it up a notch.  What happens if you do a frame-dump using Dolphin's framedump feature?  Does the video it outputs have the stutter?

I tried and I get a butter smooth 30FPS video (from a session where I saw stutters on my display). From my understanding Dolphin’s framedump recorded single rendered frames (so 30FPS) eliminating the frame pacing problem, while ShadowPlay recorded actually displayed frames (so 60FPS) with the stuttering that, eventually, I see on my display.

(08-04-2017, 06:53 PM)degasus Wrote: [ -> ]We call the "scanout" emulation XFB. Without it, we just scan out all framebuffer copies which are in the format the hardware is able to scanout. This is a big hack, but it simplifies a lot and removes latency. With virtual XFB, you should see 60 fps. With also enabled GFX stats, you should see that there is one hard frame and one easy frame. So those repeated frames are now easier to distinguish.

By the way, without scanout emulation, our scanout isn't synchronized well to the real time. So it *might* be too fast.

The default max slowdown is for 40 ms, so you should not reach this in gameplay at all. But a few ms are very common.
The second condition throttles the emulation if it is too fast. We try to sleep for 1 ms, but if your host OS won't shedule dolphin for a long time, this might happen as well. But errors of this kind won't scan out a frame too early.

And just for the record I tried to enable XFB: with virtual XFB the stuttering remains, with real XFB the stuttering is almost non existent (if not existent at all), but the output is limited to 1xIR. If I disable XFB again and I set 1xIR, no AA, 1x AF I get the stuttering again.
Maybe timing stats should earn a dedicated section in Advanced->Debugging?

By the way, doing these tests I noticed that anisotropic filter destroys god rays during the intro. If you watch my first video (16x AF) you can barely see some white lines, with 1x AF I can see god rays and they disappear linearly upping AF.



Best regards.
Locutus73

Just out of curiosity I tried two things:
1) Setting a 30FPS limit to Dolphin through RivaTuner Statistics Server: no more AABBCC[color=#ff3333]DEEE[/color]FFGGHH patterns, but worse stuttering; single (30FPS) rendered frames displayed for even 4 (60FPS) display frames.
2) I tried RetroArch's Dolphin core: worse stuttering with single (30FPS) rendered frames displayed for 1, 2, 3, 4 and even 5 (60FPS) display frames.



Best regards.
Locutus73

May you try virtual XFB and enable the GFX stats? So no frame should be repeated at 60 fps and we'll see which are repeated because of vsync timing or because of in-game timing.

Just posting my two cents.

First of all, thank you for looking into this as well. This has been a problem that I noticed for a long time now but it was otherwise very difficult to prove because of shader generation being the main culprit. Now that we have a method of completely eliminating the frame pacing issues brought on by shader generation through exclusive ubershaders, we can see what else affects the frame pacing in Dolphin.

There are only a few things that I have been able to identify whenever I encountered the problem.

1.) This issue is more apparent in games that run below 60fps, i.e games that run consistently at 30fps (like Pikmin, PSO, Luigi's Mansion, Sunshine, etc).
2.) The issue is not caused by shader generation, as it affects frame delivery in places where calls to generate a shader should not happen (even in subsequent playthrus).
3.) The issue affects every video backend and has existed since before Dolphin 2.0. Although some backends seem to fair worse than others, this could be a placebo.
4.) The stuttering occurs inconsistently and lasts for a duration of a few seconds.
5.) The audio doesn't seem to stretch or pop when this occurs.

I tried various settings over the years to see if it would affect the stuttering but nothing seems to fix it.   Recently, I experimented with Afterburner/Rivatuner to see if I could capture the issue in a fps/frame pacing graph in real time. I captured some video of Luigi's Mansion today to illustrate this issue (using NVENC/Shadow Play), so take a look here.

Dolphin was configured with these settings (recorded in exclusive fullscreen mode, Windows 10):
Dual Core - Off
DSP: LLE recompiler
Audio Backend: Cubec (20ms latency)

Backend: D3D 11
Adapter: Nvidia GeForce GTX 680
Vsync: Enabled
Internal Resolution: Native
Anti-Aliasing: None
Anisotropic Filtering: 1x
Ubershaders: Exclusive
All enhancement settings disabled.
All hacks disabled
Texture Cache: Safe (max)
XFB: Virtual
Progressive Scan: Enabled

One thing that does strike me a bit odd is that I noticed that the framerate and frame timing are VERY variable even at the best of times, never settling at a solid framerate. Note, Rivatuner/Afterburner is set to refresh the graph every 100ms, so there's a chance that the graph won't reflect the actual frame pacing.



I can only suspect that this might have something to do with it, but why it happens and when it happens I'm not sure. This could all be unrelated, but it seems suspect.

Hopefully the lack of video backend hacks and dual core aren't causing the slight variations in performance, especially here with exclusive ubershaders on.

(08-04-2017, 09:28 PM)Locutus73 Wrote: [ -> ]By the way, doing these tests I noticed that anisotropic filter destroys god rays during the intro. If you watch my first video (16x AF) you can barely see some white lines, with 1x AF I can see god rays and they disappear linearly upping AF.



Best regards.
Locutus73

That issue is well known and has been in the WIKI for the game since the beginning (that I know of) and it does not just destroy the godrays in the intro but also in the game. But since anisotropic is an enhancement, it will probably never be fixed.