Unnecessary since b93b7ec. It was needed before that commit becase
RenderBase.cpp only was checking the value of aspect_mode, not
suggested_aspect_mode.
People in the Google Play reviews still seem to be confused about
games not showing up in the directory picker, so let's show them
even though they can't be selected. (Either that or they haven't
realized that they need to extract their pirated games.)
For a while now, we have used the INI setting SuggestedAspectRatio
to indicate that a Wii game doesn't support 16:9, making Dolphin
switch to 4:3 when playing those games (as long as the aspect ratio
setting is set to Auto). However, we didn't have a complete list of
games that don't support 16:9. Yesterday, I found what seems like
such a list in the vWii system menu (the PAL one, in case it matters).
This commit sets SuggestedAspectRatio = 2 in the INIs for all the
titles in that list, with a few exceptions:
E5Z E62 E63 E6W E6X E6Z: These titles are already covered by E.ini.
HAJ HAP HCB: HAJ and HAP do in fact support 16:9, but are not
installable on vWii without hacking. I don't know anything about HCB
other than what its GameTDB entry says, but since HAJ and HAP do
in fact support 16:9, it's probably best to not mark HCB unless
someone actually can check that it doesn't support 16:9.
All newly added files in this commit were automatically generated,
and all existing files that were edited were handled manually.
Interesting to note is that some of the titles in the vWii list
seem to be completely unknown. Perhaps they are unreleased games.
Some games don't behave as expected if we eject the disc as soon as
we receive the DVDLowStopMotor command. For instance, Baten Kaitos
never shows the prompt to switch discs or the "Reading disc..." text
(but works correctly other than that).
Some of the recent reviews on Google Play express trouble finding the
emulation activity menu. One of them thought you were supposed to go
to the settings accessible through the main activity to configure the
virtual controller buttons.
This commit changes the text so that the user now explicitly is told to
swipe down from the top of the screen to access the menu. In exchange,
I removed the exact selections to make in the menu so that the text
wouldn't get too long, but I think it shouldn't be too hard to
understand once you know how to open the menu.
It doesn't feel great to let the value from a previous emulation session
linger around considering that the GC aspect ratio heuristic can use
the previous value of m_aspect_wide when calculating m_aspect_wide.
Starting with PR 7411, the rest of Dolphin reads the game ID from
PARTITION_NONE, but SetRunningGameMetadata was still reading from
the game partition. https://bugs.dolphin-emu.org/issues/11422
These country codes have the unfortunate property that they are used
by Wii disc games in two different regions. We already correct for this
in VolumeGC::GetCountry and VolumeWii::GetCountry, so this commit
shouldn't really have any effect on how the game list behaves,
but it will be useful if we in the future would want to call
CountrySwitch directly without having extra code in the caller for
handling region weirdness.
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.
The LogManager code had trouble detecting the "/Source/Core/" substring
for two reasons, neither of which seemed to happen a few years ago:
1. __FILE__ is in lowercase on MSVC
2. __FILE__ uses backslash as the directory separator on MSVC
Fixes https://bugs.dolphin-emu.org/issues/11366
JosJuice