Project

General

Profile

Actions

Emulator Issues #8158

closed

Weird VPS/FPS desync on loads in Metroid Prime 3, Speedup Disc Transfer Rate avoids the issue

Added by hckrtz over 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
% Done:

0%

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

Description

Game Name?
Metroid Prime 3: Corruption (Metroid Prime: Trilogy)

Game ID?
R3MP01 (The European version)

What's the problem? Describe what went wrong in few words.
After a seemingly random time inside the game the background sound will hang up, this does not happen in MP1 and MP2 of the Trilogy.
It also seems possible that this hangup occurs before any background music started, resulting in silence.
When this sound hangup (repeating of the last second of the background music indefinitely) occurs a number of other things happen:
-The normal gameplay is not affected, other sounds like beam fire are still normal, saving works as well
-If there's some monologue incoming (for example from the Aurora Unit), it can not be heard, and despite clicking on 1 like indicated the monologue doesn't advance either, if the sound hangup is not present this works normally
-If the map can be opened through the dialogue after the error has occurred, it is glitched out, parts are missing and the objective seems to be shown in the wrong place, but when opened manually and normally the map is ok, even when the sound is hanging
-Some kinds of cut scenes seem capable of fixing the issue for the time being, like entering the ship and flying to a different zone
-Some other kind of cutscenes may hang up the game completely, requiring a restart, examples of those are:
--Calling Samus Ship into the Federation base for the missile upgrade (the view changes to the opened hangar doors but the ship doesn't approach, the environment is still 'alive' though)
--Defeating the first big boss (Mogenar) leads to a white screen if the sound error occurred during the fight
--If defeating the Mogenar worked without getting the issue, it's possible it occurs during the conversation with the Aurora Unit on Samus ship, here it froze the screen completely

What did you expect to happen instead?
The game to run normally obviously

What steps will reproduce the problem?

  1. Start the Trilogy and then start Metroid Prime 3
  2. Play the game normally and wait for the problem to occur

Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?
Dolphin-x64 - 5267 and Dolphin-x64 - 5308

Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
No older version I tried has worked normally for MP3.

What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)
OS: Win Server 2012 x64 (W8.1 x64)
CPU: AMD FX-8350 @ 4,5-4,8 GHz
GPU: AMD HD7970
RAM: 12GB DDR3-1600 Mixed Brand

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
Metroid Prime 1 and 2 run normally and I was able to complete them.

While in the main menu the log is being excessively flooded [several per second) with this message:
IPC_HLE\WII_IPC_HLE.cpp:370 W[WII_IPC_HLE]: Trying to open /dev/net/kd/request as 9

While playing MP3 the log is being excessively flooded [several per second) with this message:
IPC_HLE\WII_IPC_HLE.cpp:370 W[WII_IPC_HLE]: Trying to open /dev/net/kd/request as 13

Nothing else specifically arrives in the log when the sound hangup occurs. I have not yet initiated a game ending cutscene hangup while observing the log.

These log messages do not appear while playing MP1 or MP2

As I mentioned, it appears seemingly random, I have seen no factors which prevent nor provoke this issue.
I also have excessively tested through all settings, those which are adjustable for individual ISOs [like BAT/MMU], audio backends, different graphic backends...
turned all kinds of hacks and general settings on and off and even went through the pain of using the interpreter instead of the recompiler, all to the same result.
With JITIL however I do not even get the game started as of now [getting lots of these in the log: x64Emitter.cpp:1275 E[JIT]: Redundant MOV @ 000000001BC24B99 - bug in JIT?]

Actions #1

Updated by JMC4789 over 10 years ago

  • Status changed from New to Questionable

Games are known to sometimes hang when speedup disc transfer rate is enabled. You're using that setting to get around (another?) potential issues with disc transfer rates.

https://forums.dolphin-emu.org/Thread-wii-metroid-prime-trilogy--26043?page=22

Actions #2

Updated by hckrtz over 10 years ago

Yes I've used that setting, I previously thought though I got the hangup issue without SuDTR. I now played the game for 90 minutes or so without SuDTR and have indeed not encountered the sound hangup, however the FPS drops I experience without SuDTR are outright extreme, at times the FPS goes under 10 and sometimes takes more than 10 seconds to recover, which doesn't even begin to happen with SuDTR turned on.
So, whether I turn it on or off is just trading one serious problem for another.

The log flooding does however appear with all settings, I tested it again just to be sure, so there might be some relation to that issue behind that.

Actions #3

Updated by JosJuice over 10 years ago

