Equivalent to a negation, no need to materialize the zero.
Before:
0x52800015 mov w21, #0x0 ; =0
0x6b1802b6 subs w22, w21, w24
After:
0x6b1803f6 negs w22, w24
This case can be handled as a move. It also generates a constant carry
flag.
Before:
0x52800013 mov w19, #0x0 ; =0
0x6b1302b3 subs w19, w21, w19
After:
0x2a1503f3 mov w19, w21
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.
Sintendo
JMC47
JosJuice
Dentomologist
Jordan Woyak
Admiral H. Curtiss
TryTwo
Tilka
Alex Harrison
AGuy27
CrossVR
Joshua Vandaële