Bounding Box: Newer versions of Dolphin use hardware optimized implementations of bounding box, which produce different results at different resolutions and graphical settings, as well as being tied to specific hardware. To avoid this while using the latest versions, use the Direct3D backend with Microsoft Basic Renderer (as to be hardware agnostic), or use version 4.0-5124 or older to use the older software based bounding box solution.
It's been a couple years since the OP was made. Has there been any change in this front? Has anybody asked the Dolphin team to restore the software based bounding box solution? Reason that I ask is that my hardware is too slow to run Dolphin full speed with Microsoft Basic Renderer. Even using Intel graphics is a lot faster (my laptop uses i5-7300HQ and Nvidia Geforce 1050)
Bounding Box: Newer versions of Dolphin use hardware optimized implementations of bounding box, which produce different results at different resolutions and graphical settings, as well as being tied to specific hardware. To avoid this while using the latest versions, use the Direct3D backend with Microsoft Basic Renderer (as to be hardware agnostic), or use version 4.0-5124 or older to use the older software based bounding box solution.
It's been a couple years since the OP was made. Has there been any change in this front? Has anybody asked the Dolphin team to restore the software based bounding box solution? Reason that I ask is that my hardware is too slow to run Dolphin full speed with Microsoft Basic Renderer. Even using Intel graphics is a lot faster (my laptop uses i5-7300HQ and Nvidia Geforce 1050)
No, nothing has changed.
But keep in mind that only a very small number of games use bounding box:
Disney's Hide & Sneak
Disney's Magical Mirror starring Mickey Mouse
Disney's Mickey & Minnie Trick & Chase
Paper Mario: The Thousand-Year Door
Speed Challenge: Jacques Villeneuve's Racing Vision
Super Paper Mario
Ultimate Spider-Man
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
How can you tell if a game uses one of those features?
Joined: 1/24/2018
Posts: 251
Location: Stafford, NY
Xander wrote:
JosJuice wrote:
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
How can you tell if a game uses one of those features?
The Dolphin Wiki has the information about what games use what features, if any.
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
If the game doesn't use bounding box or some other GPU readback feature like EFB copies to RAM or EFB access from CPU (Super Mario Sunshine says hi), you can use whatever hardware, backend and enhancements you want without worrying about desyncs.
How can you tell if a game uses one of those features?
The Dolphin Wiki has the information about what games use what features, if any.
It actually doesn't have that information for the most part. All of the wiki's recommended settings assume that you already have the settings that are forced by the default game INIs that ship with Dolphin. So what you should do instead is to look for the default game INI for your game: https://github.com/dolphin-emu/dolphin/tree/master/Data/Sys/GameSettings
07:10:33 <Warepire> feos: The Dolphin smart Idle skipping PR might have broken determinism in Dolphin
07:10:42 <Warepire> (it was merged recently)
07:10:55 <Warepire> It should be noted somewhere.
EDIT:
This has been sorted out and should be added to the OP I think?
Dolphin revisions from 5.0-10039 to 5.0-10093inclusivelyshould not be used for TASing due to non-determinism exposed by tweaks to idle skipping. It was fixed in 5.0-10095.
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.
Just a info about the Dual Core option:
I know it must be off to sync the movie (playback), but its essential to be disabled during the record as well? I mean, it doesnt work if you TAS with Dual-Core ON and then turn it OFF before playback the movie?
Dolphin revisions from 5.0-10039 to 5.0-10093inclusivelyshould not be used for TASing due to non-determinism exposed by tweaks to idle skipping. It was fixed in 5.0-10095.
This determinism problem is just that TASes made on Windows won't sync on other operating systems, and vice versa. So while not using the versions that has that problem would be preferable, it is still possible to TAS on them. (Also, the problem technically existed before 5.0-10039 but wasn't as exposed back then.)
Darth Marios wrote:
Just a info about the Dual Core option:
I know it must be off to sync the movie (playback), but its essential to be disabled during the record as well? I mean, it doesnt work if you TAS with Dual-Core ON and then turn it OFF before playback the movie?
The dual core setting must be set to the same value when playing back as when recording.
And to be accepted the TAS has to sync with dual core off no matter if it was off or on during the TASing process
The requirement is just that the TAS syncs. You can actually get TASes to sync with dual core nowadays, but you couldn't do it in Dolphin 5.0 stable (barring special settings). While single core is still recommended for TASing, if you've managed to make a TAS that syncs fine on dual core, I don't see why that would prevent it from being accepted.
This determinism problem is just that TASes made on Windows won't sync on other operating systems, and vice versa. So while not using the versions that has that problem would be preferable, it is still possible to TAS on them. (Also, the problem technically existed before 5.0-10039 but wasn't as exposed back then.)
I'm not saying it's not working, I'm saying it shouldn't be used for movies meant for TASVideos, because not a lot of judges and publishers can run both OS's.
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.
Since 5.0-11318, MMU must be explicitly enabled for TASes.
Go to Config -> Advanced and tick Enable MMU.
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.
Question about SRAM: assuming you want to TAS more than one game, what you have to di with SRAM? Have to backup for each game or just delete it everytime? I mean: movies and savestates then keep handle the RNG values when playback on a new sram?
Builds from 5.0-11231 until 5.0-13180 have audio/video desync in AVI dumps, first frame will be missing. If the first frame repeats, all its duplicates will also be missing. It can't be fixed on user end. Use older or newer versions.
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.
Joined: 9/12/2014
Posts: 536
Location: Waterford, MI
Good news and bad news: the good news: the annoying save/load state problem has been fixed in upstream somewhere! Bad news is: now the simpsons hit and run game desyncs where I don't know how to consistently reproduce yet. I was making an encode while it was playing back. I didn't test without making encode.
[Edit] tried switching from Vulcan to opengl to see if there was any difference, opengl seemed to sync fine. But I switched back to Vulcan to test another movie and it synced there too. I guess it was just some unlucky desync where in input was dropped. Oh well. Its what we can expect with newer consoles. I've heard some games are very prone to desyncs.
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 talked to the man who announced a new version of savestates for Nintendo Wii 2 years ago and asked him why he had dropped the implementation of it.
Here is what he replied to me.
Hi, the problem with saving the entire filesystem is that loading the save state would lead to the user silently losing everything that has been written to the FS after the save state was made... Considering that's not how GameCube save states work and the fact it would affect entirely unrelated saves for other games as well, I feel uncomfortable making that change so consider it abandoned for now. Another issue is that it would bloat the size of save states and make them a lot slower as the Wii NAND can store ~512MB of data...
It might be possible to only enable full FS snapshots in TAS mode, but that still requires some thought to design it well and ensure the UI lets the user know that save states would work differently in TAS mode
So, to sum up, the desync problem with Wii TASes isn't likely to be fixed in the near future.
If you have some ambitious plans about TASing Wii and Wii Ware games, please consider the fact that you can LOSE your progress because of desyncs if you play your movie from the beginning or even from a recent savestate!
Even though the GameCube TAS movies are not safe as well, they are much more stable comparing to Wii movies where saves/loads were used.
TASing is like making a film: only the best takes are shown in the final movie.
Since 5.0-11318, MMU must be explicitly enabled for TASes.
Go to Config -> Advanced and tick Enable MMU.
Just to clarify, is this post saying that MMU must be enabled for all future TASes on Dolphin? Or just that if you want to enable MMU for your TAS, you have to check it off in the settings?
MMU must be explicitly enabled for all future TASes on Dolphin.
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.
If they were started before it, then MMU was still on by default. Also it's not like we're banning anything, it's just to ensure sync (after it was disabled by default as seen in the commit I linked).
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.
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.
