The conditions were in reverse order (maybe someone was reading the
PowerPC manual and forgot about IBM's bit numbering), and additionally
the two conditions for unsigned comparison were wrong.
Fixes https://bugs.dolphin-emu.org/issues/14054.
For some reason, NativeLibrary.kt calling Log for the alert message text
makes Dolphin die with a JNI error. Supposedly the jstring passed to the
logging function is invalid. I don't understand why, because the dialog
that we show right afterwards is able to read the string just fine. The
error happens even if I pass the string directly to Log without
prepending any extra text.
There's no real downside to having the logging in C++ instead of Kotlin,
so let's move it to C++ to avoid the JNI error.
This fixes VolumeVerifier potentially calling TMDReader::GetIOSId for
invalid TMDs.
VolumeVerifier also has a call to TMDReader::GetContent that doesn't
check if the TMD is valid. In practice, this can't get called with an
invalid TMD because the previous commit made it so GetContentOffsets
returns an empty vector if the TMD is invalid, but I've added a check
inside TMDReader::GetContent just to be on the safe side.
I also made VolumeVerifier show a specifically worded problem if the
ticket or TMD is invalid. Before, invalid TMDs in Wii discs and WADs
and invalid tickets in WADs would show a more generic problem.
This can be useful for experimenting with how a game behaves with and
without page table fastmem. As with everything in the JIT menu, this is
only available if Dolphin's debugger is enabled.
I didn't add this in 989a95a when I added the setting itself because we
were under a string freeze for Dolphin 2603a at the time.
The Open in External Editor button makes editing a game INI file easy,
and the Refresh button is only useful if you edit the game INI. You're
not supposed to edit read-only game INIs, so let's not show these two
buttons for read-only game INIs.
I implemented this by hiding the buttons instead of not creating them in
the first place so we don't have to branch on whether the buttons exist
in GameConfigEdit::ConnectWidgets.
Back in 2018, a Presets system was added to DolphinQt's GameConfigEdit.
Presets was a dropdown menu where you could select a particular setting
to add to your custom game INI. Only a small number of settings were
made available, with the intent that more would be added over time.
8 years later, the set of available settings hasn't been expanded at
all, and I don't know of anyone who uses these presets. On top of this,
we have now made good progress in exposing per-game settings
graphically. I think the Presets system is best off removed.
In place of the Presets menu, we now have "Refresh" and "Open in
External Editor" buttons. These more useful actions were previously
hidden away in the Presets menu.
`value` contains 16 bits of data and `remainder` contains 11 bits of
data. When they're added together, we may end up with 17 bits of data,
so the result should be stored as u32 rather than u16.
This fixes `y` being set to 0 (minimum amplitude) when it should be set
to 32 (maximum amplitude).
In the PWM audio we output, instead of each group of 512 bits consisting
of a run of ones followed by a run of zeroes, now each group of 32 bits
consists of a run of ones followed by a run of zeroes. This gets rid of
noise that was previously present.
Doing this for every group of 8 bits instead makes the Game Boy Player
Start-Up Disc not start correctly for some reason. Game Boy Interface
works fine, though.
I also made us not discard the bottom 7 bits of each PCM sample.
According to Extrems, a real GBA doesn't actually output that many bits,
but doing it in this way makes the code simpler anyway.
Mistakenly, MISALIGNED_HOLE_MASK_PAGE_TABLE_BASE was aligned and
MISALIGNED_HOLE_MASK_PAGE_TABLE_BASE_ALIGNED was misaligned. It should
be the other way around.
These variables are unused due to a separate mistake which is corrected
in the next commit.
Unmapped on the physical level, not the MMU level.
Fixes booting Game Boy Interface. Previously, Game Boy Interface thought
it was running on a Wii because accessing MEM2 didn't raise a PI
interrupt, and as a result tried to exit to the Homebrew Channel in a
way Dolphin's HLE doesn't recognize. (Dolphin's HLE catches jumps to
0x80001800, but GBI is running without address translation at this point
and therefore jumps to 0x00001800 instead.)
Jit64::dcbz's fast path bypasses the dcache, so we shouldn't use it if
accurate dcache is turned on. This fixes the graphical corruption that
would occur in Mario Kart Wii's menu FMVs with accurate dcache.
JitArm64 never had this problem, because it implements dcbz in a
different way. It calls EmitBackpatchRoutine, which already has a check
for accurate dcache.
Some games are showing frame flickering, e.g. Pokémon games when only
the text at the bottom of the screen is updating. GB/GBC games are
apparently especially affected, presumably due to the extra border.
`OpenModeToAndroid("r")` is conceptually wrong, since we're opening a
binary file. It should be either `OpenModeToAndroid("rb")` or just
`"r"`. But either way it evaluates to `"r"`, so this doesn't affect
behavior.
The following settings were excluded:
* Port 1-4 ROM: We're only supporting Game Boy Player for now
* Save in Same Directory as the ROM: Implementation nightmare due to SAF
SAF for save files is a huge can of worms because they're managed in a
more complicated way than asking the user to select an existing file,
so I won't be touching save files for now.
We used to create User/Logs/ as a side effect of creating
User/Logs/Mail/, but the creation of User/Logs/Mail/ was removed in
8cbfee2, so now nothing is creating User/Logs/ anymore. Let's explicitly
create it.
Some users seem to be under the impression that the panic alert is
saying that enabling MMU will fix the issue, but that's not what it
actually says. Let's try to make this a bit clearer.
I think we've gotten all the useful reports we can get from this now.
Nowadays we're just getting repeated reports of issues we already know
about, like https://bugs.dolphin-emu.org/issues/12321.
TimeSplitters: Future Perfect is crashing if page table fastmem is
enabled. The reason hasn't been analyzed yet. For the time being, let's
use GameSettings to bring back the old behavior of not having page table
fastmem.
Fixes https://bugs.dolphin-emu.org/issues/14000.
This should stop AchievementManager::LoadGame from being called for the
default ISO when CBoot::BootUp is booting something other than a disc or
IPL (most notably, the Wii Menu), while still detecting all disc changes
that happen while a disc game is running.
This switches from an O(log(N) * M) algorithm to an O(N * log(M))
algorithm. This is advantageous because N, the size of `mappings`, is
usually much smaller than M, the size of `m_page_table_mapped_entries`.
RemoveLargePageTableMapping already did something similar, so we can
even deduplicate some code between it and RemoveHostPageTableMappings.
Speeds up Rogue Squadron 3 by roughly 3% on my PC.
If Dolphin crashes, changes that have been made to settings are often
lost. This has been a minor annoyance for me when developing, but it has
become a much bigger issue recently due to the problem where Dolphin
freezes on shutdown for ROG Ally users.
Instead of saving the config when certain arbitrary settings are
changed, let's save the config when the user closes the settings window.
Users are reporting a crash at the point where WiimoteAndroid::IORead
tries to use m_java_wiimote_payload. This commit solves the problem by
making m_java_wiimote_payload a global reference.
The code for setting up m_java_wiimote_payload has also been moved to
the constructor just because that way it's impossible for it to run
twice. (If the code as written were to run a second time, the old global
reference would be leaked. ConnectInternal should only run once, so this
is just to be on the safe side.)
Fixes https://bugs.dolphin-emu.org/issues/13960.
We often use game IDs in paths, so we should try to make sure path
traversal is impossible in game IDs. Admittedly, doing any kind of real
attack using the six bytes available in game IDs is unrealistic, but no
game ID should contain non-alphanumeric or non-ASCII characters anyway.
Might also fix https://bugs.dolphin-emu.org/issues/13982 by skipping
converting between encodings for game IDs.
This makes JitBaseBlockCache::ErasePhysicalRange around 50% faster and
PPCAnalyzer::Analyze around 40% faster. Rogue Squadron 2's notoriously
laggy action of switching to and from cockpit view is made something
like 20-30% faster by this, though this is a very rough measurement.
This is a very small libary, and as I understand it, it was more or less
developed for Dolphin.
This moves the two relevant files from Externals to Common, changes the
namespace to Common, reformats the code, and adds Dolphin copyright
notices. The change in copyright notice and license was approved by
AdmiralCurtiss.
Default values for settings need to be the same in Kotlin and C++,
otherwise settings that haven't been changed by the user will be shown
as having one value in the Android GUI but treated as having a different
value in the core.
This lets users select Triforce Baseboard for SI and SP1. Limitations:
* The test, service and coin buttons can be bound to gamepads and other
physical inputs, but aren't available in the touch input overlay.
* The IP redirections are exposed to the user as a raw string rather than
a table like in DolphinQt.
The functions SaveToSYSCONF and LoadFromSYSCONF contain checks for
whether emulation is running. The intent of this is that when we're
emulating a Wii, the emulated system may write to SYSCONF whenever it
likes and does not expect anything else to write to SYSCONF, so the
host code shouldn't access SYSCONF while emulation is ongoing. However,
Core::IsRunning is an imperfect proxy for whether we've handed over
control of SYSCONF to the emulated system yet, as the actual handover
happens at a slightly different point in time than when the emulation
state is changed. This usually isn't a problem, but in theory it could
be a determinism problem if a setting is changed right as emulation is
starting, or it could cause the emulated software to briefly misbehave
if a setting is changed right as emulation is stopping.
Things got worse in 72cf2bdb87 when I
replaced the Core::IsRunning calls with !Core::IsUninitialized. With
IsRunning, there was be a period of time where SYSCONF should have been
protected but wasn't. With !IsUninitialized, there was a period of time
where SYSCONF shouldn't have been protected but was, and crucially, this
period of time included the moments where we do setup and teardown of
the emulated NAND, which broke transferring SYSCONF settings between the
host and the guest. 72cf2bdb87 was
reverted because of this.
This commit adds a flag that we explicitly flip when control is handed
over to or from the emulated system. This protects the SYSCONF file
for exactly as long as is needed.
I've gone through all relevant settings for Rogue Squadron II and III
and overhauled their game INI files. Each setting is explained with a
comment.
Some settings I chose not to include:
* EFB to RAM only seems to affect certain fadeouts in Rogue Squadron II.
Without it, the affected fadeouts are replaced by a pure black screen.
I don't think this is important enough to warrant the performance hit.
* As I was unable to find anything Rogue Squadron III needs EFB to RAM
for, I also didn't find anything it needs DeferEFBCopies disabled for.
* I didn't find anything EFBEmulateFormatChanges was needed for in
either game.
* Enabling EFB access makes the ship engine glow visible in Rogue
Squadron III, but this effect is minor enough that you probably won't
notice it's missing unless you know it's supposed to be there. Since
this is Dolphin's heaviest game, let's give users the choice.
* I was considering forcing XFB to RAM for Rogue Squadron III to make
fadeouts render properly instead of going from magenta to black, since
enabling XFB to RAM doesn't really hurt performance when you're
already enabling EFB to RAM. But then I was unable to find a reason
why we should enable EFB to RAM for this game.
Tested in RS2 and RS3. The RS3 demo disc settings are copied from the
RS3 settings and haven't been tested by me.
Previously, when an input device was connected or disconnected, we would
recreate all devices. This commit makes it so we only touch the relevant
device instead. This matters because recreating a device causes us to
drop all held buttons for that device. Due to Android only delivering
inputs as events, we're unable to poll for currently held buttons when
recreating a device.
This recently became a problem for users of Ayn devices due to a
firmware update. Every now and then, something about the display
viewports changes, triggering an update to an input device that I assume
is a touch input device. This input device isn't something users
normally map in Dolphin's controller settings, but it changing was
causing Dolphin to drop all held buttons for the device's built-in
gamepad as well as any other connected gamepads.
In the unit test I'm adding in the next commit, I want to call
MemoryManager::Init, but initializing all the hardware that
MemoryManager::InitMMIO calls into would be cumbersome.
Calling MemoryManager::InitMMIO from MemoryManager::Init was a bit
strange anyway. Because MemoryManager::Init is called about halfway
through HW::Init, some of the hardware that MemoryManager::InitMMIO
calls into isn't initialized yet.
Most systems that Dolphin runs on have a page size of 4 KiB, which
conveniently matches the page size of the GameCube and Wii. But there
are also systems that use larger page sizes, notably Apple CPUs with
16 KiB page sizes. To let us create host mappings on such systems, this
commit implements combining guest mappings into host page sized mappings
wherever possible.
For this to work for a given mapping, not only do four (in the case of
16 KiB) guest mappings have to exist adjacent to each other, but the
corresponding translated addresses also have to be adjacent, and the
lowest bits of the addresses have to match. When I tested a few games,
the following percentages of guest mappings met these criteria:
Spider-Man 2: 0%-12%
Rogue Squadron 2: 39%-42%
Rogue Squadron 3: 28%-41%
So while 16 KiB systems don't get as much of a performance improvement
as 4 KiB systems, they do still get some improvement.
Removing and readding every page table mapping every time something
changes in the page table is very slow. Instead, let's generate a diff
and ask Memmap to update only the diff.
Page table mappings are only used when DR is set, so if page tables are
updated when DR isn't set, we can wait with updating page table mappings
until DR gets set. This lets us batch page table updates in the Disney
Trio of Destruction, improving performance when the games are loading
data. It doesn't help much for GameCube games, because those run tlbie
with DR set.
The PowerPCState struct has had its members slightly reordered. I had to
put pagetable_update_pending less than 4 KiB from the start so AArch64's
LDRB (immediate) can access it, and I also took the opportunity to move
some other members around to cut down on padding.
Previously we've only been setting up fastmem mappings for block address
translation, but now we also do it for page address translation. This
increases performance when games access memory using page tables, but
decreases performance when games set up page tables.
The tlbie instruction is used as an indication that the mappings need to
be updated.
There are some accuracy downsides:
* The TLB is now effectively infinitely large, which matters if games
don't use tlbie when modifying page tables.
* The R and C bits for page table entries get set pessimistically rather
than when the page is actually accessed.
No games are known to be broken by these inaccuracies, but unfortunately
the second inaccuracy causes a large performance regression in Rogue
Squadron 3. You still get the old, more accurate behavior if Enable
Write-Back Cache is on.
This improves my PC's performance on RS2 Hoth by... 0.1% or so, which I
think is within the margin of error. But this change also cuts down on
boilerplate.
If all inputs to an fmadds instruction (including cousins like fmsubs,
fnmadd...) are single-precision, then the result is identical between a
double-precision calculation with an error-free transform (whether the
calculation is fused or not) and a single-precision FMA instruction
(must be fused). So as a performance optimization in JitArm64, if we
were going to use double precision with EFT but the inputs are singles,
instead we'll use a normal single-precision FMA instruction without
anything extra. This lets us skip both the EFT and double-to-single
conversions.
Also renaming `inaccurate_fma` to `nonfused` because it's confusing that
`inaccurate_fma` and `m_accurate_fmadds` have such similar names
despite controlling separate things.
If result_reg is set to a temporary register instead of VD because of
accurate NaNs, there's no need to allocate a secondary temporary
register because of inaccurate FMA.
TextureCacheBase::LoadImpl has a hot path where the passed-in
TextureInfo never gets used. Instead of passing in a TextureInfo, let's
pass in the stage and create the TextureInfo from the stage if needed.
This unlocks somewhere above an additional 4% performance boost in the
Hoth level of Rogue Squadron 2 on my PC. Performance varies, making it
difficult for me to measure, so treat this as a very approximate number.
JosJuice