This new setting is like Override Language on NTSC Games, except
instead of only applying to the GameCube language setting,
it also applies to the Wii language setting.
Fixes https://bugs.dolphin-emu.org/issues/11299
This variable isn't std::moved anywhere and is just read out of into a
string. Instead of making a copy, and then another copy of the data into
a std::string, we can take it by reference, only copying the data once.
This isn't std::moved wholesale into a member variable or further
std::moved into another function, so it's better to take it by const
reference here to avoid unnecessary reallocations of contained
std::string instances.
Moves it closer to where its used, narrowing its visible scope, as well
as preventing unnecessary std::string constructor executions in the
event invalid data is encountered (the continue branch).
std::function is allowed to heap allocate in order to store captured
variables, etc, so std::function isn't a trivial type. We can std::move
here in order to avoid potential reallocating.
While we're at it, make the definition's parameter name match the
declaration's parameter name for consistency.
If the parameter is const, then a move won't actually be able to occur,
making the std::move non-functional. We can remove the const qualifier
to remedy this.
...in addition to the existing function CreateVolume
(renamed from CreateVolumeFromFilename).
Lets code easily add constraints such as not letting the user
select a WAD file when using the disc changing functionality.
Unfortunately, it appears that using libusb's synchronous transfer API
from several threads causes nasty race conditions in event handling and
can lead to deadlocks, despite the fact that libusb's synchronous API
is documented to be perfectly fine to use from several threads (only
the manual polling functionality is supposed to require special
precautions).
Since usbdk was the only real reason for using a single libusb context
and since usbdk (currently) has so many issues with Dolphin, I think
dropping support for it in order to fix other backends is acceptable.
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.
The pack is already has its validity checked at the beginning of the
function, so we don't need to check this again after inserting it.
Also resolves a use-after-move case.
Same behavior but doesn't take up 8 bytes in the executable to store a
pointer. While we're at it, move it into an anonymous namespace within
the UICommon namespace.
We already check ahead of time if the optional contains a value within
it before accessing it, so we don't need to use the throwing value()
accessor. We can just directly use operator->
Rather than construct strings twice, we can just construct it once and
reuse it. While we're at it, we can move variables closer to where
they're actually used within DownloadDefaultCover()
* Simplifies libusb context usage and allows us to set options for
all contexts easily. Notably, this lets us enable usbdk support
in libusb, which is now opt-in in the latest version.
* Moves the libusb config descriptor wrapper class to LibusbUtils too
since that could easily be reused.
* Moves device listing to LibusbUtils too and add a lock around it
as some libusb backends are not thread safe.
* Consequences: only a single context and a single event handling
thread is used now, which is more efficient.
This allows the same code to be used to read into a std::string, which
allows for eliminating the vector->string transfer when reading the
manifest file.
A ContiguousContainer is a concept that includes std::array,
std::string, and std::vector.
Makes it way harder to introduce resource leaks, and plugs the existing
resource leaks in the constructor and Install() where the file wouldn't
be closed in some error cases.
Because the GC language setting cannot be set to Japanese, we
need a special condition for Japanese GC games. I accidentally
removed it in PR 7816, but here it is again in a new form.
We could do the same thing with Korean GC games if we want to
(which we couldn't do before PR 7816), but due to how spotty
GameTDB is with having Korean names for Korean GC releases,
things will be more consistent if we just use English for them.
We can't join a detached thread, so NetPlayIndex gets deleted before
the notification thread exits, creating a race condition. We switch to
using Common::Event because just sleeping leaves the UI hung on the
thread join for a few seconds.
Instead of selecting languages based on the user config at the time
of TitleDatabase creation and merging the different languages into one
map for GC and one map for Wii, have one map for each language, and
have the caller supply the language they want. This makes us not need
the IsGCTitle function, which is inaccurate for IDs that start with D.
The difference between Dolphin's game IDs and GameTDB's game IDs
is that GameTDB uses four characters for non-disc titles, whereas
Dolphin uses six characters for all titles.
This fixes:
- TitleDatabase considering Datel discs to be NHL Hitz 2002
- Gecko code downloading not working for discs with IDs starting with P
- Cover downloading mixing up discs with channels (e.g. Mario Kart Wii
and Mario Kart Channel) and making extra HTTP requests. (Android was
actually doing a better job at this than DolphinQt!)
The header of a Wii disc can be read from two places: The
unencrypted area at the beginning of the disc, or the beginning of
the game partition. The two copies are usually identical (except
for 0x60 and 0x61), but there are exceptions. For most of Dolphin's
history, we have been reading from the header inside the game
partition when getting metadata. This was however not the case
starting with 4.0-4901 and ending with 5.0-3762. This commit once
again makes Dolphin read metadata from the unencrypted header,
because of the following reasons that I recently was informed about:
- The "pink fish" disc has the game ID 410E01 in the unencrypted
header but the placeholder game ID RELSAB in the partition header.
- The revisions of some games differ between the two headers,
with the unencrypted one making more sense.
(See https://bugs.dolphin-emu.org/issues/11387)
For better or worse, this also means that sloppily hacked games where
only the game ID in the unencrypted header has been changed now will
use that modified game ID. And unlike with the partition header,
there is no signing or hashing that can tell us whether the
unencrypted header has been modified by someone other than Nintendo.
Since we don't have a way (AFAIK) to dynamically collect the list of
available art assets, we hardcode a list of gameids with available
artwork inside Dolphin. It's not great, but I don't think it's a
terrible solution either.
Art has to be manually uploaded to our Discord app configuration, and we
have a limit of ~150 assets, so most likely we'll limit ourselves to a
small set of popular games.
also did these things
fixed crash from joining user that isn't hosting via a direct connection
current game stat can now pass to override the current game in config
uses ip endpoint from dolphin.org
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.
Deduplicates code, and gets rid of some problems the old code had
(such as: bad performance when calling native functions, only one
disc showing up for multi-disc games, Wii banners being low-res,
unnecessarily much effort being needed for adding more metadata).
This ports the Wii filesystem root, Wii SD card path and dump path
settings to the new config system (OnionConfig).
My initial plan was to wait until DolphinWX was removed before porting
most of the Main (Core, DSP, General) settings to onion config, but
I've decided to submit a small part of those changes to fix
[issue 10566](https://bugs.dolphin-emu.org/issues/10566).
Removes the need to manually set the FileUtil path in the UI frontends
and gets rid of some more members that don't really belong in SConfig.
Also fixes a bug which would cause the dump path not to get created
after change.
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.
Xlib has really terrible headers that declare non-namespaced
macros and typedefs for common words.
Just wasted 10 minutes trying to figure out why a unit test failed
to build before I remembered it was Xrandr.h conflicting with our
enum class members again.
To fix the issue, this removes the Display* parameter from the
EnableScreensaver function (which was unused) so we don't have
to include Xrandr.h anymore.
After 3a83ebc, the Show System Clock feature started using the
unfortunate combination of MM/DD/YY dates (rare outside of the US)
and 24-hour time (rare in the US) regardless of the user's locale
settings. This commit makes it use the configured locale again.
I've noticed one minor difference in behavior between now and
before 3a83ebc: The new way of setting the C/C++ locale seems to
treat "en" as "en-US", but the wx way of setting the C locale
treated it as "en-GB" (at least on Windows).
Everything that links in core doesn't need to see anything related to bochs, because it's only used internally.
Anything else that relies on bochs should be linking it in explicitly.
Makes our libraries explicitly link in which libraries they need.
This makes our dependencies explicit and removes the reliance on the
LIBS variable to contain the libraries that they need.
Regression from 1f1dae3.
This problem doesn't happen in DolphinWX as far as I know, but if
you've ran into the problem in DolphinQt2, it will carry over to
DolphinWX because of the shared game list cache.
The AutoUpdate module is a generic update checker mechanism which can be
used by UI backends to trigger an auto-update check as well as the
actual update process.
Currently only configurable through .ini and the Qt implementation is
completely placeholder-y -- blocking the main thread on a network
request on startup, etc.
The original reason I wanted to do this was so that we can replace
the Android-specific code with this in the future, but of course,
just deduplicating between DolphinWX and DolphinQt2 is nice too.
Fixes:
- DolphinQt2 showing the wrong size for split WBFS disc images.
- DolphinQt2 being case sensitive when checking if a file is a DOL/ELF.
- DolphinQt2 not detecting when a Wii banner has become available
after the game list cache was created.
Removes:
- DolphinWX's ability to load PNGs as custom banners. But it was
already rather broken (see https://bugs.dolphin-emu.org/issues/10365
and https://bugs.dolphin-emu.org/issues/10366). The reason I removed
this was because PNG decoding relied on wx code and we don't have any
good non-wx/Qt code for loading PNG files right now (let's not use
SOIL), but we should be able to use libpng directly to implement PNG
loading in the future.
- DolphinQt2's ability to ignore a cached game if the last modified
time differs. We currently don't have a non-wx/Qt way to get the time.
Currently, a simple typo in the system name will trigger an assert
message that complains about a "programming error". This is not
user friendly and misleading.
So this changes GetSystemFromName to return an std::optional, which
allows for callers to check whether the system exists and handle
failures better.
Manually convert each argument to a UTF-8 std::string, because the
implicit conversion for wxCmdLineArgsArray to char** calls ToAscii
(which is obviously undesired).
Fixes https://bugs.dolphin-emu.org/issues/10274
Originally, Layer contained a std::map of Sections, which containted a std::map
containing the (key, value) pairs. Here we flattern this structure so that only
one std::map is required, reducing the number of indirections required and
vastly simplifying the code.
Ideally Common.h wouldn't be a header in the Common library, and instead be renamed to something else, like PlatformCompatibility.h or something, but even then, there's still some things in the header that don't really fall under that label
This moves the version strings out to their own version header that doesn't dump a bunch of other unrelated things into scope, like what Common.h was doing.
This also places them into the Common namespace, as opposed to letting them sit in the global namespace.
The "X.h" header *just* contains protocol constants, not functions or
typedefs - so stuff like "Display" and "Window" are not defined unless
you include "Xlib.h".
"Xrandr.h" happens to include "Xlib.h" itself, so enabling xrandr
effectively worked around this issue.
The Config::AddLoadLayer functions call Load on the layer
explicitly, but Load is already called in the constructor,
so they'd cause the loader's Load function to be called twice,
which is potentially expensive considering we have to read an INI
from the host filesystem.
This commit removes the Config::AddLoadLayer functions because
they don't appear to be necessary.
Allows reusing the WAD import logic more easily, whereas UICommon
code can only be used from UICommon and UI.
And managing what's on the NAND is the Core's responsability, not UI.
To use it, with a modern LLVM (3.9+), set your CMAKE_PREFIX_PATH
to point to the LLVM install folder or to a LLVM build folder.
We're linking ALL of LLVM libs since I don't really know which ones we need.
LTO will take care of sliming the binary size...
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.
This cleans up some of the code between core and UI for disassembling and dumping code blocks.
Should help the QT UI in bringing up its debug UI since it won't have to deal with this garbage now.
Eventually, netplay will be able to use the host's NAND, but this could
still be useful in some cases; for TAS it definitely makes sense to have
a way to avoid using any preexisting NAND.
In terms of implementation: remove D_WIIUSER_IDX, which was just WIIROOT
+ "/", as well as some other indices which are pointless to have as
separate variables rather than just using the actual path (fixed, since
they're actual Wii NAND paths) at the call site. Then split off
D_SESSION_WIIROOT_IDX, which can point to the dummy NAND directory, from
D_WIIROOT_IDX, which always points to the "real" one the user
configured.
With my previous changes Dolphin would fail to create the user directory if it didn't exist, and would dump all the configuration options in to the cwdir.
This was a bit more complicated to fix in a clean fashion, so I took to moving around code concerning user directories.
Instead of having GetUserPath serve a dual purpose of both getting and setting our user directories, break out to a new SetUserPath function.
GetUserPath will know only get the configured user path.
SetUserPath will set our user paths and setup the internal user path state.
This ending up being a lot cleaner overall, which is nice. Also less mind bending when attempting to read the code.
So now we won't dump all of our configuration in to the cwdir if ~/.dolphin-emu isn't found.
Fixes issue 8371.
The UI should decide on where it wants the user directory, not our core system.
This is in anticipation of some upcoming work on Android which will need proper user directory setting.
The libusb driver must be installed on the adapter (e.g. zadig can be used to install the driver in Windows). GameCube pad controllers are supported and will override the current input device assigned to the port. GameCube controller buttons are auto-configured and cannot be re-assigned. Rumble is supported. Hotplug is supported while playing a game. If a controller is unplugged from the adapter, Dolphin will fallback to using the host input device on that port. If a port on the adapter is unused, Dolphin will use the host input device for that port, allowing a mixture of host input devices and controllers connected to the adapter.
The adapter support can be disabled in the Controllers config if the OS driver is preferred (allowing the pad buttons to be reconfigured).
One adapter per system is supported.