https://bugs.dolphin-emu.org/issues/11888
This also includes another change: DolphinQt will now exit with an
error if you use --batch without specifying a game using any method
(unlike in the past where --batch would be ignored if you didn't
specify a game using --exec, even if you had used --nand-title).
The main reason why I did this was because coding the alternative
(ignoring --batch) would be annoying with render to main involved.
This feature was originally exclusive to the previous iteration of
DolphinQt (the one that was the reason for the current iteration
being named DolphinQt2 initially).
https://bugs.dolphin-emu.org/issues/8949
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.
Léo Lam