Instead of expecting callers to know how the size of directory file infos
relates to which files are in which directories, filesystems now offer a
GetRoot() method, and file infos offer a way to get their children. As
a bonus, m_FileInfoVector no longer has to be created and kept around
in RAM. Only the file info objects that actually are used are created.
Some callers already have the file info, making the relatively slow
FindFileInfo calls unnecessary. Callers that didn't have the file info
will now need to call FindFileInfo on their own.
Some callers (i.e. ISOProperties) don't want the full path, so giving them
it is unnecessary. Those that do want it can use GetPathFromFSTOffset.
Not storing full paths everywhere also saves a small bit of RAM and is
necessary for a later commit. The code isn't especially pretty right now
(callers need to use FST offsets...) but it'll become better later.
GC/Wii filesystem internals shouldn't be exposed to other classes.
This change isn't especially useful by itself, but it opens up the
way for some neat stuff in the following commits.
* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
Normal users don't care about it. In fact, people care so
little about it that the Wii implementation of it was broken
starting from when it was implemented (eb65601) to 7 years
later (e0a47c1), apparently without anyone reporting it.
This makes the interface slightly cleaner and a bit more consistent
with the other getters. Still not fully the same, since the others
don't really handle failures with std::optional; but at least the
value is returned by value now, as opposed to having the function
take a pointer to a u64.
This gets rid of some assumptions that non-DiscIO code was making about
volume types. It's better to encapsulate as many of the volume type
differences as possible in DiscIO.
Made possible by PR #2353.
This makes it hard to support different boot params for different boot
types. We should not be making the assumption that Dolphin will
always be booting directly from a file (and in particular, only
using a string).
It's incompatible with future changes that will allow Dolphin to boot
a NAND title properly from well, the NAND, as opposed to booting from
WADs. (And no, treating the title TMD as a "bootable" path doesn't
count. Especially when that approach won't work with NAND images
or IOS LLE.)
And it's confusing to expose this functionality from the UI. It's
pretty bad for UX to change the play button's behaviour depending on
whether the user has launched something before, configured a default
file to boot, added a directory to their game paths.
This file is pretty small now that it doesn't handle Wii
partitions anymore, so let's move its contents to Volume.cpp.
This is also more consistent with how blob creation works.
By removing mutable state in VolumeWiiCrypted, this change makes
partition-related code simpler. It also gets rid of other ugly things,
like ISOProperties's "over 9000" loop that creates a list of
partitions by trying possible combinations, and DiscScrubber's
volume swapping that recreates the entire volume when it needs to
change partition.
This is something that should be the responsibility of the frontend
booting the game. Making this part of the host 'interface' inherently
requires frontends to leak internal details (much like the other
UI-related functions in the interface).
This also decouples more behavior from the debugger and the
initialization process in the wx frontend. This also eliminates several
usages of the parent menubar in the debugger code window.
These cannot be booted, so it is bad UX to show them in the UI as if
they were regular titles, and yet have different behaviour for them.
And technically, there is no reason to allow them to be used to boot
in the first place.
Another reason they should not be shown is that Dolphin fails
spectacularly with WADs that have a valid boot content index, but are
not PPC titles (e.g. IOS WADs). The only reliable way to avoid this
is to check for the title type and only show channels, just like
the Wii System Menu.
Just like DeleteTitle, Using CNANDContentManager is overkill,
inefficient and useless. And it results in a few failures in
situations where a delete should just always work.
But here it gets bonus points, because it manages to actually use
the TMD for deleting contents, when IOS does none of that and just
deletes files ending with .app in the title content directory. :)
Default column width was being used for math related to automatic column sizing, in the case of COLUMN_SIZE the default width was -1 which resulted in an issue where an errant scrollbar would appear.
