Work around a dcache issue by preventing the game from doing
something pointless.
The game's DVD read function writes 0x87654321 to the entire read
buffer and 0x12345678 to the last 4 bytes. It then calls DVDReadAsync()
and without waiting for the read to complete at all, it checks if the
last 4 bytes are still 0x12345678. If they are, then the game fails.
The check always passes on console because DVDReadAsync() calls
issueCommand(), which calls DCInvalidateRange(read_buffer) (dcbi).
Dolphin cannot emulate this without an extremely significant
performance hit.
Forcing people to use hacks is a bad idea in general, and there are
two practical problems with doing it for immediate XFB in particular:
1. It breaks the GC IPL, which some users run when launching games.
2. Competitive players don't necessarily want the lowest possible
latency - they might want the latency that's the closest to console,
so if they're playing locally with a low-latency monitor, they might
not want to use immediate XFB. (This isn't a theoretical concern -
I've seen Melee players want to increase their latency.)
Besides, it feels arbitrary that just these five specific games should
have immediate XFB forced on.
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.
Without virtual xfb, the game will show distorted graphics once leaving
the title screen. This adds an INI file to make the game playable.
The wiki page for this game also notes the need for virtual xfb.
This could cause the first branch of the bootucode procedure, which
takes its parameters from the AX registers, to run during the ROM init
sequence. Since the ROM doesn't set any of the AX registers, the values
aren't meaningful, and can cause bad DMA transfers and crashes.
Wii.Widescreen is a setting that cannot be changed on the fly after
emulation has started, so anything booted after the initial title
will have an unexpected aspect ratio.
We can just set Video_Settings.AspectRatio instead, which *can* be live
changed, since it doesn't involve messing with the SYSCONF at any time.
This is also much closer to the behaviour of the Wii U, which
configures the DMCU to force 4:3 transparently, instead of doing it the
intrusive way (touching the SYSCONF).
JosJuice