Same as the previous commit, except I'm copying strings
in the other direction because the DolphinWX variants
of these strings could use some improvement.
I don't know who thought it would be a good idea to put the Wiimote
connect code as part of the Host interface, and have that called
from both the UI code and the core. And then hack around it by having
"force connect" events whenever Host_ConnectWiimote is called
from the core...
Core::PauseAndLock requires all calls to it to be balanced, like this:
const bool was_unpaused = Core::PauseAndLock(true);
// do stuff on the CPU thread
Core::PauseAndLock(false, was_unpaused);
Aside from being a bit cumbersome, it turns out all callers really
don't need to know about was_unpaused at all. They just need to do
something on the CPU thread safely, including locking/unlocking.
So this commit replaces Core::PauseAndLock with a function that
makes both the purpose and the scope of what is being run on the
CPU thread visually clear. This makes it harder to accidentally run
something on the wrong thread, or forget the second call to
PauseAndLock to unpause, or forget that it needs to be passed
was_unpaused at the end.
We also don't need comments to indicate code X is being run on the
CPU thread anymore, as the function name makes it obvious.
Showing the Wii remote connection status leads to inconsistent UX,
because we don't do anything like that for GameCube controllers
or with Bluetooth passthrough.
It's also questionable how useful it is given that:
* it doesn't print the number of connected remotes, just that one
remote is connected, connecting or not connected, so the only info
it provides is actually wrong when using multiple remotes;
* this user-facing feature is actually broken in master and no one has
complained AFAIK, which means people don't really rely on it;
* the status bar isn't visible most of the time unless the user is
using render to main or deliberately keeping the main window's
status bar visible by moving the render window and they're not too
far away from their screen;
* emulated Wii remotes now reconnect on input, which means that there
is less of a need to actually know at all times whether a remote
is connected, since pressing any button will reconnect it and provide
immediate, visible feedback via OSD messages and the Wii remote
pointer appearing.
There are some cases where overriding the opening.bnr names
isn't desirable, such as when someone has several modded
versions of a game that differ in names but not game IDs.
This was causing Dolphin to always save "WriteToWindow = False". Instead
of disabling logging to the window (a config value), tell LogManager
that there's no window to log to (a runtime state).
The actual problem was combining the values from the date and time
pickers incorrectly. The uninteresting parts of the returned wxDateTime
need to be ignored and the WX documentation says so for the time picker.
I also cleaned up the handling of both widgets a bit, removing redundant
member variables in the process, in order to not risk correctness.
Some code was calling more than one of these functions in a row
(in particular, FileUtil.cpp itself did it a lot...), which is
a waste since it's possible to call stat a single time and then
read all three values from the stat struct. This commit adds a
File::FileInfo class that calls stat once on construction and
then lets Exists/IsDirectory/GetSize be executed very quickly.
The performance improvement mostly matters for functions that
can be handling a lot of files, such as File::ScanDirectoryTree.
I've also done some cleanup in code that uses these functions.
For instance, some code had checks like !Exists() || !IsDirectory(),
which is functionally equivalent to !IsDirectory(), and some
code was using File::GetSize even though there was an IOFile
object that the code could call GetSize on.
The MonoSpaceFont of the LogWindow was using a Windows native way to
specify a font name.
Now it's using wxFONTFAMILY_TELETYPE.
On Win32 it will additionally request the specific font name "Consolas",
so it doesn't use ugly "Courier New". I pilfered that specialization
from Source/Core/DolphinWX/Cheats/ARCodeAddEdit.cpp.
Before, if you extracted a directory like /map/Final/Release/,
Dolphin would create the nested folders map, Final and Release
in the output directory and put the files in Release instead of
just putting the files directly in the output directory.
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.
Before these changes each value of latency were actually 5ms, with a
minimum latency of ~10 ms. If it was set to 4 ms on the UI, the actual
latency was 10 + 5 * 4 = 30 ms.
Now 30 ms on the UI means 30 ms on the backend.
Simpler, and puts the call to CheckIntegrity right where it should be,
instead of being hidden somewhere in a thread class.
This also makes it more obvious what we're getting from the async task.
Oh, and coincidentally, this fixes a random crash that could occur
during the check. I'm not sure why.
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.
