Begins the transition to using fmt for string formatting where
applicable. Given fmt supports formatting std::string instances out of
the box, we can remove now-unnecessary calls to .c_str() and .data().
Note that this change does not touch the actual logging subsystem aside
from converting the final StringFromFormat call in the process over to
fmt::format. Given our logging system is heavily used throughout the
entire codebase, and converting that over will be quite a large change
by itself, this will be tackled near the end of the conversion process.
Avoids dragging in IniFile, EXI device and SI device headers in this header which is
quite widely used throughout the codebase.
This also uncovered a few cases where indirect inclusions were being
relied upon, which this also fixes.
Allows for both string types to be non-allocating. We can't remove the
const char* overload in this case due to the fact that pointers can
implicitly convert to bool, so if we removed the overload all const
char arrays passed in would begin executing the bool overload instead of
the string_view overload, which is definitely not what we want to occur.
Since C++17, non-member std::size() is present in the standard library
which also operates on regular C arrays. Given that, we can just replace
usages of ArraySize with that where applicable.
In many cases, we can just change the actual C array ArraySize() was
called on into a std::array and just use its .size() member function
instead.
In some other cases, we can collapse the loops they were used in, into a
ranged-for loop, eliminating the need for en explicit bounds query.
Prior to this commit, the emitter would emit a 7-byte instruction when
loading a 32-bit immediate to a 64-bit register.
0: 48 c7 c0 ff ff ff 7f mov rax,0x7fffffff
With this change, it will check if it can instead emit a load to a
32-bit register, which takes only 5 or 6 bytes.
0: b8 ff ff ff 7f mov eax,0x7fffffff
std::call_once is guaranteed to execute the given callable object
exactly once. This guarantee holds even if the function is called
concurrently from several threads.
Given that, we can replace the mutex and boolean flag with
std::call_once and a std::once_flag to perform the same behavior.
Previously, every entry pair within the map would be copied. The reason
for this is subtle.
A std::map's internal entry type is defined as:
std::pair<const Key, Value>
but the loop was declaring it as:
std::pair<Key, Value>
These two types aren't synonymous with one another and so the compiler
is required to always perform a copy.
Using structured bindings avoids this (as would plain auto or correcting
the explicit type), while also allowing the use of more appropriate
names compared to first and second.
std::function is allowed to heap allocate in order to hold any necessary
bound data in order to execute properly (e.g. lambdas with captures), so
this avoids unnecessary reallocating.
While current usages of ParseLine aren't problematic, this is still a
public function that can be used for other purposes. Essentially makes
the function handle potential external inputs a little nicer.
We can just utilize map's insert_or_assign() function and check the
return value to determine whether or not we need to insert the key into
the keys_order vector.
All supported platforms now have easy access to a compiler with C++17
support.
C++17 potentially allows for some nice cleanups and removes the need
for standard library backports (optional/variant).
See discussion at https://dolp.in/pr6264#discussion_r158134178
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.
MemoryWatcher only works on Linux and affects emulation determinism due
to scheduling additional events, which causes NetPlay to desync.
Considering that this interface is a rather specialized use case, the
communication with it is kinda crappy *and* it's affecting emulation, I
think it's best to just axe it and come up with a better implementation
of the functionality.
* The high half of regOp is immediately overwritten so the value in it is irrelevant.
* MOVSD produces an unnecessary dependency on the high half of regOp.
* MOVAPS is implemented as a register rename on modern microarchitectures.
There is no reason to use MOVAPD over MOVAPS, for two reasons:
* There has never been a microarchitecture with separate single and double domains.
* MOVAPD is one byte longer than MOVAPS
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.
Switch to using additional overloads of sf::Packet, so we can eliminate
some of the messy code and just use the normal syntax for
BigEndianValue.
We can't avoid helper functions with u64 due to SFML's non-standard way
of defining 64-bit integer types.
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de 00 movabs rax,0xdeadbeef
7: 00 00 00
With this change, it will instead rely on the fact that on x64 writes to
32-bit registers are automatically zero extended to 64-bits, allowing
us to emit a 5 or 6-bytes instruction with the same effect for certain
immediates.
0: b8 ef be ad de mov eax,0xdeadbeef
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de ff movabs rax,0xffffffffdeadbeef
7: ff ff ff
With this change, it will instead emit a 7-byte instruction when it is
possible to express the 64-bit immediate using a signed 32-bit value.
0: 48 c7 c0 ef be ad de mov rax,0xffffffffdeadbeef
The LogManager code had trouble detecting the "/Source/Core/" substring
for two reasons, neither of which seemed to happen a few years ago:
1. __FILE__ is in lowercase on MSVC
2. __FILE__ uses backslash as the directory separator on MSVC
Fixes https://bugs.dolphin-emu.org/issues/11366
Similar in nature to e28d063539 in which
this same change was applied to the x64 emitter.
There's no real requirement to make this const, and this should also
be decided by the calling code, considering we had places that would
simply cast away the const and carry on
Added an option in General config to enable/disable usage statistics. Added a popup on first open if
the user would like to engage in reporting. Clicking cancel or out of the box opts out. Only
clicking 'Ok' will enable reporting. Also added a new android specific values to report.
Type punning like this is undefined behavior. Instead, we use std::memcpy to
copy the necessary data over, which is well defined (as it treats both
the source and destination as unsigned char).
This adds the functionality of sending the host's save data (raw memory
cards, as well as GCI files and Wii saves with a matching GameID) to
all other clients. The data is compressed using LZO1X to greatly reduce
its size while keeping compression/decompression fast. Save
synchronization is enabled by default, and toggleable with a checkbox
in the NetPlay dialog.
On clicking start, if the option is enabled, game boot will be delayed
until all players have received the save data sent by the host. If any
player fails to receive it properly, boot will be cancelled to prevent
desyncs.
Previously these were required to be built into the executable so that
the JIT portion of the DSP code would build properly, as the
x86-64-specifics were tightly coupled to the DSP common code. As this is
no longer the case, this is no longer necessary.
Makes the enum values strongly-typed and prevents the identifiers from
polluting the PowerPC namespace. This also cleans up the parameters of
some functions where we were accepting an ambiguous int type and
expecting the correct values to be passed in.
Now those parameters accept a PowerPC::CPUCore type only, making it
immediately obvious which values should be passed in. It also turns out
we were storing these core types into other structures as plain ints,
which have also been corrected.
As this type is used directly with the configuration code, we need to
provide our own overloaded insertion (<<) and extraction (>>) operators
in order to make it compatible with it. These are fairly trivial to
implement, so there's no issue here.
A minor adjustment to TryParse() was required, as our generic function
was doing the following:
N tmp = 0;
which is problematic, as custom types may not be able to have that
assignment performed (e.g. strongly-typed enums), so we change this to:
N tmp;
which is sufficient, as the value is attempted to be initialized
immediately under that statement.
In cases where we just want a random value for a primitive arithmetic
type, we can wrap this in a template to allow convenient direct
assignment instead of keeping declaration and initialization separate
(making it more difficult to use values uninitialized). This also allows
the use of Common::Random with functions such as std::generate, making
it more flexible in how random values can be generated.
ChunkFile doesn't use any of the file utilities, so we can drop these
headers to avoid pulling in unnecessary dependencies. This also
uncovered a few indirect inclusions.