Speed up disc transfer rate isn't supposed to be compatible with all games, so it's not surprising that something like this happens. One possibility is making fast disc speed eight times as fast as the regular disc speed (or something like that). We had that in the past, but then it was replaced with an infinite speed... I assume it was so that it could be used as a workaround for that old RS2 FIFO problem. Fixing the MP3 performance issue properly like I talked about in https://forums.dolphin-emu.org/Thread-wii-metroid-prime-trilogy--26043?pid=356629#pid356629 would obviously be better, but depending on how long that takes, maybe changing the speed of the speed up disc transfer rate option is a good idea in the meantime? I don't know if it will fix the problems described here, but it has a good chance to do so, and it's very unlikely to make it worse. It's a bit hacky, but it's not more hacky than it already is.

Actions #4

Updated by JMC4789 over 10 years ago

I confirmed this on speedup-disc-transfer rate. Thing is, There's a valid issue with regular disc speeds. I don't really want to close this for fear of forgetting that something is up. I'll ask this: Can you figure out what build began causing the really odd fps/vps desyncs when loading rooms?

Actions #5

Updated by hckrtz over 10 years ago

It'll take some time but I'll try them through and see if I can zoom in on the build which is responsible. As soon as I have something I'll post it.

Actions #6

Updated by hckrtz over 10 years ago

Okay, after some 2 hours of testing or so, here is what I found out:
5357 very strong FPS/VPS desync
5308 very strong FPS/VPS desync
5168 very strong FPS/VPS desync
4907 very strong FPS/VPS desync
4898 very strong FPS/VPS desync
4894 weaker FPS/VPS desync
4889 weaker FPS/VPS desync
4887 weaker FPS/VPS desync
4875 weaker FPS/VPS desync
4849 weaker FPS/VPS desync
4800 ES_LAUNCH error
4724 ES_LAUNCH error
4601 Less drastic slowdown, weaker FPS/VPS desync
4555 general strong slowdown, weaker FPS/VPS desync
4523 general strong slowdown, weaker FPS/VPS desync
4494 general strong slowdown, weaker FPS/VPS desync

So to conclude:
-SuDTR does help with evening out the terrible load times throughout all revisions, this is especially noticeable when opening the doors to really big or open rooms, where the game will freeze for 1 or 2 seconds without SuDTR turned on
-The mentioned FPS/VPS desync which seems most easy to be noticed right when the game starts in a save station seems to have been introduced with 4898
(I'm not sure the revisions 4897/4896/4895 exist as they don't appear in the download lists)

Actions #7

Updated by JMC4789 over 10 years ago

It's from the more accurate Disc Timings. Goddamn it. THere's something we're missing or something's wrong, is it what that guy that seems to know everything about the GameCube/Wii said, or could it be even more?

Actions #8

Updated by JosJuice over 10 years ago

Wait, so this isn't just a performance problem, it's something weirder? Why would FPS and VPS be desynced?

If you want to test if the VolumeWiiCrypted problem is what kills performance, PR 1969 is ready for testing: http://dl.dolphin-emu.org/prs/pr-1969-dolphin-latest-x64.7z

Also, I must ask... SuDTR didn't change anything when using 4.0-4894 or older, right?

Actions #9

Updated by hckrtz over 10 years ago

SuDTR DOES change the performance in earlier versions as well. I'll try to make it clear.
In version 4898 or newer there is a drastic desync which SuDTR fixes mostly. Without SuDTR the desync when loading in a savestation in Elysia is as drastic as 6 FPS to 50 VPS. If SuDTR is turned on then the worst desync I get is 30 FPS to 50 VPS, which is hardly noticeable.
In version 4894 or older there still is a slight desync, though it only goes down to 30 FPS to 50 VPS, like mentioned above, here however SuDTR on or off makes no further difference.

However there is the desync on the one side, and many severe slowdowns all throughout the game on the other side.
These severe slowdowns as far as I perceived it exist throughout ALL the revisions I tested, and throughout ALL of them SuDTR helps drastically, at the cost of potentially causing the mentioned hangups.

So SuDTR fixes two things, the desync (at least somewhat) and it also vastly improves the general performance. As I said, playing MP3 for an hour without SuDTR was a real pain. To make a comparison, with SuDTR there are no drastic slowdowns, unless a room is simply too complex, but even then it rarely goes below 40.
If I have SuDTR turned off it's like walking in syrup for half the game. These slowdowns do not happen with SuDTR turned on, whatever revision I use it's the same.

I also tested the latest revision, it seems to change nothing.

Actions #10

Updated by JosJuice over 10 years ago

