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).
Based off codehandleronly.bin. Improves support for codes with conditionals due to adding cache invalidation on stores. You also have support for mode code lines at once before Dolphin freezes at startup.
- coef: Explicitly set 23 different values that are used by GBA UCode,
and tweaked overall parameters to more closely match those 23 values.
- irom: Moved a few functions to their proper places, updated BootUCode
to configure DMA transfers using AX registers as well as IX registers
(the GBA UCode uses this to do two sequential transfers in one call),
and added partial functions used by GBA UCode.
All functions were reverse-engineered solely based off of observed
effects on the virtual machine: register states before-and-after, dmem
interactions, and DMA transfers. The specific coefficients were observed
being read from dmem, and must be exactly those values to function
properly. I have no knowledge of how the official ROM implements these
functions, or how it is implemented overall.
Tested with The Legend of Zelda: Four Swords Adventures, Final Fantasy
Crystal Chronicles, and Billy Hatcher and the Giant Egg (to download
ChuChu Rocket!).
This adds new themed rating stars to all of the theme folders, with the
intent to eventually replace the awful old ratings stars in
sys/resources. I’m not a coder so it will be up to someone else to use
these files to replace the ratings stars in WX and Qt. Their dimensions
are the same as the old ones, so it should be pretty easy to implement,
though it will require moving over to theme-able files and supporting
HiDPI for them.
@4x files are present for future proofing / possible android usage.
All files have been optimized with opti-png.
This allows us to print user friendly names for titles out of the box,
without requiring the user to manually download a title database and
place it in the correct location.
No auto-update mechanism is implemented as it would be substantially
more complicated and overkill (imo), since titles are not updated
that often. I have however added a script to make updating them easier.
The database can be freely used without any restriction. I have
contacted the author.
Dolphin is able to generate one with all correct default settings, so
we don't need to ship with a pre-generated SYSCONF and worry about
syncing default settings.
Additionally, this commit changes SysConf to work with session SYSCONFs
so that Dolphin is able to generate a default one even for Movie/TAS.
Which SYSCONF needs to be touched is explicitly specified to avoid
confusion about which file SysConf is managing.
(Another notable change is that the Wii root functions are moved into
Core to prevent Common from depending on Core.)
Windows-1252 was sometimes being referred to as ASCII or ANSI
in Dolphin, which is incorrect. ASCII is only a subset of
Windows-1252, and ANSI is (rather improperly) used in Windows
to refer to the current code page (which often is 1252 on
Western systems, but can also be something entirely different).
The commit also replaces "SJIS" with "Shift JIS". "SJIS"
isn't misleading, but "Shift JIS" is more commonly used.
- F.ini: PR #4189 removes the need for 1x IR according to JMC
- GWO.ini: Just force integral resolution, not auto resolution
- GALP01.ini: I have no idea why EFBScale would be forced here
- GINX69.ini: I think JMC said it's fixed, but I can't find his post...
- SNS.ini: https://bugs.dolphin-emu.org/issues/9891
- P INIs: https://bugs.dolphin-emu.org/issues/9938
Set EFBtoTextures=False, fixes issue #9942 from Ocarina of Time, makes Link preview visible in Equipment screen, with EFB to Textures Only enabled the preview stays black, rather than showing Link's current equipment.
The signature DB is very helpful for generating a symbol map for games
which don't ship with debugging symbols, since it includes signatures
for common SDK functions.
However, it isn't very complete and only contained signatures for GC
games -- the current database isn't very helpful for Wii games, which
still have a huge number of unknown functions even after using this DB.
Yet Wii games typically share a lot of code (since they all use the
SDK), and not having symbols makes it a lot harder to look into what
a game is doing… So this commit adds common Wii SDK function signatures
to the database, in order to make generated symbol maps a lot more
useful for Wii games.
The debug info comes from the debugging map that was left in the Wii
version of The Legend of Zelda: Twilight Princess. To avoid cluttering
the DB with game-specific debug info (even though it already contains
some game-specific symbols), some basic filtering was done on the
shipped symbol map:
egrep '(section layout|\.a|m_Do|lib|Lib| OS)' tp-framework.map | grep -v Z2 > common-wii-sdk.map
Then this map was loaded in Twilight Princess, and "append to existing
signature file" was used to append the new hashes to totaldb.dsy.
Set EFBtoTextures=False, fixes issue #9942, makes Link preview visible in Equipment screen, with EFB to Textures Only enabled the preview stays black, rather than showing Link's current equipment.
Based on ca0c2efe7a. Credits go to flacs.
However, unlike the original commit, hidapi does not completely replace
the current implementations, so we can still connect Wiimotes with 1+2
(without pairing).
Also, it is only used on Linux and OS X for now. This removes the
advantage of having only one implementation but there is no other
choice: using hidapi on Windows is currently impossible because
hid_write() is implemented in a way that won't work with Wiimotes.
Additionally:
* We now check for the device name in addition to the PID/VID so we can
support the Balance Board and maybe third-party Wiimotes too. This
doesn't achieve anything with the DolphinBar but it does with hidraw.
* Added a check to not connect to the same device more than once.
All the inline comments from the netplay code were removed because they
apparently took up space in game memory (They were maxing out gecko
codes).
"Increase input timing accuracy" was made into its own code entry.
"Netplay Safe Kill Music" code has been updated to prevent desyncs.
BMX XXX can detect forced Progressive Scan in Dolphin but the game will not be playable, the emulator will freeze.
On an original GameCube, GC-Forever reported that "Game does not support component video output.".
By default, it's better to disable the forced Progressive Scan feature on this game to make it playable and also not stuck in a broken startup.
Anthony