Emulator Issues #12615open
Speed Challenge: Jacques Villeneuve's Racing Vision Hangs
Speed Challenge: Jacques Villeneuve's Racing Vision
Game ID? (right click the game in the game list, Properties, Info tab)
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
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.
Is the issue present in the latest stable version?
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.)
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)
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.
Updated by phire about 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.