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.
Lioncash