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>
Waterbox supports threads now, but they're not real threads on the host side because that's complicated and can be nondeterministic. Instead, everything is scheduled to share one host thread. This means that scheduling is actually cooperative and certain patterns of spinlocks and other nonsense can fail to work at all, but "regular" code probably will.
With this, add DobieStation PS2 core. This core was selected because it has threads and is otherwise simple to port; easy to build and a good core/frontend separation. It's not a wonderful core however, with low speed (made abysmally lower by our lack of real threads) and low compatibility, so it remains a curiosity for now.
nattthebear