Posts for ircluzar

Posted: 9/14/2017 3:01 AM
Quote
ircluzar
Experienced Forum User
Joined: 3/26/2015
Posts: 3
Location: Quebec, Canada
zeromus wrote:
In case it wasn't clear, this is not a negotiable subject. We will not be the vanguard of unreliable sloshy behavior r&d innovation for the thrill of gamers. That is the _opposite_ of our mission statement.
I understand perfectly your point of view towards the integrity of savestate data. I was simply looking to know if anyone knew a way to solve my issue or if it could be considered as an optional feature for a future version. This answers my questions. Thank you for the response.
Posted: 9/13/2017 1:48 AM
Quote
ircluzar
Experienced Forum User
Joined: 3/26/2015
Posts: 3
Location: Quebec, Canada
creaothceann wrote:
Copy the data to a buffer in RAM, then write the savestate from there using another thread?
That was my plan in case I don't get any other suggestions. I'm trying to edit as little BizHawk code as possible but I guess that if i don't have any other choice, that's what i'll have to do. Edit: Since my workaround is most likely going to be hacky, would it be possible that we get a proper implementation of non-hitching savestates in a future version?
Posted: 9/12/2017 8:58 PM
Quote
ircluzar
Experienced Forum User
Joined: 3/26/2015
Posts: 3
Location: Quebec, Canada
It seems that creating a savestates currently locks the emulation for a few milliseconds due to the code running in the emulation thread. This creates a noticeable hitch during gameplay if the savestate size is too big. Wrapping the method call in another thread causes corrupted savestates due to the memory changing while the savestate is being created. From my understanding of it, most of the hitch is caused while the savestate file is written on disk. Is there a quick solution for this issue? Note: I am still working with the 1.11.9 source (haven't upgraded yet) but it seems that this still happens in the current 2.x when doing an ALT+F1 during gameplay.