Project

General

Profile

Actions

Emulator Issues #12615

open

Speed Challenge: Jacques Villeneuve's Racing Vision Hangs

Added by ZephyrSurfer over 2 years ago. Updated over 2 years ago.

Status:
Accepted
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

Speed Challenge: Jacques Villeneuve's Racing Vision

Game ID? (right click the game in the game list, Properties, Info tab)

GSZP41

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

13730f9eda5e6877e556a21bb43e939b

What's the problem? Describe what went wrong.

The game will hang before the loading screen for a race.

What steps will reproduce the problem?

The game will crash before any race. So for example
Main Menu -> Single Player -> Quick Race -> Paris

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, 5.0-14831

Is the issue present in the latest stable version?

Yes, 5.0

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

4.0-5369 -> https://dolphin-emu.org/download/dev/b92eb03d26529103083984a46aee2db37aa853b3/

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

N/A. Nothing shows up in the log, I think.

What are your PC specifications? (CPU, GPU, Operating System, more)

i7-8750H
GTX 1060
Windows 10
8GB DDR4

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

Let me know, I'll see what I can do.

Actions #1

Updated by JMC4789 over 2 years ago

I swear I tested 4.0 and that didn't fix this game.

Actions #2

Updated by ZephyrSurfer over 2 years ago

I tested with default settings. The game doesn't work if it's on Single Core on this old build. Also the game looks like it's hung if XFB isn't set to real

Actions #3

Updated by ZephyrSurfer over 2 years ago

I just made a build with that commit reverted and the game then ran in both single and dual core mode.

Actions #4

Updated by JMC4789 over 2 years ago

Ah I see. I must have had another setting problem.

Actions #5

Updated by JMC4789 over 2 years ago

This commit also broke all of my beloved Datel games. However, the old builds couldn't run them due to other bugs, so your bisect has proved very useful.

Actions #6

Updated by JMC4789 over 2 years ago

  • Status changed from New to Accepted
Actions #7

Updated by phire over 2 years ago

Like all good dolphin regressions these days, this appears to be caused by a bug in the game.

I haven't actually debugged or REed the game, but this is what appears to happen:

When the player presses the button to start the race, the game goes to stop rendering it's menu and to render the loading screen instead. But it somehow messes this up, and it only disables the "end of drawing" handler for the menu renderer. The actual menu renderer continues executing, emitting new draw commands. Once it gets to the end of the menu draw, it doesn't issue an EFB copy, or even a SetFinish command. It immediately starts emitting draw commands for the same menu page.

If you record a fifolog of this transition with dolphin single core, patched to the old timings of 1600 cycles per draw, the fifo log contains a frame with 172,963 draw calls. As a standard menu frame is 227 draws (each draw is a single quad), it has redrawn the menu about 772 times.

What happens on real hardware: This same bug happens, and apparently the GPU timings are slow enough that the CPU fills the FIFO's circular buffer slightly faster than the GPU draws it. The FIFO high-watermark interrupt fires at some point, and whatever bug the game has is cleared. It finally emits a SetFinish command, then draws the loading screen. This all takes time, on real hardware, there is a roughly 1.5 second pause between when the menu background animation stops updating and the loading screen shows up. This hints at some kind of multi-threading bug.

What happens on dolphin: Well, dolphin's GPU timings are significantly faster than a real gamecube, in both single and dual core modes. The GPU drains the FIFO faster than the CPU pushed new draw calls into it, and the high-watermark interrupt never fires.


The only real solution to this is somehow slowing down the draws.

I don't like JMC47's suggested hack of enforcing a minimum of 1600 cycles for each draw, (it will probably cause issues elsewhere) but we might need to go that route, probably making it an ini file option. Since the game doesn't do anything else but draw, it must be the draw timings that are adjusted.

We could also bit the bullet and implement accurate GPU timings.

Or we could always go the route of patching the bug in the game.

Actions

Also available in: Atom PDF