As an aside, one dolphin developer mentioned in IRC that it was slightly more likely for a movie made with MMU enabled to desync as compared to a movie with MMU disabled. I'm not sure how much of a difference this makes (and it sounds like it only effects certain games), but I just wanted to bring that up here for consideration...
for the laypeople, could people explain in the thread what MMU means, what it does, how it affects sync, and why it was alternately on and off by default between revisions
Alright, I'll try my best to explain.
The short version of what Dolphin's MMU setting does is it makes the emulation of memory accesses more accurate. For some games this is 100% required for the game to work at all, but for most games it largely doesn't matter. In some cases, actions which case a crash on a real console may not cause a crash in Dolphin unless MMU is enabled, or the symptoms of the crash might be different (you might get an error popup from Dolphin instead of the game printing debug info to the screen, for instance).
It is definitely possible to get TASes to sync with MMU disabled. I've heard reports that you're more likely to get desyncs if you have MMU enabled (or only if the game you're playing requires MMU to be enabled?) but I'm not certain. The one thing I can definitely recommend regarding MMU and syncing is: The MMU setting should have the same value when recording the movie as when playing back the movie. Saying that MMU must be enabled when making a movie to avoid desyncs makes no sense as far as I can tell, so unless someone can explain the reasoning behind that statement I think it should be disregarded.
For the longest time, the MMU setting was off by default and could only be turned on by manually editing INI files. Because Dolphin's game settings system automatically enabled MMU for all games that required MMU in order to run, there wasn't much reason for users to enable MMU for other games, considering that enabling MMU came with a performance penalty. However, eventually the performance penalty of MMU emulation on x86-64 became rather small, and it was decided to enable MMU by default on x86-64 only, with a checkbox available in the GUI just in case. Later still it was discovered that while the sustained performance was about the same, a few games had problems with lag spikes due to the JIT cache needing to be cleared more frequently when MMU is enabled, and due to this we decided to no longer enable MMU by default. Of course, this matters less to TASers than to normal users.
So, in short: Enabling MMU does not help you avoid desyncs when recording, but enabling it may cause Dolphin to emulate crashes more accurately, which (in certain edge cases) helps ensure that whatever glitches you're exploiting in the game actually work on a real console. The most important things to do for ensuring sync is checking that the TAS syncs for yourself and writing down what settings you used (including the MMU setting).
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Turns out I hallucinated what it was about. Accuracy, not sync!
[20:38:54] <Warepire> feos: https://github.com/dolphin-emu/dolphin/pull/8348 This got merged, so the TASing requirements on Dolphin must be updated.
[20:39:13] <feos> I forgot what it affects
[20:39:38] <Warepire> Basically, glitches in games may no longer behave according to console
[20:39:57] <feos> huh?
[20:40:52] <Warepire> You're not going to get any memory mapping faults etc with the MMU disabled, so if a glitch reads outside of memory, the result will be different
[20:41:07] <Warepire> Also glitches requiring game crashes etc
[20:41:29] <feos> hold on
[20:42:31] <Warepire> https://en.wikipedia.org/wiki/Memory_management_unit
[20:42:35] <feos> different from console, right? not different every time
[20:42:43] <Warepire> Yes, different from console
[20:43:14] <Warepire> We want to be as close to console as possible, so we must require full MMU on.
[22:43:23] <TASVideoAgent> New reply by feos (GC/Wii: Updated important information for TASing with Dolphin): http://tasvideos.org/forum/p/489664#489664 [a:1]
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Alright, if you want to require the MMU setting to be enabled for accuracy reasons, then that makes sense. Though it would be good if it was written down in a better place than some post in page two of this topic.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Updated the OP, please verify the wording.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
The wording is correct. On second thought it probably makes more sense to say "causes Dolphin to" instead of "may cause Dolphin to", but that's not exactly a big problem.
I wonder, though: What if someone makes a Dolphin TAS without enabling MMU because they didn't see this topic, or because they're using 5.0 stable and therefore thought that this doesn't apply to them? Would such a TAS be rejected?
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Only if it uses a heavy glitch that is entirely an emulation error, usually relevant for major skip glitches.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I don't know if anyone has the same problem as me, but replaying a movie for Wii games stops at the first frames (48).
Sometimes it warns me that the checksum does not correspond to the game, which is not possible because it is indeed the game and the corresponding film.
On the other hand, no problem with movie playback for GameCube games.
I retested with the latest development version and it's the same.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
CasualPokePlayer on Discord wrote:
Since 5.0-5700, a hardware bug of the GameCube was emulated revolving the sample rate. This resulted in the sample rate being changed to 32029/48043Hz. This however was inaccurate, as the GC actually outputs at a non-integer sample rate. Rounding to an integer backfired here, as these sampe rates do not have an even CPU cycles per sample rate. So the code ends up actually outputting different sample rates, which were several hertz off (32024.2488139/48040.3301537Hz). Since 5.0-16788, this has been corrected, so the correct sample rates are output and this discrepancy no longer exists (32028.4697509/48042.7046263Hz). However, wav files can only store an integer sample rate in their header, so while the code outputs an accurate sample rate, it is rounded off in the wav header (or more so it's now less than a hertz off from reality).
This program resolves the issue by simply taking wav files and resampling them back to 48000Hz. It will be able to correctly identify the true sample rate from any Dolphin wav file, including pre-5.0-5700 builds. Usage is simple, if you only have a single file you can just drag and drop the file in. If you have multiple files (i.e. split due to changing sample rates) you can give all of them at once, and it will concat them together. The order used is the order given, so you probably want to make a simple batch script to give all the files, e.g.
Of course, anything before 5.0-5700 along with Wii games on any Dolphin version do not have this issue, so this program isnt super useful. It can be used just for concatting multiple audio files together, but that's already possible with AviSynth anyways.
https://github.com/CasualPokePlayer/fix-gc-audio/releases/tag/v1.0
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Looks like the stability situation for Wii TASing was improved in Dolphin 5.0-17850. Here's that PR discussion, which focuses on various scenarios, including TASing, and a respective Dolphin issue was closed.
No Wii TASes have been submitted with this Dolphin version or newer, but this gives hope more complex Wii games would be stable when TASing, as broken savestates is the main reason why TASes go out of sync.
Wii also now has MotionPlus support for TAS since 5.0-18878, so the games like Red Steel 2 can now be TASed.
There are a handful of Dolphin issues which might be actual even today:
https://bugs.dolphin-emu.org/issues/7219 (GC savestates inaccuracy)
https://bugs.dolphin-emu.org/issues/9721 (DSP LLE + Memory Card is desync-prone)
https://bugs.dolphin-emu.org/issues/9722 (savestate inconsistency with LLE)
https://bugs.dolphin-emu.org/issues/9689 (settings changes are not tracked for playback)
https://bugs.dolphin-emu.org/issues/10357 (Wii aspect ratio problem for TAS Input)
TASing is like making a film: only the best takes are shown in the final movie.
