This is to avoid several issue with using 2 actions and switching between them. This commit will instead have one action get his property changed on pause and play.
Paired single (ps) instructions can call asm_routines that try to update
PowerPC::ppcState.pc. At the time the asm_routine is built, emulation has
not started and the PC is invalid (0). If the ps instruction causes an
exception (e.g. DSI), SRR0 gets clobbered with the invalid PC.
This change makes the relevant ps instructions store PC before calling out
to asm_routines, and prevents the asm_routine from trying to store PC
itself.
Moves the codebuffer access variables closer to their first use, and
gets rid of multiple indexing expressions. We already know which op
we're accessing in particular, so just make a reference to it and access
it instead of duplicating the expression all over the place.
A call like ReplaceAddress(address, 0) is pretty ambiguous; so is
ReplaceAddress(address, false), so use an enum class that tells people
straight-up what the replacer is.
This also gets rid of the really weird naming, where if 'blr' is true,
we'd be replacing the address with a NOP, rather than an actual BLR
instruction, so we invert that so it actually makes sense. There's no
actual bug fixed here though, considering the OnInsert functions
specified the correct values; it's literally just weird naming.
Without this macro, if any signals or slots were attempted to be used,
they wouldn't work; neither would various other features of the Qt
meta-object system. This can also lead to weird behavior in other
circumstances. Qt's documentation specifically states:
"Therefore, we strongly recommend that all subclasses of QObject use the
Q_OBJECT macro regardless of whether or not they actually use signals,
slots, and properties."
on its page for "The Meta-Object System", which can be seen here:
https://doc.qt.io/qt-5/metaobjects.html
Let's opt for "always do the right thing", and keep the code extensible
for the future and not have random things blow up on us.
Makes the enum strongly typed. A function for retrieving the string
representation of the enum is also added, which allows hiding the array
that contains all of the strings from view (i.e. we operate on the API,
not the exposed internals). This also allows us to bounds check any
querying for the strings.
Export and ExportAll now open a directory picker (that defaults to the
previous default directory, i.e. the Dolphin user dir).
Also removes the need to return the path in the export functions since
the user knows which path they chose.
This moves the result dialogs to DolphinQt2, since WiiSave should not
really be responsible for interacting with the user as a simple
Wii save importing/exporting class.
This also fixes Wii save import/export showing result dialogs twice,
once from WiiSave, and another time from DolphinQt2.
Move the import/export operation into separate functions, as it doesn't
really make sense for the constructor to do *everything*, including
printing success/failure message boxes.
The existing constructor was split into two: one that takes a path,
and another taking a title ID. This makes it more obvious what is
actually done when a path/TID is passed and also clarifies what
parameters should be passed. (No more magic 0 or "" value.)
It only needs to be updated when we changes the symbols, not every time the code widget updates and it does take a while to update them so this fixes some delay when updating the code window.
Putting the columns to resizeToContents causes way too much resizes per updates which can cause severe lags and even crashes. This only does one resize at the end of the columns.
One, which was also possible in Wx is to add an mbp after the core stopped which shouldn't be possible as it needs to add the memcheck on the core thread which wouldn't be running. The other fix is Qt specific where it doesn't clear the breakpoints on stop.
The items were editable while you cannot edit the breakpoints at the moment and the last breakpoint deleted would not cause the row count to change to 0.
This allows avoiding two copies of the executable data being created in
the following scenario (using pseudocode):
some_function()
{
std::vector<u8> data = ...;
DolReader reader{data};
...
}
In this scenario, if we only use the data for passing it to DolReader,
then we have to perform a copy, as the constructor takes the std::vector
as a constant reference -- you cannot move from a constant reference,
and so we copy data into the DolReader, and perform another copy in the
constructor itself when assigning the data to the m_bytes member
variable. However, we can do better.
Now, the following is allowable as well:
some_function()
{
std::vector<u8> data = ...;
DolReader reader{std::move(data)};
...
}
and now we perform no copy at any point in the reader's construction, as
we just std::move the data all the way through to m_bytes.
In the case where we *do* want to keep the executable data around after
constructing the reader, then we can just pass the vector without
std::move-ing it, and we only perform a copy once (as we'll std::move
said copy into m_bytes). Therefore, we get a more flexible interface
resource-wise out of it.
Not only it colors the entire row instead of just the address, but if the pc is the selected row, the pc color will overwrite the selection, this is done via a stylesheet.
This commit makes the colors hardcoded except when there is no symbols loaded, in which case, it uses the theme colors, except for the PC which is hardcoded to black on green. This makes a compromise between making use of the corespoinding theme color and the text being nicely readable on all themes.
This aligns the values to the right since It looks odd to be aligned to the left with any format other than hexadecimal. It also sets the font tot he debugger font and disallow selection as a previous commit made the selection pointless since it now relies on the current item.
It seemed impossible to SELECT an item, however, when right clicking, the CURRENT item is set to the appropriate cell, this commit makes the view use thta cell instead of the first selected one.
This makes it possible to use enums as the config type.
Default values are now clearer and there's no need for casts
when calling Config::Get/Set anymore.
In order to add support for enums, the common code was updated to
handle enums by using the underlying type when loading/saving settings.
A copy constructor is also provided for conversions from
`ConfigInfo<Enum>` to `ConfigInfo<underlying_type<Enum>>`
so that enum settings can still easily work with code that doesn't care
about the actual enum values (like Graphics{Choice,Radio} in DolphinQt2
which only treat the setting as an integer).
Dolphin doesn't use any of the WC24 files, so this can be done when
actually starting emulation in WiiRoot. The benefit of moving the
copy is that we don't need to handle temporary NANDs in a special way.
{Initialize,Shutdown}WiiRoot should only be responsible for setting the
SESSION_WII_ROOT or managing the temporary NAND directory.
Move all the content manipulation out of these functions to ensure
separation of concerns and call them after/before WiiRoot init/shutdown
to make sure they operate on the correct root.
If we don't flush the values, they persist in the register cache,
potentially resulting in the values being out of sync with PPCSTATE.
This was causing random crashes in games, mainly booting, when certain
JIT instructions were disabled, or forced to fall back to interpreter.
This excludes the second argument from template deduction.
Otherwise, it is required to manually cast the second argument to
the ConfigInfo type (because implicit conversions won't work).
e.g. to set the value for a ConfigInfo<std::string> from a string
literal, you'd need a ugly `std::string("yourstring")`.
This can be considered a hack, but it essentially neuter the bias applied on boot for both console on the RTC. This avoids having the time on boot be changes significantly while the user would want a specific RTC and it also avoids possible underflow of the RTC if it is near the epoch.
GetHandle() should really not even be part of IOFile's interface, but
since it is (for the time being), we can cull unnecessary usages of it.
In this case, the WriteBytes() function does what we need without using
the underlying handle directly.
This allows getting rid of casts. We can also leverage std::min to allow
making relevant variables const. Also make the "empty" table const to
allow it to be read-only.
Converts them from 0 == success, 1 == failure to using the built-in
standard bool. Also while we're at it, const qualify write_sector's
"sector" parameter, since nothing in the function modifies the data
being pointed to.
Avoids needing to iterate and append the characters in one case. This also
alters the function to not need to construct a temporary std::string
(QString's toUtf8() is sufficient, as QByteArray exposes iterators).
toStdString() is equivalent to retrieving the QString's underlying
QByteArray via calling QString's .toUtf8 member function and then
calling .toStdString() on the result of it (discarding the QByteArray
afterwords), so this just trims off an unnecessary step in the process.
This is also somewhat more indicative of the conversions going on:
toStdString() converts the underlying character sequence of a
QString to UTF-8, not strict ASCII, so we're really using a superset of
ASCII.
Also move it to MathUtils where it belongs with the rest of the
power-of-two functions. This gets rid of pollution of the current scope
of any translation unit with b<value> macros that aren't intended to be
used directly.
Change SettingsHandler to take a buffer instead of assuming that the
setting file to read is always on the host filesystem for more
flexibility and make it possible to use the new filesystem interface.
aldelaro5