Fix the device ID struct to reflect the actual structure used by IOS.
It turns out that offset 2 is the internal device index. The reason
that field seemed to be "0x1e - interface_number" is that IOS only
keeps track of 32 devices and always looks for free entries from
the end of the internal array. With each USB interface being exposed
as a separate USBv5 device, "0x1e - interface_number" was mostly
correct... but wrong!
We also made the assumption that the interface number can be
identified from just a USBV5 device ID, which is definitely not true.
VEN (and HID) keep track of the interface number in the internal struct
instead of "reconstructing" it from the device ID (which is normally
not possible if we were generating IDs correctly)
This commit fixes all of these inaccuracies.
This reverts commit 1fc910b3ea,
replacing the old INI setting EFBScale with a new INI setting
called InternalResolution, which has a simpler mapping:
| EFBScale | InternalResolution
----------------- | -------------------- | --------------------
Auto (fractional) | 0 |
Auto (integral) | 1 | 0
1x | 2 | 1
1.5x | 3 |
2x | 4 | 2
2.5x | 5 |
3x | 6 | 3
4x | 7 | 4
5x | 8 | 5
6x | 9 | 6
All the fractional IRs were removed in f090a943.
It is not possible to tell whether DLC contents are supposed to be
present on the NAND or not, because they're treated as "optional".
So this commit changes the NAND check to not consider missing
contents for DLC titles as an issue.
"N/A" can be awkward to handle in translations.
I don't think there's much point in showing "N/A" rather than
leaving the description box blank, so let's just leave it blank.
Use std::string(cstring, strnlen(cstring, max_length)) instead of
trying to remove extra null characters manually, which is a bit
ugly and error prone.
And indeed, the original code contained a bug which would cause
extra NULLs to not be removed at all if the string did not
end with a NULL -- causing issues down the road when constructing
paths for sub-entries.
Because the Wii NAND size is finite, mark titles that were installed
only for booting as temporary, and remove them whenever we need to
install another title (to make room). This is exactly what the
System Menu does for temporary SD card title data.
Also clean up the way the system menu label is updated. We don't want
to access the NAND while emulation is running, and especially not
that many times per second on an unpredictable timing.
This commit removes the last usage of NANDContentManager in IOS code.
Another cleanup change is that loading ARM (IOS) binaries is now done
by the kernel in the BootIOS syscall, instead of being handled as a
special case in the MIOS code. This is more similar to how console
works and lets us easily extend the same logic to other IOS binaries
in the future, if we decide to actually load them.
This removes the hack that enables directly booting from WADs
without installing them first for the following reasons:
1. It makes the NAND content handling much more complicated than what
it should be and makes future changes like permissions or booting
NAND titles without a WAD more annoying to implement.
Because of this hack, we needed an extra level of abstraction
(NANDContent*) which has to read tons of things from the NAND, even
most of the time it's useless. This in turn forces us to have
caching, which is known to break titles and requires manual cache
invalidations. Annoying and error prone.
2. It prevents the WAD boot code from being easily accurate. With this
change, we can simply reuse the existing launch code, and ask IOS
to launch the title from the NAND.
3. The hack did not work that well since it did not cover a lot of ES
commands. And it works even less since the ES accuracy fixes.
This results in Dolphin returning inconsistent results: a
lot of the ES "DI" commands will just fail because the active title
is not installed on the NAND. uid.sys is not changed, etc.
And I'm not even talking about FS stuff -- where this would still
totally fail, unless we add even more unnecessary hacks.
This is not just theoretical -- the system menu and the Wii Shop are
known to behave strangely because the hack damages the NAND
structure, and we've already had several users report issues.
This commit makes it so WADs are always installed prior to launching.
A future commit will remove any code that was there only for the hack.
The GameCube's sample rate is slightly different due to a hardware bug.
The exact numbers are (54000000 / 1124) for GameCube and (54000000 / 1125)
on Wii. I also modified 32KHz mode. This fixes audio desyncs in several
GameCube games and severe issues in Sonic Mega Collection.
Léo Lam