Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
Using SDL_INIT_JOYSTICK implies SDL_INIT_EVENTS which installs a signal
handler for SIGINT and SIGTERM. There will be a way to prevent this in
2.0.4 but for now we'll need to handle SDL_QUIT.
This should be restructured to move the connection logic into Core
instead of duplicating it in every Host, but alas, I'm too lazy for
that right now. ~flacs
Core::Shutdown was only called on app exit, yet the emu thread exits
whenever emulation stops; if you launched a new game it would just join
via the destructor when s_emu_thread was set to a new thread.
(Incidentally, the destructor also makes explicitly joining on app exit
rather pointless.)
Because the GUI thread wasn't waiting for the CPU thread to fully shut
down, Core::IsRunning would remain true briefly after CFrame::DoStop
which, given Dolphin's penchant for accessing variables belonging to
other threads, can only mean trouble... In my case, because the previous
commit caused UpdateGUI, which is called at the end of DoStop, to call
PauseAndLock, which checks IsRunning, pressing stop at the right time
would cause strange behavior.
The UI should decide on where it wants the user directory, not our core system.
This is in anticipation of some upcoming work on Android which will need proper user directory setting.
Before this change I always got this when closing dolphin-emu-nogui:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 10 (X_UnmapWindow)
Resource id in failed request: 0x3400003
Serial number of failed request: 215
Current serial number in output stream: 219
terminate called without an active exception
Aborted
The person who wrote this seemed to misunderstand how XPending and
XNextEvent actually work. XNextEvent will wait in poll if there's
no event yet, meaning that we don't need to sleep after we process
all the events; the kernel will sleep for us.
This changes indentation, so view with -w or a similar feature to
understand what's actually changed here.
The concept of a "title bar" / "status bar" shouldn't be a core concept,
so remove the Host_UpdateStatusBar function, and move the code handles
whether to update the status bar or titlebar into DolphinWX.
Now that MainNoGUI is properly architected and GLX doesn't need to
sometimes craft its own windows sometimes which we have to thread back
into MainNoGUI, we don't need to thread the window handle that GLX
creates at all.
This removes the reference to pass back here, and the g_pWindowHandle
always be the same as the window returned by Host_GetRenderHandle().
A future cleanup could remove g_pWindowHandle entirely.
Our existing code was relying on the GLX backend to create the GLX
window properly, and for the rest of the code to patch that up, sort
of. If we rely on Host_GetRenderHandle() returning a valid window, we
can do a lot better about this.
Create a simple window inside MainNoGUI to make this happen.
Now, the only supported EGL platform is Android. We might eventually add
back support for EGL/X11 or EGL/Wayland, but it will have to be
architected differently.
Yes, this is a fancy new feature, but our Wayland support was
particularly bitrotten, and ideally this would be handled by a platform
layer like SDL. If not, we can always add this back in when GLInterface
has caught up. We might be able to even support wxWidgets and GL
together with subsurfaces!
This was actually never used as far as I can tell. There was no wx event handling done whatsoever for the global ID, So this is basically a dead function.
EmptyChaos