At its only usage point, its return value is stored into a u32, and the
default implementation returns 0xFFFFFFFF (-1), which would be an
unsigned integer. Given all of the bits are used to determine a color,
it makes slightly more sense to treat this as an unsigned value as
opposed to a signed one.
Changed itemSelectionChanged and itemClicked signal to itemPressed in CodeWidget.
Holding mouse down and moving will only travel up/down the stack one time.
This fixes the common occurrence of unintentionally traveling deeper down the stack or higher up the callstack than intended.
* Use font based sizing for row height. Fits more rows on screen.
* Adds whitespace for better formatting and minimum column width.
Helps prevent frequent resizing while scrolling.
Different address spaces can be chosen in the memory view panel.
* Effective (or virtual): Probably the view people mostly want. Address
translation goes through MMU.
* Auxiliary: ARAM address space. Does not display anything in Wii mode.
* Physical: Physical address space. Only supports mem1 and mem2 (wii
mode) so far.
Adds the Hardware Implementation-Dependent registers to the register
pane, which makes it much nicer to see which hardware-specific features
are enabled or disabled.
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).
