In 9d348c9c8 I copied these verbatim, but half of the non-alphanumeric keys were
wrong. I passed 0..0xFFFF to MapWin32VirtualScanCodeToVirtualKey to get what I
assume are the correct values, though it's possible they're per-machine, in
which case the whole alt. mode feature is broken. There are a few keys that
remain commented-out because I didn't find their scan code, notably numpad 0-9.
These are used for realtime and recorded AV output. They match closely what the core actually does (not idealized values about what the NES framerate ""should"" be.)
Fixes#2460
fixes b01f52c01; this required a whole lot of rearchitecting for one obscure
feature which will become obsolete with the move to .NET Core anyway, and I'm
not happy about it
The interface is a single method plus the four constants from the top of Sound,
which are now properties. The static methods in Sound are moved to extension
methods on the interface.
* StateManager - switch from SortedSet to List<int> + duplicate checks. Seems to make raw capture speed to be slighly slower, but greatly speeds up invalidate which speeds up painting
* Add SortedList<T> : ICollection<T> which wraps List<T>
More interfaces can be added as needed. There's an indexer though ICollection
doesn't specify one.
* Update SortedList<T>
* StateManager - use SortedList<int>, seems to offer raw unthrottled drawing speed with no drawbacks, painting is still smooth when there is a high number of states
* remove a space
* Add RemoveAfter to our SortedList for efficiency
* fix unit tests to use [DataRow]
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
Co-authored-by: RetroEdit <30182911+RetroEdit@users.noreply.github.com>
This reverts commit bb0e92a830.
I can't build again. e.g:
Unable to move file "..\..\output\BizHawk.WinForms.Controls.dll" to "../../output\dll/BizHawk.WinForms.Controls.dll". Cannot create a file when that file already exists.
We've failed twice now. Please give a rationale for why we have to move these files around.
Without this commit, choosing "Cancel" from a tool form's "Save changes?" dialog
(i.e. AskSaveChanges) while trying to load a rom from `File` > `Recent ROM`
would treat that recent rom as though it were missing. With this commit, an OSD
message is displayed instead.
This isn't the best fix. The return value from LoadRomInternal isn't even used
anywhere apart from LoadRomFromRecent, which is the only place the new out param
is used.
Having GBA be a console mode is more straightforward for users to understand and a more logical way of arranging options. GBA is literally a console mode, not an additional modifier to a console mode.
Change the status of alternate GB/C firmware options to unacceptable. Quoting from CasualPokePlayer "Gambatte is definitely not emulating those cpus [dmg0 and cgb0]. So you would end up with quirks of newer cpus being combined with bootroms only present in older cpus."
Also fix what looks to be a longstanding typo where the PCFX BIOS v1.01 was not being properly detected.
* Fix SGB core picker which was broken
* Restore default SGB core choice of SameBoy
In 2.4.2 and before, SameBoy was implicitly the default, but this makes the choice more explicit and the core picker UI properly show the chosen core when nothing has been selected yet.
* Cleanup core picker UI gen
* Remove now defunct SgbUseBsnes option from Config
Co-authored-by: RetroEdit <30182911+RetroEdit@users.noreply.github.com>
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
* post-build step moves .exes up a level, to output
* also fixed OpenTK.dll.config location
* also removed redundant step from packaging scripts
* future executables need to be capable of resolving assemblies in dll
Fixes#2215
* Make marker/branch columns use ColumnType.Text
One step towards fixing multiselect for markers and branches
* Disable some input operations while TasView is unfocused
This prevents accidentally deleting inputs while branches or markers are selected.
The non-weird init in ToolManager can't pass in the ctor because 1. Config is
written to in Restart as well as Load and 2. it's a base class and that's not
how ctors work and I should know this
Mednafen has extra aliases of enum values that we don't need here and were confusing the system. Now, NGP no longer has three different "English" options for language.
Internal Mednafen code expects MDFN_GetSettingB ("bool") to work with enum values, so long as those enums are 0 and 1, but we weren't handling that.
Fixes#2385
Mednafen has extra aliases of enum values that we don't need here and were confusing the system. Now, NGP no longer has three different "English" options for language.
Internal Mednafen code expects MDFN_GetSettingB ("bool") to work with enum values, so long as those enums are 0 and 1, but we weren't handling that.
Fixes#2385
A2600 standard controller and A7800 standard controller were using the same
keybinds, now only Atari2600Hawk uses those and A7800Hawk's are blank unless
configured manually or configured on config regen
The main point is referencing types directly instead of iterating them by
reflection and also calling their ctors by reflection.
(disclaimer: [DisplayName] attrs are still necessarily read by reflection)
The only forms that did anything special with their window title were Basic Bot,
CDL, Hex Editor, Log Window, MainForm, and TAStudio. That behaviour is in
WindowTitle, while the rest use WindowTitleStatic.
The implementations of WindowTitleStatic in those six forms are new. There's a
checkbox in `Config` > `Display...` > `Misc` to disable their special behaviour
and use the new static titles.
The Text property is hidden from Designer de/serialisation as well.
* split TargetedPairSchema ctor and added docs to clarify its behaviour
* renamed VirtualPadTargetScreen.RangeX/RangeY to MaxX/MaxY
* left TODOs in the three places MaxValue was actually used
* Cleanup NormalizeAxes
no behaviour change yet
* Use a more sensible scaling algorithm in NormalizeAxes
* Replace AxisSpec.FloatRange with AxisSpec.Range (ints)
* Use 0..255 for GBA light sensor, and set its Mid to 0 (fixes#2323)
* Revert "mgba - try resetting sram memdomain after frame advance, so sram autodetection can progress and feed into frontend. addresses #1620, maybe not in the best way"
This reverts commit 25327b510d. We decided exposing the whole buffer would be better than dealing with a variable size memory domain.
* mGBA: Update SaveRAM mem domain to a hardcoded size.
* TAStudio import: ask before saving the bk2
* Only save cycle count at movie end; fixes#2203
* Rework the movie end cycle count warning.
* TAStudio import: allow saving even if no changes are detected
These all seem to have been made from the point of view of testing every possible value the UI allowed, and then fixing them all with as little effort as possible, with the fixes going deep in core logic instead of in the validation layer, and the fixes not making anything really "work"; just making it stop complaining.
ZWinderBuffers now require TargetFrameLength >= 1 again: A value of zero doesn't make much sense here, and didn't actually behave differently than 1.
ZWinderBuffers now require Size > 0 again: A size 0 buffer will never capture anything and has no value. If you don't want a buffer, don't make one at all. I believe that omitting some buffers might make sense for the state manager, maybe; those more familiar with all of its uses will have to chime in. If that is the case, then the state manager should not instantiate buffers it does not plan to use.
ZWinderBuffers now throw exceptions again when a single state is bigger than the entire buffer: If you're in this situation, things are phenomenally broken and your buffer is never going to capture anything successfully. Users need to fix their settings in this case; they don't need to have a completely non functional system silently claim to work while not doing anything, leaving them befuddled as to why seeking is taking forever.
size 0 means 0 states will be captured; TargetFrameLength 0 means no spacing of states (result behavior is identical to TargetFrameLength of 1; capture every frame)
* 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.
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
* 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.
(Align didn't seem to make any sense, it was just weighting priority less towards the current frame. Perhaps helpful in some situations, but I don't think enough so to justify complicating the decay algorithm. Either way it was a misnomer and I don't know what there is to align to.)
YoshiRulz