* TAStudio: Fix deletion crashing when deleting invalid indexes
The problem occurs when trying to delete a selection where some of the frames were valid, but the last displayed line (which is currently an extra non-input frame) was in the selection.
* LINQ alignment tweak
When a missingfirmwareexception is encountered, do not fallback. It's presumed that these cases are fixable by the end user.
Absolutely does not in any way fix#2327 - the user was emphatic that they had the BIOS file, so they must have hit some other situation.
* rename highpriority to ReGreenZone, and add a comment, to better document what it is used for
* rename again, from regreenzone to gapFiller, rename settings too, make gap frame length 1000 instead of 10000
* oops
* merge original state with ancient, since we can never invalidate frame 0 anyway, it can safely be stored here
* unremove nonstate
* change ancient to reserved, in preparation for marker and branch states to go here, add more comments
* capture branch states as reserved, reconsider gap logic to account for the fact that a reserved state might be greater than the last current/recent state
* do not capture to reserved states if the state is already rreserved
* add a callback to check if a state is "reserved", client code wil return whether it is a branch or marker state. Wire up reserved logic into eviction logic. If reserved, go to reserved list, else evict
* add API for evicting reserved states, and wire it up to marker removal
* just in case
* a bit of renaming, add a unit test for an edge case that was broken with the Last property, add unit tests to cover it
* Revert "a bit of renaming, add a unit test for an edge case that was broken with the Last property, add unit tests to cover it"
This reverts commit b0d01ffacb058eb26c68a7fdccb0010d3bca40b2.
* fix AllStates using Concat() and OrderBy(), add unit tests for HasState and GetStateClosestToFrame()
* Fix InvalidateAfter and add tests
* make HasState() a lot faster
* durp
* convert reserved to a Dictionary
* fix count being off by 1 due to no longer correct assumption of there being a separate frame zero state
* a few cleanups
* clean up tests and use less ram, fix a few things that I broke that unit tests caught, yay unit tests
* implement IDisposable and use in unit tests
* fix SaveCreateroundTrip (for me at least), by using a smaller buffer allocation, also be pedantic and use zw.Settings in zw2 to ensure they match
* some tests for Count
* attempt to cache which states have frames, doesn't work, ZwinderBuffer on the last state before it wraps, doesn't behave as I expect, dunno if it is intended
* fix typo when evicting recent to reserved, cleanups, make unit test work
* oops
* cleanup and account for Gaps in unit test
* use StateCache for HasState, fix unit test accordingly
* use statecache to check if a frame exists during Capture, and do this first, before gap logic
* fix reserved logic in Clear, add a unit test for Clear
* fix Engage bug that was breaking loading movies, remove CaptureReserved from the API and instead, call the reserved callback in Capture
* use state.Size to minimize memory thrashing in AddToReserved()
* cleanup some comments
* when loading a tasproj from disk, build up the state cache, without this commit, loading an existing movie was unuseable
* reserve the frame before markers, not hte marker itself, users expect instant navigation to markers, and since we always navigate 1 frame before the target frame to emulate and get a frame buffer, this is the frame that must be reserved
Did this as a separate commit because it seems like the intent was for
OwnerEmulator to be mutable, though it was only ever set immediately after
creation. Revert to make it mutable again.
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.
YoshiRulz