I guess the 16383 came from looking at the code, but 16383 is a limit on the number of states (which also needs to be increased, TODO) not how many frames back those states go. There is effectively no limit except numerical calculation limits on the target frame length; if you had room for only 10 savestates, but wanted to cover a 10 million frame range, we'd just save once every million frames
All of the cool and quirky stuff it did was solely to support waterbox, which has its own native impl of this now. So now it just lets you allocate memory and change protection on it. Boring. Note that the slot based callback system in waterbox gives constant function pointer addresses inside the box, so it doesn't matter where exactly CallingConventionAdapter is allocated.
* Clean up truncate behavior and docs. Fixes#2285
To start with, 770ddc26db (6 years ago, prior to 1.7.0) made the documentation of how truncate is supposed to work. However, judging by my testing of 1.9.0 and 2.4.2, it probably hasn't ever worked that way in practice. It seems justified to change the documentation to match the behavior that the user is familiar with, and what I see as the commonsense behavior anyway (I can justify this further if anyone is curious).
Note this is not changing the behavior of truncate itself; it is simply documenting what the behavior has always been.
Secondly, Invalidate was modified to become InvalidateAfter. This modifies how it gets called, but otherwise remains mostly identical internal to the Zwinder. This was done to make it easier to reason about relative to the input log, which should be the foundation for an understanding of related components.
* zwinder: "frame after" interpretation in all Invalidate methods
Pretty sure this only affected Mono. The infinite loop in ProgramRunLoop
continued even after the form was disposed (in the testing I did, this was
always during the call to CheckMessages). However, DisplayManager (actually
GlobalWin.DisplayManager) was cleared during disposal, so the call to
DisplayManager.UntransformPoint rightly threw an NRE. After this change, the
"real" stacktrace is still printed as always.
First of all, use a try..finally pair around the mutating calls to make it clear that Config.PreferredCores will always be rolled back, and to the correct value, after the operation is done.
Then, assume that when Movie.Core is set, we always want to prefer that core... no matter what system comes up. Seems to fix#2259
This lets us support mapper32k_w without needing extra hacks. Because of lazystates, this doesn't hurt us on state size either (lazystates did not exists when we did 722358c1b1
typically changing the submodule paths wrecks repositories. you can try to repair it by deleting the directories and doing "git submodule update --init --recursive" from the bizhawk root. In my experience, git GUIs may mess something up here
nattthebear