Hi everyone,
I am writing here to give y'all on update on how things are progressing in my quest to eliminate desyncs from Dolphin TASes:
It took me my entire weekend, but I was finally able to get Dolphin 5.0 Stable to compile and run on my laptop. I had to completely purge any trace of Visual Studio's existence from my computer, download an offline installer for VS2015, and I had to add the line "#include <dxgi.h>" into the top of the file D3DQueuedCommandList.h to get around a linkage issue where a certain standard library data type wasn't being found... But the important thing is, now it works!
As of now, I have finished tracing which values are stored to a Dolphin savestate in Dolphin Stable 5.0, and the order/function call hierarchy that leads to each new piece of data. There are about 255 or so unique PointerWrap:: Do()-type calls that are gone through in saving a save state (ignoring the initial calls to measure how big the savestate will be, cases where a loop occurs, or where PointerWrap:: Do() calls another function which eventually calls some function like PointerWrap:: Do()). I have attached a file below which shows the type of each piece of data stored, which is indented to show the function call stack and to show where loops are. If anyone is interested in looking into this, you can take a look at the attachment (which also includes a small number of parts where I marked functions that I thought might be questionable).
For now, my main candidates for a desync cause are s_real_time_started_us and s_real_time_done_us in DVDThread:: DoState(PointerWrap P), since they are not saved to the save state or loaded from a savestate, which introduces the possibility that loading a savestate at certain points in time could mess up the system time (relative to what it should be when playing the TAS back from power on), which could alter the results of a variety of functions (most notably, the RNG function for many games), which could in turn potentially cause a desync.
However, time will tell if this is actually what's causing desyncs, or if it's just a red herring. In the meantime, if any other programmers want to help me out in this process or have any ideas they would like to share, I would be happy to listen! For now, I am moving on to my next step in my debugging idea: Trying to create a TAS which desyncs somewhere (consistently) after making a save state.
Dolphin_5.0_Savestate_Format.txt (Size: 17 KB / Downloads: 97)
I am writing here to give y'all on update on how things are progressing in my quest to eliminate desyncs from Dolphin TASes:
It took me my entire weekend, but I was finally able to get Dolphin 5.0 Stable to compile and run on my laptop. I had to completely purge any trace of Visual Studio's existence from my computer, download an offline installer for VS2015, and I had to add the line "#include <dxgi.h>" into the top of the file D3DQueuedCommandList.h to get around a linkage issue where a certain standard library data type wasn't being found... But the important thing is, now it works!
As of now, I have finished tracing which values are stored to a Dolphin savestate in Dolphin Stable 5.0, and the order/function call hierarchy that leads to each new piece of data. There are about 255 or so unique PointerWrap:: Do()-type calls that are gone through in saving a save state (ignoring the initial calls to measure how big the savestate will be, cases where a loop occurs, or where PointerWrap:: Do() calls another function which eventually calls some function like PointerWrap:: Do()). I have attached a file below which shows the type of each piece of data stored, which is indented to show the function call stack and to show where loops are. If anyone is interested in looking into this, you can take a look at the attachment (which also includes a small number of parts where I marked functions that I thought might be questionable).
For now, my main candidates for a desync cause are s_real_time_started_us and s_real_time_done_us in DVDThread:: DoState(PointerWrap P), since they are not saved to the save state or loaded from a savestate, which introduces the possibility that loading a savestate at certain points in time could mess up the system time (relative to what it should be when playing the TAS back from power on), which could alter the results of a variety of functions (most notably, the RNG function for many games), which could in turn potentially cause a desync.
However, time will tell if this is actually what's causing desyncs, or if it's just a red herring. In the meantime, if any other programmers want to help me out in this process or have any ideas they would like to share, I would be happy to listen! For now, I am moving on to my next step in my debugging idea: Trying to create a TAS which desyncs somewhere (consistently) after making a save state.
Dolphin_5.0_Savestate_Format.txt (Size: 17 KB / Downloads: 97)
