Previously, s_temp_input was being used for BOTH the savestate's and the movie's input printout in the panic alert.
This commit simply performs memcpy from the correct vector for the movInput printout.
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.
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.
Special shoutout to Android for not having RTL compatible
variants of nextFocusRight and nextFocusLeft.
Ideally we would have some way to block the user from using
the d-pad to switch between the two panes when in portrait mode,
or make the list pane act as if it's to the left of the details
pane rather than the right when the details pane is open, but I
don't know of a good way to do this. SlidingPaneLayout doesn't
really seem to have been implemented with d-pad navigation in mind.
Thankfully, landscape is the most important use case for gamepads.
sowens99