Previously, PowerPC.h had four macros in it like so:
\#define rPS0(i) (*(double*)(&PowerPC::ppcState.ps[i][0]))
\#define rPS1(i) (*(double*)(&PowerPC::ppcState.ps[i][1]))
\#define riPS0(i) (*(u64*)(&PowerPC::ppcState.ps[i][0]))
\#define riPS1(i) (*(u64*)(&PowerPC::ppcState.ps[i][1]))
Casting between object representations like this is undefined behavior.
Given this is used heavily with the interpreter (that is, the most
accurate, but slowest CPU backend), we don't exactly want to allow
undefined behavior to creep into it.
Instead, this adds a helper struct for operating with the paired singles,
and replaces the four macros with a single macro for accessing the
paired-singles/floating-point registers.
This way, it's left up to the caller to explicitly decide how it wants to interpret
the data (and makes it more obvious where different interpretations of
the same data are occurring at, as there'll be a call to one of the
[x]AsDouble() functions).
Since we use the common pipelines here and draw vertices if a batch is
currently being built by the vertex loader, we end up trampling over its
pointer, as we share the buffer with the loader, and it has not been
unmapped yet. Force a pipeline flush to avoid this.
This could happen with savestate loads, permission issues, or use by other processes.
Prior to this Dolphin assumed any existing file could be opened and crashes from invalid variant access.
Failing to open a file during savestate load will likely still crash but at least the user will know why.
This makes it possible to gracefully force stop emulation rather than
having to kill Dolphin completely when NetPlay deadlocks in the input
loop. Without a graceful stop, Wii saves do not get flushed to the main
NAND, and are left in limbo in the temporary NAND.
Doing pretty much anything in the controller config breaks NetPlay
(desync and/or deadlock), as saving the settings reconfigures
controller interfaces, which NetPlay doesn't expect.
This sends arbitrary packets in chunks to be reassembled at the other
end, allowing large data transfers to be speed-limited and interleaved
with other packets being sent. It also enables tracking the progress of
large data transfers.
The interface address isn't particularly useful in most circumstances
(playing over internet), and we have a way to get the external IP now,
so displaying it in the dialog is useful.
And use it for reporting games that rely on ICache emulation to some
degree. We know of a few but it would be interesting to get a more
exhaustive list from crowdsourcing.
