* 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
* zwinder state manager wip
* stuff
* fixes
* slightly better defaults
* stuff
* re-delete TasStateManager - re-added by my bad rebase attempt
* add back in saving of a default.tasproj, we are a lot of refactors away from not having to do this
* Make zwinder loadstate a factory method
* progress on wiring up Zwinder to movie shenanigans
* zwinder now survives save/load
* hack for settings to exist
* fix test
* shenangians for frame 0, add some asserts to the unit test
* Add crappy impl of integrity check for zwinderstatemanager
* remove Any() from the IStateManager contract, since it should always have at least 1 state
* move ZwinderStateManagerSettings to its own file
* use NonState, it's there and I suppose this was the intent
* add a test
* don't attempt to capture states if we aren't "currentt"
* ugh
* small cleanup
* ZwinderStateManagerSettings - implement necessary copy constructor
* wire up Settings updating, get rid of Settings setter, add some documentation to IStateManager
* shenanigans to fix Savestate settings UI
* Play around with "high priority"
It's really a mess because there's no information feeding between high priority and normal priority on what captures should take place...
* this fixes the branch gap problem
* bump tasproj version to 1.1, warn user and gracefully handle loading an incompatible version
* if a movie starts from savestate, stuff the anchored state into TasStateManager instead of a frame zero state
* ZwinderBuffer - remove some unused usings
Co-authored-by: nattthebear <goyuken@gmail.com>
RetroEdit