Core: Skip duplicate frames when using frame advance

[JosJuice]

https://bugs.dolphin-emu.org/issues/12025

It used to be the case that frame advance skipped duplicate frames (i.e. it would take 30 frame advances to get through one second of emulated time in a 30 fps game), but this broke in PR #8347. Skipping duplicate frames making TASing less annoying.

[phire]

I'll point out that this isn't going to work so well in any XFB mode other than Immediate Present.

Not sure if that's an issue you care about.

[JosJuice]

My testing was done without Immediately Present XFB, and I didn't run into any problems. What type of issue would it be more specifically?

[phire]

This PR makes an assumption that if the game copies something to a XFB, then that XFB will be displayed on screen in the next frame.

While this might be true in the general case, there are a lot of edge cases.

1. A frame might finish rendering just before the start of the field. The interrupt handler takes a short while to fire so in a race condition the XFB might not be displayed until a full frame later.

2. The game might be rendering partial XFBs. If it finishes one XFB section before the field boundary, it might still be waiting on a second section before it calls the XFB finished and displays it.

3. The game might be locked to 30fps. Just because an XFB is ready this field, doesn't mean the game will display it this field. For pacing issues.

4. The game might have more than 2 XFBs allocated. It might race ahead and finish 3 XFBs now and not display them until later.

[phire]

Oh.. thought of some more edge cases.

Homebrew often draws directly to XFB. These updates will be skipped over.

Retail games occasionally do this too. Some games render loading screens or cutscenes directly to XFB.

[phire]

So, we already have code that knows if an XFB is duplicate or not.

dolphin/Source/Core/VideoCommon/RenderBase.cpp

Line 1203 in b0e0404

if (xfb_entry &&

You should pipe that though to the FrameUpdate callback.

[JosJuice]

I've pushed a new version that should be better, though I'm not sure if it solves every problem you mentioned.

[phire]

Other than the minior naming/documentation issues I mentioned above, LGTM.