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.
The required version of MSVC already supports [[maybe_unused]], so we
can utilize this here. When GCC 7 and clang 3.9 become hard
requirements, we can eliminate this macro entirely and replace it with
[[maybe_unused]].
UNUSED is quite a generic macro name and has potential to clash with
other libraries, so rename it to DOLPHIN_UNUSED to prevent that, as well
as make its naming consistent with the force inline macro
This is much better as prefixed double underscores are reserved for the
implementation when it comes to identifiers. Another reason its better,
is that, on Windows, where __forceinline is a compiler built-in, with
the previous define, header inclusion software that detects unnecessary
includes will erroneously flag usages of Compiler.h as unnecessary
(despite being necessary on other platforms). So we define a macro
that's used by Windows and other platforms to ensure this doesn't
happen.
Instead of globbing things under an ambiguous Common.h header, move
compiler-specifics over to Compiler.h. This gives us a dedicated home
for anything related to compilers that we want to make functional across
all compilers that we support.
This moves us a little closer to eliminating Common.h entirely.
This makes it easier to generate random numbers or fill a buffer with
random data in a cryptographically secure way.
This also replaces existing usages of RNG functions in the codebase:
* <random> is pretty hard to use correctly, and std::random_device does
not give enough guarantees about its results (it's
implementation-defined, non cryptographically secure and could be
deterministic on some platforms).
Doing things correctly is error prone and verbose.
* rand() is terrible and should not be used especially in crypto code.
The definition of the function uses the ordering {mod, reg, rm}, which
is correct. Match the prototype to this, so that the parameter list
isn't misleading.
Gets rid of the need to set up memcpy boilerplate to reinterpret between
floating-point and integers.
While we're at it, also do a minor bit of tidying.
Given this is what occurs in both constructors (as one just passes
through to another), we can just initialize the member directly.
While we're at it, amend the struct to follow the general ordering
convention of:
<new types>
<functions>
<variables>
Given this is actually a part of the Host interface, this should be
placed with it.
While we're at it, turn it into an enum class so that we don't dump its
contained values into the surrounding scope. We can also make
Host_Message take the enum type itself directly instead of taking a
general int value.
After this, it'll be trivial to divide out the rest of Common.h and
remove the header from the repository entirely
This was added in 4bdb4aa0d1 back in
2009-02-27. The only usage spot of this macro involves the same checks
that were used to define that preprocessor macro, so we can simply
remove the macro
Only invoke config changed callbacks from Config::Save, not
Layer::Save. The latter results in callbacks being called
once per layer, up to 7 times per save.
- Move all of the ec functions into the Common::ec namespace.
- Give the public functions better names and some usage information.
- Move all of the "elt" related functions into an "elt" class including
all of the arithmetic operations, so that the logic becomes clearer
and feels less like assembly.
This also makes it much more obvious what the parameters are, instead
of only using unsigned char* (which doesn't tell anything about what
the pointer is used for or the size).
- Similarly, add a new "Point" class and move point functions there.
Overload the arithmetic operators to make calculations easier to read
The loops relied on unsigned integer overflow, which is not immediately
obvious. Replace them with less clever variants that are clearer.
Also implement bn_compare using std::memcmp.
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).
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")`.
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.
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.
