For one I do not think the term "SRAM" or even "SaveRAM" really means a lot to most people. So a more obvious term through the site could be better.
A new and clearer term would especially be appreciated for Dolphin, as the GameCube stores game progress on flash memory in memory cards but also has an SRAM chip that stores console-wide settings. Normally when TASers say "SRAM" they mean game save data, but that usage of the term doesn't make sense on its face when talking about the GameCube.
While you may be able to get around disc drive inconsistencies with this, you're unfortunately left with all the same problems as the N64. GameCube emulation currently doesn't have CPU and GPU timing accuracy anywhere near what would be required for console verification, and all GameCube games I know of configure the hardware to regularly poll controllers automatically, so you can't detect lag frames.
Oh, interesting, I had thought such things were already quite advanced for GameCube. In your estimation, how far off is it? Like, for NES for example even a relatively inaccurate emulator can generate console verifiable runs a good fraction of the time, would the same be true with GameCube? Maybe there are games that spend a lot of time in an idle loop for example that would stand a chance?
Well, I don't know how games work internally well enough to say how much they are affected by Dolphin's inaccuracies, but the fact that Dolphin updates are continually breaking sync for old movies is indicative enough.
Getting any major improvements to the timings is probably many years into the future. Emulating all the caches and pipelines correctly is difficult not only in terms of the research required to accurately emulate them, but also in terms of how demanding it is to run.
Maybe something like this can lead to the possibility of Gamecube verifications down the road (admittedly cheating a bit but would still be cool.)
While you may be able to get around disc drive inconsistencies with this, you're unfortunately left with all the same problems as the N64. GameCube emulation currently doesn't have CPU and GPU timing accuracy anywhere near what would be required for console verification, and all GameCube games I know of configure the hardware to regularly poll controllers automatically, so you can't detect lag frames.
That was done on the official Dolphin build 4.0-4222. The submission was rejected because it desynced for literally everyone, not because a bad Dolphin version was picked.
With that said, do I hope this new TAS is using a more recent version than the 8 years old 4.0-4222!
I'm assuming that the new post indicators are the "yellow document" icons that I'm seeing now? If so, they don't seem to be clickable, which makes them a lot less useful than in the old forum.
As of today, they are clickable! \o/
Now I can browse the forums just like I'm used to. Thank you!
funnily enough that i was originally using the stable version and the rom simply didn't work on that one so i installed the latest one instead
This is not a good sign! Please check that you have a good dump of the game. If the game is in the NKit format, your DTM files are not sync compatible with good dumps of the game and will not be accepted for publication here.
linny356 wrote:
would my dtms work on that version too?
No, DTMs are not sync compatible between 5.0 and recent versions.
I don't really see how using a cheat code could be considered more legitimate than just uploading a save file with no verification movie. Everything that can be done by editing a save file manually can be done using Gecko codes. So if you're going to allow Gecko codes as long as the end result is the same as from legitimate play, you could also allow hacked save files as long as the end result is the same as from legitimate play.
Just because a cheat is available through Dolphin doesn't necessarily mean it's "safe", by the way. I know of casual players who have softlocked their saves because of cheats they found through Dolphin. I don't have any concrete examples of cheats that would mess things up for a New Game+ run, but I don't want to assume that there aren't any such cheats.
It's unfortunately not useful enough that I can go back to my old way of using the site where I used the new post indicators. (Manually finding where the unread posts start in each thread I open is too bothersome.) But I found that using "Posts since last visit" is an alright way to use the site once I realized I could log out and then back in as a way of making the "last visit" tracking actually work. So, even though my old workflow doesn't work anymore, I do have a workflow that I can use.
I'm curious, though: What criteria is used by this new last visit tracking to determine what counts as a new visit? Hopefully this new addition means that I can skip the step of logging out and back in each time I'm done catching up on posts. (Not that doing that workaround takes more than a few seconds.)
I'm assuming that the new post indicators are the "yellow document" icons that I'm seeing now? If so, they don't seem to be clickable, which makes them a lot less useful than in the old forum.
Previously each subforum had a little bubble with a white paper/sheet inside that turned yellowish if there were new posts in the subforum since last visit--this visual indicator was much faster to read at a glance than the new implementation of "15 minutes ago," "15 days ago," and "12/18/2021, 1:30pm."
Previously at the bottom of the forums was a "Mark All Read" button, which would in turn change all the sheet bubbles to white, giving an easy way to check on a daily basis what posts had happened, and investigate subforums as necessary. I relied on both of these features a lot... their absence in the new layout is going to drive me away from the site. :(
I relied heavily on this feature too. I can live with using "Posts since last visit" instead of having the icons, but I can't seem to find any way to actually clear that view along the lines of what "Mark All Read" used to do... Which means I have to try to memorize which page I was at when I last visited the site.
I've used the torrents a few times. But considering that archive.org is the only one I've ever seen seeding, I don't really have any reason to like HTTP downloads less. To me the two work about equally well, and if the torrents were removed I personally wouldn't mind.
The rules currently say that "You are allowed to start with premade in-game save data (SRAM) for categories that require it". In other words, if you could play the category of your choice without premade save data, you're not allowed to use it. I believe the pre-rewrite rules had a rule which was similar but worded differently.
The site has gotten a few submissions of games where starting from a completed save lets you play through the game from the beginning while being allowed to skip lengthy animations or skip cutscenes. While using a premade save in this way doesn't add any content, I feel like skipping non-gameplay parts of the game can make a TAS more entertaining to watch, and it also removes an arbitrary time advantage that RTA runs currently have over site-eligible TASes. Is this something that would make sense to change in the rules?
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?
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.
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).
But TASes sync just fine with MMU disabled, don't they?
For reference, MMU was only enabled by default in 5.0-6568 to 5.0-11318. Versions older than that had MMU disabled unless you manually edited INI files.
Mario Kart Wii polls for inputs multiple times per frame. By having (gamecube) controller 1 pressing half of the inputs, and controller 2 pressing the exact negative of those inputs, the game cancels out the inputs and reads only half the size on all following frames (until power off), so by inputting all possible inputs on 2 controllers on the next frame (which will fill up double the amount of space - so 4 controllers), you can use the third controller to read past the 4 controllers’ memory region and into “garbage” data. After the input region of memory are the event and save regions. Because an event is already occurring (power on -> menu screen), changing these values will only affect the screen itself until the event that’s running is already over, as long as the value is changed by the time the event is over. What I do is run an event in the background, unlocking each individual aspect that goes towards having 100% of the game unlocked, which writes to the save region after the event memory, meanwhile on certain frames that I need to actually input A. I do so on the rewritten double scaled input table, so it turns out I have to actually hold 64 input units right on the C stick of controller 1. The unlock events only occur for one frame so by doing one event every frame I can unlock all required things before the power on -> menu screen event finishes. I finally finish by proving that everything is unlocked by creating the new license and returning to the main menu screen with B (which involves pressing 64 input units left on the control stick of controller 1 due to the doubled input range).
Is this a real bug, or you just made it up, and the entire reason this even occurs is the gecko code?
For the record, "[cav-disc-drive] 4.0-3964-dirty" is not an official release of Dolphin and I don't know if it's sync compatible with any official release. (Development versions which are listed at https://dolphin-emu.org/download/ are official releases.) However, if there is any official release it is sync compatible with, it is sync compatible with 4.0-4222. The source code for the cav-disc-drive build can be found here: https://github.com/dolphin-emu/dolphin/commit/c6e695b2450821f5913b76fb467e89e23c567a06
That's not the newest version, but it is recent, and I'm not aware of anything in particular in it that's broken. I don't get a crash when I start recording input in it.
If you currently have dual core enabled, try disabling it. And if you're starting recording in the middle of the game, try doing it before starting the game instead. I'm not sure if this will help, but dual core and savestate-anchored movies are usually troublesome.
