Previous changes to the patch allowlist format were not reflected in AchievementManager; this corrects that and re-enables patches and codes in hardcore mode.
Host_RequestFullscreen and Host_UpdateMainFrame have been removed, and
Host_RequestRenderWindowSize has been used by DolphinQt since 80699096
and by Android since e8739156.
Remove Host_RefreshDSPDebuggerWindow (which hasn't done anything since
DolphinWX was removed in 44b22c90) and DSP::Host::UpdateDebugger (which
only called Host_RefreshDSPDebuggerWindow).
Remove Host_UpdateMainFrame(). The only non-empty call happened in
DolphinNoGUI which called s_update_main_frame_event.Set(), but
DolphinNoGUI never waits on that event.
When 9d9b6d8 changed our target SDK version to Android 16, it made
Android 16 stop calling onBackPressed and stop delivering KEYCODE_BACK
events. Dolphin's code isn't ready for that yet.
Android lets us opt out of this new behavior for now, so let's do so.
But the opt-out will presumably stop working once we start targeting
Android 17, so we're going to have to update Dolphin's code within the
next one or two years to support the replacement API.
Dual Core is primarily known as one of the first troubleshooting steps when emulation or NetPlay misbehave.
I believe(?) the original intent with having it on by default was likely to support users with weaker machines. However, I believe it would be a lot more reasonable for users to manually enable dual core if they really need the performance boost, rather than it is for them to have come ask us in support channel why their cleanly-installed Dolphin is not emulating their games properly.
Instead, this creates a fragile first impression where a clean install of Dolphin is already set up in a way that leads to inexplicable crashes, subtle timing bugs, and NetPlay desyncs.
Note: This changes only applies to the Desktop application, since mobile devices *do* really need the performance boost.
For thread safety, we shouldn't return any pointers or references that
can be used to mutate the state of the PPCSymbolDB. This should be the
final part of making PPCSymbolDB thread safe unless I've missed
something.
9395238 added locking in some PPCSymbolDB functions that access member
variables, but far from all. To ensure thread safety, this commit adds
the missing locking.
9395238 added a mutex to PPCSymbolDB, and made functions return with an
"empty" result if called while the mutex is locked. This new behavior
has the potential to affect not only less important call sites like the
symbol printing mentioned in a comment, but also the JIT deciding if it
should HLE a function.
A later commit in this pull request decreases the amount of lock
contention, reducing the performance impact of this commit.
