I think someone confused these with the actual token and bounding box
registers in PE, which were added later. In CP they never did anything
and it's suspicious that they have the same addresses as their PE
counterparts. On real hardware they always read as zero.
Move ImGui::End() calls out of if(ImGui::Begin()) blocks.
Quoting from ImGui::Begin's function comment in imgui.cpp:
"You always need to call ImGui::End() even if false is returned."
In practice this didn't cause problems because the windows don't have
title bars and thus can't be collapsed, and so the block containing
::End would always run, but let's do it the right way.
Instead of having UserDataImportWarningDialog set an
`onResultDismiss` callback that examines `mustRestartApp`, and having
UserDataActivity set `mustRestartApp`, just have UserDataActivity set
the callback directly.
This approach is no more data-race-y than the previous approach, and it
simplifies the code. (The behavior of restarting the app when the task
finishes is specific to the user data import flow, and there is no
reason for TaskViewModel to be directly aware of it.)
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
We exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00218 mov w24, #0x100000 ; =1048576
0xcb180379 sub x25, x27, x24
After:
0xd1440379 sub x25, x27, #0x100, lsl #12 ; =0x100000
You can encode a 12-bit immediate in a SUB instruction on ARM64. We can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x5280003a mov w26, #0x1 ; =1
0xcb1a033b sub x27, x25, x26
After:
0xd100073b sub x27, x25, #0x1
While we cannot always avoid materializing immediates, we can still
inspect the most significant bit and potentially skip sign extension.
This can sometimes save an instruction.
Before:
0x5280003a mov w26, #0x1 ; =1
0x93407f5b sxtw x27, w26
0xcb38c37b sub x27, x27, w24, sxtw
After:
0x5280003a mov w26, #0x1 ; =1
0xcb38c35b sub x27, x26, w24, sxtw
Before:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb38c339 sub x25, x25, w24, sxtw
After:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb180339 sub x25, x25, x24
You can encode a shifted 12-bit immediate in an ADD instruction on
ARM64. If the negated constant fits in this range, we can exploit this
to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52bff01a mov w26, #-0x800000 ; =-8388608
0x93407f1b sxtw x27, w24
0xcb3ac37b sub x27, x27, w26, sxtw
After:
0x93407f1b sxtw x27, w24
0x9160037b add x27, x27, #0x800, lsl #12 ; =0x800000
You can encode a 12-bit immediate in an ADD instruction on ARM64. If the
negated constant fits in this range, we can exploit this to avoid
materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x12800019 mov w25, #-0x1 ; =-1
0x93407f5b sxtw x27, w26
0xcb39c37b sub x27, x27, w25, sxtw
After:
0x93407f5b sxtw x27, w26
0x9100077b add x27, x27, #0x1
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00099 mov w25, #0x40000 ; =262144
0x93407f7a sxtw x26, w27
0xcb39c35a sub x26, x26, w25, sxtw
After:
0x93407f7a sxtw x26, w27
0xd141035a sub x26, x26, #0x40, lsl #12 ; =0x40000
You can encode a 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52800416 mov w22, #0x20 ; =32
0x93407f78 sxtw x24, w27
0xcb36c318 sub x24, x24, w22, sxtw
After:
0x93407f78 sxtw x24, w27
0xd1008318 sub x24, x24, #0x20
A number of settings in the `debugger` group were wrongly using a newly
constructed `QSettings` object instead of the singleton object that
`GetQSettings()` provides.
This made the application create a spurious, extra configuration file in
the user directory:
```
~/.config/Dolphin Emulator/dolphin-emu.conf
```
Notice that, by default, the application configuration files are stored
in `~/.config/dolphin-emu`; not in `~/.config/Dolphin Emulator`.
Adding a community-requested list of Gecko and Action Replay codes to the allowlist. Many of these codes were from the wiki and are being added to Dolphin's repo for the first time.
Change the displayed controls in the TAS Input window when the
controller's extension (including MotionPlus) is changed.
This previously required restarting Dolphin after the attachment was
changed, as the controls were never updated after the WiiTASInputWindow
was created at Dolphin startup.
When I wrote 71e9766519, there was an interaction I didn't take into
account: When setting eq, SetCRFieldBit assumes that all bits in the
passed-in host register except the least significant bit are 0. But if
we use EON or ORN, all bits except the least significant bit get set to
1. This can cause eq to end up unset when it should be set.
This commit fixes the issue.
crandc is unaffected by the issue because the "1" bits get ANDed with
"0" bits from the first operand.
Note that in practice, we never have both bits_1_to_31_are_set and
negate at once, so while it looks like this commit adds an extra AND
instruction in some cases, those cases don't happen in practice, meaning
this fix shouldn't affect performance.
QCheckBox::toggled and other similar signals are used to save changes and to update widget status (such as enabled).. OnConfigChanged needs to load new values and trigger widget updates, but the new value shouldn't trigger a save. A save is unnecessary (the config has the correct values and the UI is being updated to those values) and it'd trigger another ConfigChanged signal. This commit blocks the save without blocking the signal entirely.
The computed value is only used when the register is equal to zero, so
we can fully precompute it and materialize the constant instead. In
other words, we change from
```
return reg == 0 ? (reg | 1ULL << 63) : reg;
```
to
```
return reg == 0 ? 1ULL << 63 : reg;
```
The number of instructions remains the same, but we eliminate an
unnecessary dependency on the register value.
Before:
0xb241037a orr x26, x27, #0x8000000000000000
0xeb1f037f cmp x27, xzr
0x9a9a137b csel x27, x27, x26, ne
After:
0xd2f0001a mov x26, #-0x8000000000000000 ; =-9223372036854775808
0xeb1f037f cmp x27, xzr
0x9a9a137b csel x27, x27, x26, ne
In NandPaths.cpp, the `std::initializer_list<char>` of illegal characters has been turned into a `char[]` (similar to the one in GameList.cpp).
The reverse iteration in ResourcePack.cpp seemed to provide no benefits, and doing without it it seemed to have no ill effects.
The new `Common::Contains` and `Common::ContainsSubrange` function objects mirror C++23's `std::ranges::contains` and `std::ranges::contains_subrange`, respectively.
Recently there was some issues in TASVideos trying to sync a Donkey Kong Country Returns TAS. It eventually was synced by directly using the config from the TAS author. The exact setting which caused the desync was narrowed down to being in SYSCONF, with the country code. The TAS author lives in the US, so the country code matched the US country code, while the person attempting to sync the TAS did not live in the US.
Adding SYSCONF country code to the DTM should avoid this being an issue for future Dolphin versions.
When the input register and carry flags are known, we can always
precompute the result.
We still materialize the immediate when the condition register
needs to be updated, but this seems to be a general problem. I might
look into that one day, but for now this'll do.
- ConstantFalse
Before:
0x52800119 mov w25, #0x8 ; =8
0x2a1903fa mov w26, w25
After:
N/A
- ConstantTrue
Before:
0x52800119 mov w25, #0x8 ; =8
0x1100073a add w26, w25, #0x1
After:
N/A
Same optimization we did for subfex. Skip loading the carry flag into a
temporary register first when we're dealing with zero.
Before:
0x394bd3b8 ldrb w24, [x29, #0x2f4]
0x2a1803f9 mov w25, w24
After:
0x394bd3b9 ldrb w25, [x29, #0x2f4]
When both the input register and the carry flag are constants, the
result can be precomputed.
Before:
0x52800016 mov w22, #0x0 ; =0
0x2a3603f6 mvn w22, w22
After:
The result is either -1 or 0 depending on the state of the carry flag.
This can be done with a csetm instruction.
Before:
0x1280001a mov w26, #-0x1 ; =-1
0x1a1f035a adc w26, w26, wzr
After:
0x5a9f23fa csetm w26, lo
When the immediate is zero, we can load the carry flag from memory
directly to the destination register.
Before:
0x394bd3b8 ldrb w24, [x29, #0x2f4]
0x2a1803f9 mov w25, w24
After:
0x394bd3b9 ldrb w25, [x29, #0x2f4]
Resolves duplicate OSD messages for Loading and Found custom textures.
VideoBackend initialization results in HiresTexture::Init being called.
We already call HiresTexture::Update when OnNewTitleLoad is called.
Thus we can remove HiresTextures::Init completely as it is redundant.
No games seem to use this, so this isn't useful as a performance
optimization, but it's required for correctness because the (sh == 0)
case of our implementation doesn't handle zero masks.
In JitRegCache.cpp, the lambda predicate were replaced by a pointer to member function because ranges algorithms are able to invoke those.
In ConvertDialog.cpp, the `std::mem_fn` helper was removed because ranges algorithms are able to handle pointers to member functions as predicates.
In BoundingBox.cpp, the lambda predicate was returning the bool element unchanged, so `std::identity` was a better fit.
In WiimoteReal.cpp, JitRegCache.cpp, lambda predicates were replaced by pointers to member functions because ranges algorithms are able invoke those.
In ConvertDialog.cpp, the `std::mem_fn` helper was removed because ranges algorithms are able to handle pointers to member functions as predicates.
In DITSpecification.cpp, MaterialAsset.cpp, and ShaderAsset.cpp, lambda predicates were replaced by pointers to member functions because ranges algorithms are able invoke those.
In NetPlayClient.cpp, the non-trivial `NetPlay::Player` elements were being passed by value in `NetPlayClient::DoAllPlayersHaveGame()`. This has been fixed.
In WIABlob.cpp, the second example's predicate was returning the `std::optional` by value instead of implicitly converting it to a bool. This has been fixed.
Creates a layer outside the game config layer system and passes it to the created gfx widows, so as to not interfere with the global config system.
Supports multiple game properties being open at once.
Supports editing while a game is playing, but the options only save and update the active game when the window is closed.
Right-clicking will remove a property from the game ini.
New code adds a test failure if there's a Patches/Gecko/AR_Retroachievements_Verified code that doesn't appear to actually exist in the file. This will catch if the allowed patch is formatted wrong, which I found happening several times already due to not realizing that the patch author's name would need to be omitted.
Prefer BLENDVPD over VBLENDVPD if the latter doesn't save any
instructions.
VBLENDVPD allows separate source and destination registers, which can
eliminate a MOVAPD/MOVSD. However, on Intel since Skylake, VBLENDVPD
takes additional uops to execute compared to BLENDVPD (according to
https://uops.info). On AMD and older Intel microarchitectures there is no
difference.
Some generators (like Unix Makefiles and Xcode) copy an app's Info.plist at configure time.
This causes a problem when we need to generate the Info.plist at build time, like how we
currently do it with ScmRevGen. Instead of generating the Info.plist directly in ScmRevGen,
provide an Info.plist without any version information to CMake at configure time, have
ScmRevGen generate a separate plist file with the version information at build time, and
then merge the two together to create the final Info.plist.
The read thread could call Reset, which in turn tried to join the read
thread, leading to a SIGABRT. This manifested as Dolphin consistently
crashing when disconnecting a GC adapter and having a chance of crashing
a few seconds after connecting a GC adapter.
Now that patches and codes are enabled on a case by case basis, remove patcher code blocking codes entirely in hardcore mode, and reword the warning to be more accurate.
This apparently didn't compile on macOS six years ago before c++20, but
it should be fine by now.
While I'm at it, make the constants upper case per convention.
If the host is in hardcore mode, all joining players will be set to hardcore mode; if not, all joining players will be set to softcore. This ensures all players have the same settings and remain synchroized.
The primary focus of this PR is the Eternal Darkness patch which fixes hanging at startup, which prior to this fix makes Eternal Darkness unplayable in hardcore. The MHTri patch was added as well simply because it could be.
GXAbortFrame() is problematic for Dolphin because it first writes
PI_FIFO_RESET (for which we discard our internal fifo), then disables CP
reads (for which we execute pending commands in the GP fifo in emulated
memory). I don't know whether there is a race condition on hardware, but
there is one for us. Avoid this by also doing a GPU sync here.