This is slightly safer than writing contents to /title directly.
We still cannot rename everything in one go atomically, but this allows
implementing AddTitleCancel very easily.
Also, this ensures that when a title import fails, no incomplete files
will be left in the title directory, which can mess up the system menu.
Regression introduced in e99cd57 / 4935: VideoBackends: Set the maximum
range when the depth range is oversized[1]. The NV_depth_buffer_float
extension is not part of OpenGL 3.0, and requiring it causes a hard
crash when it's not supported (e.g. macOS).
[1]: https://github.com/dolphin-emu/dolphin/pull/4935
This moves all the byte swapping utilities into a header named Swap.h.
A dedicated header is much more preferable here due to the size of the
code itself. In general usage throughout the codebase, CommonFuncs.h was
generally only included for these functions anyway. These being in their
own header avoids dumping the lesser used utilities into scope. As well
as providing a localized area for more utilities related to byte
swapping in the future (should they be needed). This also makes it nicer
to identify which files depend on the byte swapping utilities in
particular.
Since this is a completely new header, moving the code uncovered a few
indirect includes, as well as making some other inclusions unnecessary.
Getting and setting configuration from the base config layer are common
and repetitive tasks. This commit adds some simpler to use functions to
make the new system easier to work with.
Config::Get and Config::Set are intended to make switching from
SConfig a bit less painful. They always operate on the main system.
Example usage:
// before
auto base_layer = Config::GetLayer(Config::LayerType::Base);
auto core = base_layer->GetOrCreateSection(Config::System::Main, "Core");
u8 language;
core->Get("Language", &language, 0);
SetData("IPL.LNG", language);
// now
auto base_layer = Config::GetLayer(Config::LayerType::Base);
auto core = base_layer->GetOrCreateSection(Config::System::Main, "Core");
SetData("IPL.LNG", core->Get<u8>("Language", 0));
// or simply
SetData("IPL.LNG", Config::Get<u8>("Core", "Language", 0));
Given a std::map can't have duplicate keys, iterating over the map
explicitly isn't necessary, and find() can just be used instead.
Also, instead of manually calling push_back() for every entry to
be added, the range constructor of std::vector can be used instead to add
the whole range all at once.
We (the Microsoft C++ team) use the dolphin project as part of our "Real world code" tests.
I noticed a few issues in windows specific code when building dolphin with the MSVC compiler
in its conformance mode (/permissive-). For more information on /permissive- see our blog
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/.
These changes are to address 3 different types of issues:
1) Use of qualified names in member declarations
struct A {
void A::f() { } // error C4596: illegal qualified name in member declaration
// remove redundant 'A::' to fix
};
2) Binding a non-const reference to a temporary
struct S{};
// If arg is in 'in' parameter, then it should be made const.
void func(S& arg){}
int main() {
//error C2664: 'void func(S &)': cannot convert argument 1 from 'S' to 'S &'
//note: A non-const reference may only be bound to an lvalue
func( S() );
//Work around this by creating a local, and using it to call the function
S s;
func( s );
}
3) Add missing #include <intrin.h>
Because of the workaround you are using in the code you will need to include
this. This is because of changes in the libraries and not /permissive-
The built-in `configure_file` command correctly handles the case where
none of the variables change and scmrev.h doesn't need to be rebuilt.
This saves a full re-link of Dolphin any time CMake is re-run.
This reimplements the USB HID v4 IOS device using the new common
USB code (to reuse more code and allow emulated HIDs to be added
more easily in the future).
The main difference is that HIDs now have to be whitelisted, like
every other USB device for OH0 and VEN.
libusb on Windows is limited to only a single context. Trying to open
more than one can cause device enumerations to fail randomly.
libusb is thread-safe and we don't use the manual polling support (with
`poll()`) so this should be safe.
Markus Wick