Previously, the file dialog window was ambiguous between saving or loading a .dtm. This commit simply gives a bit more context to differentiate the two windows.
Previously, when playing back a movie, you could not see the total frame count of a movie, only the total number of input polls.
This change simply shows the total frame count on movie playback.
Note that this change also results in the framecount and framecount total ALWAYS being displayed if show_movie_window is true, regardless of whether or not m_ShowFrameCount is true. I believe this is fine, as TASers are much more likely to reference the framecount than the input poll count.
Previously, only the number of total input polls would be shown in the window title when playing back a movie. This simply adds the VI / frame count total as well, which is a much more relevant number to look at while TASing.
If this commit is not applied, then the previous commit will cause hotkeys to be saved if there is a syntax error when hitting "OK" and the user presses the X to close the window.
This commit only applies changes to hotkey config if no syntax error occurs.
Previously you could type whatever gibberish you wanted into the formula bar, press OK, and receive a modal syntax error window. Closing the syntax error window would cause the hotkey config window to close as well, and your gibberish would be applied to the hotkey assignment.
This commit requires that a syntax error does not occur before accept() is called.
There are certain hotkeys that we absolutely want to be able to use
without being in-game. Presently, no hotkeys are recognized unless we
are in-game.
I've identified and moved the following hotkeys to be checked before the
HotkeyScheduler checks to see if the Core is running:
- Open
- Exit
- Start Recording
- Refresh Game List
Note that Play Recording should also be implemented here, however it
looks like there is no signal for a PlayRecording() function, so this
will have to be handled in a later PR once that signal is created and
implemented.
The purpose of this class was to keep track of state which the
emulation core was already keeping track of. This is rather risky -
if we update the state of one of the two without updating the other,
the two become out of sync, leading to some rather confusing problems.
This duplicated state was removed from EmulationState in the
previous commits, so now there isn't much left in the class.
Might as well move its members directly into EmulationFragment.
Previously, it was not clear where the boundary of the StickWidget was when interacting outside of the circle. This aims to restore the gray square present in the Wx-era.
Scott Mansell