That you say "SuDTR on or off makes no further difference" does make it sound like it doesn't have any effect on old versions... For Wii games, those versions should act roughly as if SuDTR is on (except for the game-breaking problems?), even if it actually is off.

PR 1969 hasn't been merged yet, so you won't be able to test it if you're using the latest revision. It would be useful if you tested it using the download link I posted earlier. Also, I realized this morning that PR 1854 would be useful to test too: http://dl.dolphin-emu.org/prs/pr-1854-dolphin-latest-x64.7z

Actions #11

Updated by JMC4789 over 10 years ago

JosJuice: If the game can't load fast enough, as I learned in EXI changes, the FPS will drop but the VPS will remain full speed. I think your more accurate disc timings may be too slow for this particular game.

Actions #12

Updated by JosJuice over 10 years ago

Actually, the reason I suggested PR 1854 is that I suspect that the DI commands are taking so long time that they are blocking other WII_IPC_HLE commands from being executed. The PR changes this so that DI commands don't block other commands at all, by bypassing the WII_IPC_HLE scheduler. I don't think that the disc speed itself being too slow is the problem, because the Metroid Prime games just prevent doors from being opened when data is being read, they don't make everything lag. However, that the problem is that WII_IPC_HLE commands are being blocked is just a guess from my side, so maybe PR 1854 won't help at all...

Actions #13

Updated by JMC4789 over 10 years ago

Let me cc MaJoR, our resident Metroid Prime expert.

Actions #14

Updated by hckrtz over 10 years ago

"PR 1969 hasn't been merged yet, so you won't be able to test it if you're using the latest revision."
Ah, sorry, I meant I tried that link as well as the newest revisions, just didn't write it properly. PR 1969 didn't help.
SuDTR did improve the performance of all master versions so far. It's only that with the recent ones it also helps with the desync.

So if I got that right then the expected behavior is that the game should run pretty much the same with or without SuDTR, which it currently does with NO revision of the master branch, right?

That's what I get with PR 1854, I think your guess might be spot on! Trying this one is a really drastic performance improvement over all other version I tried, and the desync is also gone.
And finally I do see what you all seemed to be hoping to see, SuDTR does not make any real performance difference anymore. After a bunch of test runs from the Save Station A in Elysia to the Spire Dock I got no real lagspikes, and in most of those test runs the game worked even perfectly, apart from a tiny surefire lagspike when doors open, but that's barely noticeable if you don't pay close attention to it.
The only difference SuDTR now makes is that the doors open instantly, but you know, they didn't do that in the Wii version either. It'd be cool to make that possible without inducing other bugs, but that's not really the point here, nor is it any important.

So yeah, PR 1854 seems to be fixing the issue.

Actions #15

Updated by JMC4789 over 10 years ago

  • Status changed from Questionable to Fix pending

Thank goodness. You were very helpful in your testing.

Fixed in PR 1854. Needs to be a higher priority to get merged.

Actions #16

Updated by JosJuice over 10 years ago

  • Regression set to Yes
  • Relates to performance set to Yes
  • Milestone set to Current

Huh, so that WII_IPC_HLE theory turned to be true after all...! It feels a bit odd that that PR fixed an issue I didn't even know existed when I wrote it, but hey, it's great that it works.

The expected behavior when turning SuDTR on and off is that the loading times will differ, that there might be some minor performance differences, that games might break if it's on, but that weird FPS drops like this never will happen. The only case where all behavior is completely identical regardless of the setting is in 4.0-4894 and older, and that's only because it wasn't implemented at all for Wii games back then. The behavior you describe in PR 1854 sounds exactly like the way Dolphin should be working right now.

Actions #17

Updated by hckrtz over 10 years ago

Glad to hear that, I tried my best to supply as much detail as possible.
And well, as I said above the log is always being flooded with these [IPC_HLE\WII_IPC_HLE.cpp:370 W[WII_IPC_HLE]: Trying to open /dev/net/kd/request as 13] messages when playing MP3, so I guess that also was related to this.

On my way of playing Metroid Prime 3 I might find and post more bugs some time [already saw a few weird but much less dramatic bugs], but first I'll wait for this fix to end up in the master branch and then I see if I find anything else.

Also the help was really fast and nice, dolphin and you guys are awesome :)

Actions #19

Updated by JosJuice about 10 years ago

  • Status changed from Fix pending to Fixed

Right, I need to actually mark it as fixed too...

Actions #20

Updated by hckrtz about 10 years ago

Haha, awesome. Can't wait to get back to playing and testing :)

Actions

Also available in: Atom PDF