This adds the option to configure real Wiimotes by specifying their Bluetooth addresses in
the configuration file. This allows off-brand Wiimotes to work without using the
Bluetooth Passthrough option, if you know their Bluetooth addresses beforehand.
Despite correctly setting the LAP to `0x9e8b00` in `WiimoteScannerLinux::FindWiimotes`
while scanning, which is indeed enough to make off-brand / knock-off Wiimotes respond to a
Bluetooth Inquiry, some (several? all?) bluetooth adapters seem to override and ignore
this given LAP value when performing the Inquiry, and actually use the `0x9e8b33` value as
if a null pointer have been given to `hci_inquiry`, as inspection of USB/Bluetooth packets
by Wireshark indicate. Off-brand Wiimotes don't respond to inquiries with this LAP.
If one happens to know the Bluetooth address of their Wiimote (for example, by checking
`BluetoothPassthrough.LinkKeys` after using Bluetooth Passthrough, or other means such as
directly using `libusb` to force the adapter to use the correct LAP in the Inquiry), then
it's enough to add those addresses to the vector of found Wiimotes.
Since this a niche use case and I only happen to know and have tested in Linux, this
change only affects the `WiimoteScannerLinux` backend. It's likely that it could be added
to other backends, but I'm unfamiliar with these.
If no addresses are given or this config section does not exist, behavior is completely
unchanged.
Introduce a new "Enable Time Tracking" checkbox in the InterfacePane UI. The checkbox is dynamically enabled or disabled based on the emulation state, preventing changes while emulation is active.
Creates TimePlayed class and implemented constructors, AddTime, GetTimePlayed, and Reload methods. Updates CMakeLists.txt and DolphinLib.props as appropriate.
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.
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.
All valid PPC imm masks (except for all zeroes and all ones) are also
valid AArch64 imm masks. This lets us optimize things a little.
Note that because I'm now ANDing rS before rotating it, its AND mask
is rotated left. All AArch64 imm masks can be rotated by any amount and
still be valid AArch64 imm masks.
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.
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.
The value being stored must be loaded into a register. In the case of an
immediate value, this means it must be materialized. The value is
eventually byteswapped before performing the store.
This can be simplified for the value 0 for two reasons:
- ARM64 has a dedicated zero register, so does not need to be
materialized.
- Byteswapping zero is still zero, so we can skip this step.
We could skip byteswapping for other values by immediately materializing
the byteswapped value in a register, but the benefits are not so clear
there (if the value needs to be materialized anyway, it is better to do
it up front).
Before:
0x5280001b mov w27, #0x0 ; =0
0xb9404fba ldr w26, [x29, #0x4c]
0x12881862 mov w2, #-0x40c4 ; =-16580
0x0b020342 add w2, w26, w2
0x5ac00b61 rev w1, w27
0xb8226b81 str w1, [x28, x2]
After:
0xb9404fbb ldr w27, [x29, #0x4c]
0x12881862 mov w2, #-0x40c4 ; =-16580
0x0b020362 add w2, w27, w2
0xb8226b9f str wzr, [x28, x2]
Unlike on x64, inverting EQ or GT in SetCRFieldBit saves us one
instruction. Also unlike on x64, inverting SO or LT in GetCRFieldBit
requires an extra instruction (just like in SetCRFieldBit). Due to this,
replacing an invert in GetCRFieldBit with an invert in SetCRFieldBit
when possible is either equally good or better - never worse.
MUL and SUB can be combined in one instruction.
Before:
0x1b1a7c01 mul w1, w0, w26
0x4b010318 sub w24, w24, w1
After:
0x1b1ae018 msub w24, w0, w26, w24
Makes Graphics -> Hacks -> Skip EFB Access from CPU enabled by default. Some GPU drivers stall when EFB access occurs in games where EFB is not used. Most games that require this setting set to 'true' already have this defined in their game inis.
`std::erase` is a replacement for the remove-erase idiom.
Changes to `OpenModeToAndroid` inadvertently revealed that the prior implementation had UB (potentially deleting the end iterator). This is now fixed.
Three bugs specific to older Wii games:
- The size difference between high-pass and biquad filter was not
accounted for, causing wiimote related fields to be corrupted.
- Wiimote sample buffer pointers were advanced by 32 samples per
millisecond instead of 6 samples. Usually hidden by the first bug.
- PB updates on Wii were being byte-swapped twice, but I've not actually
found any Wii games that make use of PB updates.
This fixes wiimote audio in at least the following games:
- Excite Truck
- Ice Age 2: The Meltdown
- Kororinpa: Marble Mania
- Rapala Tournament Fishing
- Shrek the Third
- Super Monkey Ball: Banana Blitz
- Tiger Woods PGA Tour 07
- WarioWare: Smooth Moves (issue 11725)
- Wing Island
Fixes LIT (https://bugs.dolphin-emu.org/issues/13635). The text does not include normals, but has lighting enabled. With the previous default of (0, 0, 0), lighting was always black (as dot(X, (0, 0, 0)) is always 0). It seems like the normal from the map in the background (0, 0, 1) is re-used.
LIT also has the vertex color enabled while vertex color is not specified, the same as SMS's debug cubes; the default MissingColorValue GameINI value of solid white seems to work correctly in this case.
No need to materialize the immediate if it is zero, we can just use WZR.
Before:
mov w27, #0x0 ; =0
str w27, [x29, #0x1178]
After:
str wzr, [x29, #0x1178]
In VolumeVerifier.cpp, constructing a `std::string_view` of the volume's GameID is unnecessary, as `std::`(`ranges::`)`binary_search` supports heterogeneous lookup. The usage in GameFile.cpp is a perfect example.
In OGLConfig.cpp, `std::views::reverse` is used rather than sorting using `std::ranges::greater` in order to parallel other instances of reverse iteration in the function.
In DSPCore.cpp, there were two `std::fill` uses that could be simplified using `std::fill_n`. Due to their proximity with other `std::fill` algorithms being modernized with ranges, I chose to make these examples into the rare `std::ranges::fill_n`.
In StringUtil.h, the lambdas wrapping `Common::ToLower(char)` and `Common::ToUpper(char)` were only necessary due to the function names being overloaded.
Many games call GXSetGPFifo() without first waiting for the GP to finish
consuming outstanding commands in the previous GP fifo. Normally,
Dolphin runs OpcodeDecoding in 1000-cycle time slices. In that time
frame, GXSetGPFifo() has probably completed and the GP read pointer now
points to entirely new memory. If the last GP fifo copy ended in an
incomplete command, the new GP fifo would most likely desync for a
while. To avoid all this, give the GP a time slice right now to copy the
remaining data from the previous GP fifo.
Indexed XF loads specify the number of 32-bit words (generally floats, but light data has some integers) to load, not the number of bytes. This was only a mistake in the fifo analyzer text; the actual implementation already loaded words.
The light LIT fifolog from https://bugs.dolphin-emu.org/issues/13635 has position data at physical address 11ae3180. This works fine when using the memory viewer in physical mode, but the corresponding virtual address (91ae3180) previously didn't show anything in effective mode. It works fine now though.
This shouldn't affect playback of fifologs as everything in there uses physical addresses; this only impacts the memory viewer.
This logic was copied from CBoot::SetupBAT.
This reverts the revert commit bc67fc97c3,
except for the changes in BaseConfigLoader.cpp, which caused the bug
that made us revert 72cf2bdb87. PR 12917
contains an improved change to BaseConfigLoader.cpp, which can be merged
(or rejected) independently.
A few changes have also been made based on review comments.
Found this bug while testing; if I manually edit the config files while Dolphin is closed I was able to get debug and hardcore on at the same time, this resolves that.
AchievementManager::SetHardcoreMode now handles the (non-Qt) settings disabled by hardcore mode, instead of doing this on the Qt layer. Also ensured Init/Enable Achievements paths run this code, fixing the bug wherein the player can manipulate things when achievements are disabled that persist when turned back on.
Prevent potential issues when creating the Graphics window (and thus
calling PopulateBackendInfo) while the core state is Stopping, like we
already do while it's Starting or Running.
Remove the PopulateBackendInfoFromUI function, which had a single caller
(GraphicsWindow::OnBackendChanged) and checked that the core wasn't
running or starting before calling PopulateBackendInfo.
Move the core state check into PopulateBackendInfo and have
OnBackendChanged call that instead. This guarantees the check is
performed by all callers of PopulateBackendInfo, preventing
potential reintroduction of the crash fixed in 3d4ae63f if another call
to PopulateBackendInfo is added.
As of the previous commit the only other caller of PopulateBackendInfo
is Core::Init shortly before s_state is set to Starting, so it will
always pass the check and so maintain its current behavior.
Remove the second of two calls to PopulateBackendInfo during emulation
startup. This call was originally the only one, but b214e0e added an
earlier call to handle the backend being changed by the GameINI.
The PR discussion doesn't explain why the original call was left in; I
suspect it was just overlooked.
As a bonus, this removes one of the extra copies of the "Video Info" On
Screen Display message at startup when using OpenGL.
Fix a crash when opening the Graphics window for the first time during
emulation startup when the backend is Vulkan, D3D11, or D3D12.
Don't call PopulateBackendInfo() from the Host thread when the core is
starting up. First, the function has already been called in Core::Init()
so we don't need to again. More importantly, PopulateBackendInfo() calls
g_video_backend->InitBackendInfo(), and the Vulkan and D3D
implementations of those functions load and then unload libraries (and
their associated function pointers) which are potentially in use by
other threads.
This crash was reliably reproducible with the following steps:
1) Select an affected backend.
2) Enable "Compile Shaders Before Starting"
3) Delete the cached shaders (but not the .uidcache file) for the game
you're testing.
4) Close and reopen Dolphin.
5) Start the game.
6) While the game is still booting or compiling shaders, open the
Graphics window for the first time in that Dolphin session.
Fixes https://bugs.dolphin-emu.org/issues/13634.
Before, Dolphin would randomly crash when updating the cheat search when automatic refresh was enabled. (Having a large number of addresses listed, e.g. by starting with an "any value" search, may contribute). The crash was due to QTableWidget::item returning nullptr in RefreshGUICurrentValues, presumably due to the table being resized on the UI thread while the emulated CPU thread was updating the values. I've fixed this by pausing the CPU thread for the entirety of OnNextScanClicked; this eliminated crashes in my testing.
With 12 uses of `JoinStrings` in the codebase vs 36 uses of `fmt::join`, fmtlib's range adapter for string concatenation with delimiters is clearly the preferred option.
Migrating `Common::CaseInsensitiveLess` to StringUtil.h will hopefully discourage rolling one's own solution in the future for case-insensitive associative containers when this (quite robust!) solution already exists.
`Common::CaseInsensitiveStringCompare::IsEqual` was removed in favor of using the `Common::CaseInsensitiveEquals` function.
The `a.size() != b.size()` condition in `Common::CaseInsensitiveEquals` can be removed, since `std::ranges::equal` already checks this condition (confirmed in libc++).
There were three distinct mechanisms for signaling breakpoint changes in DolphinQt, and the wiring had room for improvement. The behavior of these signals has been consolidated into the new `Host::PPCBreakpointsChanged` signal, which can be emitted from anywhere in DolphinQt to properly update breakpoints everywhere in DolphinQt.
This improves a few things:
- For the `CodeViewWidget` and `MemoryViewWidget`, signals no longer need to propagate through the `CodeWidget` and `MemoryWidget` (respectively) to reach their destination (incoming or outgoing).
- For the `BreakpointWidget`, by self-triggering from its own signal, it no longer must manually call `Update()` after all of the emission sites.
- For the `BranchWatchDialog`, it now has one less thing it must go through the `CodeWidget` for, which is a plus.
If texture dumping is enabled, notify the user on emulation startup
using an On Screen Display message.
Also notify the user when texture dumping is toggled.
Addresses https://bugs.dolphin-emu.org/issues/12445.
The low-pass and biquad filters run in set40 mode where accessing ac#.m
returns the value of ac#.hm clamped to 16 bits.
This fixes the crackling in "Need for Speed: Nitro" (issue 13610).
Also make the lower bound match hardware (-0x8000 instead of -0x7FFF).
During 25-bit rounding, subnormals are "normalized"
This would normally mean that the exponent needs to be able to be <-1023
Instead, you can modify at what bit you round and get the same results!
This is done by finding the highest bit and shifting right the round bit
Co-Authored-By: JosJuice <josjuice@gmail.com>
Changes integer rounding to more closely meet the documentation
The documentation explains to round before doing any bounds checks
All this really does is make sure some exception bits won't be set wrong
This depends on the rounding mode, fixing cases such as:
- Round to even, (0x7fffffff, 0x7fffffff.8)
- Round to down, (0x7fffffff, 0x80000000)
This change also uses some standard functions for rounding
Previously using them was casting to an s32 directly, now keeps the f64
RoundToIntegerMode introduced due to roundeven not being part of C++17
Finally, it can change a >0x7fffffff to >=0x80000000, done because:
- It looks nicer now with integers (I liked 0s)
- It gives ever so slightly better codegen on Aarch64
Co-Authored-By: JosJuice <josjuice@gmail.com>
I wasn't aware that even with a size of zero, it's still not safe to pass a nullptr to `std::memcpy`. When `CachedInterpreterEmitter::PoisonCallback` is written, UB is happening.
Invert conditions, invert decrement checks, and make conditional branches unconditional. USnapshotMetadata in prior versions of Dolphin is forward-compatible with these changes (tested on x86_64).
Objects which get parented automatically by later processing now pass a nullptr to the constructor to make the intent clearer. Also fixed "true" and "false" not being translatable strings.
This is a minor improvement to add line numbers to the LOG_VULKAN_ERROR
define. Basically error logs for Vulkan will now look like:
```
// This
25:03:347 VideoBackends/Vulkan/VulkanLoader.cpp:247 E[Video]: (WaitForCommandBufferCompletion:278) vkWaitForFences failed: (2: VK_TIMEOUT)
// Instead of
15:45:154 VideoBackends/Vulkan/VulkanLoader.cpp:247 E[Video]: (WaitForCommandBufferCompletion) vkWaitForFences failed: (2: VK_TIMEOUT)
```
Set the Render Window as the parent of the Confirm On Stop confirmation
dialog when Keep Window On Top is enabled, ensuring it will always be
visible.
Previously, when Confirm On Stop and Keep Window On Top were both
enabled the Confirm On Stop dialog could be hidden by the render window
in the following situations:
* Clicking Stop in the Main Window
* Clicking the Main Window's close button
* Pressing the Stop hotkey while in FullScreen mode
This was particularly troublesome because the confirm dialog is modal,
preventing the user from moving the render window out of the way if it
was obscuring the dialog.
Fixes https://bugs.dolphin-emu.org/issues/13247.
A vector of length 0 can have a null data pointer, which causes UB when
passed to memcpy, so only copy when we actually have data to copy. This
caused crashes in certain cases when compiling Dolphin with Clang and
LTO enabled.
Allow connecting or disconnecting multiple Wii Remotes simultaneously
instead of only handling the highest index whose hotkey is pressed. This
allows using a single hotkey to toggle multiple remotes.
Before the call to OnSelectionChange, m_code_edit and m_code_remove are
disabled and UpdateList calls m_code_list->clear(), thereby deselecting
any selected items.
When no items are selected, OnSelectionChange disables m_code_edit and
m_code_remove and then returns. Since that was already done, the call
doesn't change anything and can be removed.
Create ARCodeWidget and GeckoCodeWidget once on startup rather than
every time a game is launched or shutdown.
In addition to losing focus on the tab (since the previous widget and
tab no longer existed), the behavior prior to this commit could cause a
crash if the user initiated a game shutdown and then opened a code edit
window since the AR/GeckoCodeWidget would get deleted in the meantime.
Also some minor refactoring of nearby/related code:
* Make non-obvious variable types explicit instead of auto.
* Throw some consts around.
* Use setDisabled(empty) instead of setEnabled(!empty).
Changes the RetroAchievements "Log In" button's text to "To log in, stop the current emulation." when the button is disabled because an emulation session is active. This allows a user to understand why the button is disabled, and how this state can be resolved.
Previously, it could be unclear why this button was disabled without an understanding of the underlying system.
Co-Authored-By: JosJuice <josjuice@gmail.com>
The description of the Speed Limit setting currently uses a lot of
complicated terms, like "emulated time" (known to many Dolphin
developers, but in my experience not known by even advanced emulator
users) and "maximum time scale" (I have never heard it before). The
meaning of "sustainable" is also unclear in context.
This commit rewords the description to be easier to understand.
Fixes https://bugs.dolphin-emu.org/issues/13593. Before, it would attempt to
use the old shader, which did not exist for the new stereo mode. Changing the
postprocessing shader afterwards would work properly, although passive 3D only
has one option, so it was just broken without restarting Dolphin.
This also fixes the UI not updating when using one of the stereo toggle hotkeys.
These patches were added in bde9a459cd
and enabled by default in 36ecfdd6b5.
They allowed the game to run in Dolphin but disabled dynamic shadows.
The game adds 4 to the start address of otherwise valid display lists
for no obvious reason. Now that Dolphin forces 32-byte alignment these
patches are no longer needed.
`std::bit_cast` participates in overload resolution only if `sizeof(To) == sizeof(From)` and both `To` and `From` are *TriviallyCopyable* types, so the static assertions here can be removed. `[[nodiscard]]` was added as well.
For a long time now, we've had a problem where game INIs persist in
the copied Sys folder if they've been deleted from the original Sys
folder. (I still have hundreds of game INIs locally that only set
EmulationStateId, and we removed those game INIs 6 years ago. On the
buildbot, we do occasionally clear out the build directories manually,
so I'd assume it's not quite as bad there.)
This commit fixes the problem by deleting the output Sys folder before
copying the original Sys folder to the output Sys folder. This should be
a bit slower, but in my testing, the difference seems small. At least if
you have an SSD, which I really hope people have nowadays!
Operating systems other than Windows have not been touched, because:
* Android: Already explicitly deletes the output Sys folder.
* macOS: Does some magic to put the Sys folder in the app bundle, which I
will simply assume isn't affected by this problem, without testing.
* Linux: Expects the person building to manually manage the Sys folder.
Update the checkmarked slot in the Select State Slot menu when the
Increase Selected State Slot or Decrease Selected State Slot hotkeys are
pressed.
The actual selected save slot was being changed correctly before this
commit; this just fixes the menu checkmark.
The biquad filter is used in all Pikmin games for cursor sound effects
in the main menu, although the difference is subtle.
The low-pass filter is used at least by Pikmin 2 Wii during the
spaceship crash in the intro and fixes the missing "puff" sound effects
whenever there is black smoke coming out of the engine.
With this change, a different message is displayed if starting a game with RetroAchievements fails due to the Dolphin version being blocked as opposed to failing because the game hash is unsupported.
This compile definition was removed in 68cbd2640d because it was complicated by changes in 50dc0ffbce. Thus, the LLVM disassembler would never be used in UICommon's Disassembler class.
`Layer::Save` only does its thing if the layer has `is_dirty == true`.
But SYSCONF could have been modified by other layers, so if the base layer wasn't made dirty by anything else, then it wouldn't be restored.
Fixes https://bugs.dolphin-emu.org/issues/13580
I tried making the new templated Interpret callback test only the relevant exceptions (EXCEPTION_DSI, EXCEPTION_PROGRAM, or both), but didn't find a significant performance boost in it. As I am learning, the biggest bottleneck is the number of callbacks emitted, not usually the actual contents of them.
WritePC is now needed far less, only for instructions that end the block. Unfortunately, WritePC still needs to update `PowerPCState::npc` to support the false path of conditional branch instructions. Both drawbacks should be smoothed over by optimized cached instructions in the future.
Use QObject->deleteLater() instead of the delete operator to destroy
child widgets of the layout. This prevents crashes caused by pending
events trying to access the now-destroyed widget.
The player_index field in question is ultimately what gets used to determine which ranks get displayed in the leaderboards chart, and because this was missing the chart was simply displaying the top four results no matter what.
The cause of the leaderboard spam was primarily this call where if there was an attempt to get leaderboard info and there wasn't already, there would be a fetch request. This is bad for many reasons: some games have hundreds of boards that will be fetched at startup, if there's simply no data to populate that board, this will just continue to fetch every time the dialog needs to update. To mitigate this, I simply don't load leaderboard information until there are events for that leaderboard - less information for the player, sadly, but heavily cuts down on the number of leaderboard fetches.
Now that we have some test data, it wasn't showing up in the leaderboards tab; this fixes it to ensure (1) that the right ID is being passed to UpdateRow and (2) the map of leaderboard entries is being populated correctly.
Currently we're showing OSD messages for unknown patches in known INI
files, but not for unknown patches in unknown INI files. I don't think
this distinction makes much sense to the user. If there's a patch the
user can't use, they probably want to be aware of that fact.
0c14b0c8a7 made Dolphin load a file from
the Sys folder the first time AchievementManager::GetInstance() is
called. Because Android calls AchievementManager::GetInstance() from
setBackgroundExecutionAllowedNative, this had two negative consequences
on Android:
1. The first time setBackgroundExecutionAllowedNative gets called is
often before directory initialization is done. Getting the path of
the Sys folder before directory initialization is done causes a crash.
2. setBackgroundExecutionAllowedNative is called from the GUI thread,
and we don't want file I/O on the GUI thread for performance reasons.
This change makes us load the data from the Sys folder the first time
the data is needed instead. This also saves us from having to load the
data at all when hardcore mode is inactive.
We mustn't use m_system when it is nullptr. This was causing Dolphin to
crash on Android whenever an activity was recreated or resumed while
emulation is running, which is super common.
Prototype of a system to whitelist known game patches that are allowed to be used while RetroAchievements Hardcore mode is active. ApprovedInis.txt contains known hashes for the ini files as they appear in the repo, and can be compared to the local versions of these files to ensure they have not been edited locally by the player. ApprovedInis.txt is hashed and verified similarly first, with its hash residing as a const string within AchievementManager.h, ensuring ApprovedInis and the hashes within cannot be modified without editing Dolphin's source code and recompiling completely.
The challenge popups have proven to be excessive and are no longer useful thanks to the achievements hotkey. Instead, those events will ask for an immediate RP-level update to the achievements dialog, which will among other things re-sort the dialog to show challenges on top faster.
This way, by pressing Continue on top of a breakpoint, the emulation will actually continue (like on Cached Interpreter and JIT), instead of doing nothing.
Before:
1. In theory there could be multiple, but in practice they were (manually) cleared before creating one
2. (Some of) the conditions to clear one were either to reach it, to create a new one (due to the point above), or to step. This created weird behavior: let's say you Step Over a `bl` (thus creating a temporary breakpoint on `pc+4`), and you reached a regular breakpoint inside the `bl`. The temporary one would still be there: if you resumed, the emulation would still stop there, as a sort of Step Out. But, if before resuming, you made a Step, then it wouldn't do that.
3. The breakpoint widget had no idea concept of them, and will treat them as regular breakpoints. Also, they'll be shown only when the widget is updated in some other way, leading to more confusion.
4. Because only one breakpoint could exist per address, the creation of a temporary breakpoint on a top of a regular one would delete it and inherit its properties (e.g. being log-only). This could happen, for instance, if you Stepped Over a `bl` specifically, and pc+4 had a regular breakpoint.
Now there can only be one temporary breakpoint, which is automatically cleared whenever emulation is paused. So, removing some manual clearing from 1., and removing the weird behavior of 2. As it is stored in a separate variable, it won't be seen at all depending on the function used (fixing 3., and removing some checks in other places), and it won't replace a regular breakpoint, instead simply having priority (fixing 4.).
Now it actually does what it says on the name, instead of creating a breapoint and doing nothing else (not even updating the widget).
Also, it now can't be selected if emulation isn't running.
Closes https://bugs.dolphin-emu.org/issues/13532
Change misleading names.
Fix function usage: Intepreter and Step Out will not check breakpoints in their own wrong way anymore (e.g. breaking on log-only breakpoints).
There are two pieces of functionality to be added here. One, we want to disallow pausing too frequently, as it may be used as an artificial slowdown. This is handled within the client, which can tell us if a pause is allowed. Two, we want to call rc_client_idle on a periodic basis so the connection with the server can be maintained even while the emulator is paused.
When the immediate value is zero, we can do a negation. On ARM64 the NEG
/NEGS instructions are just an alias for SUB/SUBS with a hardcoded WZR.
Before:
```
ldr w22, [x29, #0x28]
mov w21, #0x0 ; =0
subs w22, w21, w22
```
After:
```
ldr w22, [x29, #0x28]
negs w22, w22
```
This reverts commit 72cf2bdb87.
SYSCONF settings are getting cleared when they shouldn't be. Let's
revert the change until I get proper time to figure out why it's broken.
Whenever a request to update the Rich Presence comes in, typically every ten seconds, the Achievement Progress Widget will update the sort order of the achievements and all of their measured values.
bugfix: SetQWidgetWindowDecorations(this); not called before show() for Windows darkmode titlebars.
The actual call to (QWidget) show() needed to come sooner. Show() was originally left alone, but with other checks needing to move with (QWidget) show(), this function became less useful. Show() was originally created to fix the render widget appearing behind the main window, but that appears to work fine in this iteration.
The measured_progress C string for achievements to display potentially contains junk data after the null terminator, which was rendering in the QString in the dialog. This trims those junk characters.
This causes Dual Core to lock up during the boot sequence, because it tries to wait for a not-yet-running GPU thread.
Fixes https://bugs.dolphin-emu.org/issues/13559
rc_client calls the provided memory peeker asynchronously in the callback for starting a session, to validate/invalidate the memory used for achievements. Dolphin cannot access memory from any thread but host or CPU so this access has a small chance of being invalid. This commit adds a MemoryVerifier that the AchievementManager will use to perform this, before changing the peek method back to the original MemoryPeeker for normal operation.
Some pieces of code are calling IsRunning because there's some
particular action that only makes sense when emulation is running, for
instance showing the state of the emulated CPU. IsRunning is appropriate
to use for this. Then there are pieces of code that are calling
IsRunning because there's some particular thing they must avoid doing
e.g. when the CPU thread is running or IOS is running. IsRunning isn't
quite appropriate for this. Such code should also be checking for the
states Starting and Stopping. Keep in mind that:
* When the state is Starting, the state can asynchronously change to
Running at any time.
* When we try to stop the core, the state gets set to Stopping before we
take any action to actually stop things.
This commit adds a new method Core::IsUninitialized, and changes all
callers of IsRunning and GetState that look to me like they should be
changed.
Core::GetState reads from four different pieces of state: s_is_stopping,
s_hardware_initialized, s_is_booting, and CPUManager::IsStepping.
I'm keeping that last one as is for now because there's code in Dolphin
that sets it directly, but we can unify the other three to make things
easier to reason about.
This commit also gets rid of s_is_started. This was previously used in
Core::IsRunningAndStarted to ensure true wouldn't be returned until the
CPU thread was started, but it wasn't used in Core::GetState, so
Core::GetState would happily return State::Running after we had
initialized the hardware but before we had initialized the CPU thread.
As far as I know, there are no callers that have any real need to know
whether the boot process is currently initializing the hardware or the
CPU thread. Perhaps once upon a time there was a desire to make the
apploader debuggable, but a long time has passed without anyone stepping
up to implement it, and the way CBoot::RunApploader is implemented makes
it rather difficult. So this commit makes all the functions in Core.cpp
consider the core to still be starting until the CPU thread is started.
When AchievementProgress::UpdateData(false) is called, it will now empty itself and reinsert all existing boxes, re-sorted into their current buckets, and call UpdateProgress on them all.
Rerendering the entire Achievements dialog every EmulationStateChanged signal is far too often when it turns out that signal fires multiple times to confirm game close, for example. This change results in only the settings changing on EmulationStateChanged, and having the Hardcore mode toggle (which DOES require redrawing the entire dialog) emit its own signal alongside EmulationStateChanged.
AchievementBox now has UpdateData and UpdateProgress, which is called from UpdateData, but may be called elsewhere to update just the progress measurement of the achievement.
CPU Clock Override slider now increments 1% in the UI, with the new lower limit
being 1% instead of 6%.
Prior implementation made it impossible to set exactly 150% in the GUI.
147% -> 152%. Now users can set exact clock % without needing to edit INIs.
rc_client provides basic sorting buckets as a possible option when retrieving the list of achievements or leaderboards; this enables them and labels them in the dialog.
Since rcheevos headers are included in AchievementManager.h, and everyone that depends on Core can include that, we must also pass on the include directory and defines to those dependencies
Storing the log type names in a map results in them getting re-sorted by
their keys, which doesn't quite give us the sorting we want. In
particular, the Achievements category ended up being sorted at R (for
RetroAchivements) instead of at A. Every use of the map is just
iterating through it, so there's no real reason why it has to be a map
anyway.
If an icon is displayed on screen before it downloads, it was displaying a default icon but it would fail to load the actual icon even after it was downloaded. This fixes that.
Add a two second timer to Achievement Progress Indicators to wait until two seconds after the previous message (when it should have decayed out automatically) before posting any new ones.
Prior to this change, attempting to decrease the speed limit below 100% in hardmode would display the new attempted speed and then warn that the speed can not be decreased below 100%; this disables that first message under those conditions.
AchievementManager maintains a unique pointer to a copy of the current volume so it can asynchronously hash that volume. It is not needed otherwise, so I can release that pointer when hashing is complete. This change fixes a bug whereby changing discs in a game and then changing to a different game would result in the loaded volume pointer still being loaded with and hashing to the previous game.
This lets us reduce the number of USE_RETRO_ACHIEVEMENTS ifdefs in the
code base, reducing visual clutter. In particular, needing an ifdef for
each call to IsHardcodeModeActive was annoying to me. This also reduces
the risk that someone writes code that accidentally fails to compile
with USE_RETRO_ACHIEVEMENTS disabled.
We could cut down on ifdefs even further by making HardcodeWarningWidget
always exist, but that would result in non-trivial code ending up in the
binary even with USE_RETRO_ACHIEVEMENTS disabled, so I'm leaving it out
of this PR. It's not a lot of code though, so I might end up revisiting
it at some point.
Enable emulator hotkeys and controller input (when that option is
enabled) when a TAS Input window has focus, as if it was the render
window instead. This allows TASers to use frame advance and the like
without having to switch the focused window or disabling Hotkeys Require
Window Focus which also picks up keypresses while other apps are active.
Cursor updates are disabled when the TAS Input window has focus, as
otherwise the Wii IR widget (and anything else controlled by the mouse)
becomes unusable. The cursor continues to work normally when the render
window has focus.
Using shifts and bit tests makes the code unnecessarily annoying to
reason about. I'm replacing it with subtracting from 3 to translate the
bit order from the PowerPC format to the usual format.
BI contains both the field and the flag (5 bits total), so we need to
shift away the 2 flag bits to get the 3 field bits. (Same as the
CRBA/CRBB handling in the code just below the BI code.)
The names attached to the BadgeStatus object are obsolete and unneeded and are removed from everything that uses them. All BadgeStatus references are updated to just Badge.
The defaults get loaded in by Dolphin at emulator start, and are used if the badge that would normally be displayed has not for whatever reason been downloaded yet. Badges attached to this PR are placeholders (MayIMilae is designing permanent badges) and reside in Sys\Load\RetroAchievements.
Achievement badges/icons are refactored into the type CustomTextureData::ArraySlice::Level as that is the data type images loaded from the filesystem will be. This includes everything that uses the badges in the Qt UI and OnScreenDisplay, and similarly removes the OSD::Icon type because Level already contains that information.
Was informed by the RetroAchievements team that this isn't an option in most emulators, and as the next commits will be to enable default icons, there will always be something to display.
On Windows:
wsi.render_window being set will set/save the initial geometry, which will cause sizing bugs until it's set again by the user resizing/repositioning.
If Rich Presence and Discord Presence are enabled in Achievement Settings, the string generated by rcheevos as the player's current Rich Presence will be sent to the Status field in the Discord Presence object. This will be updated whenever Rich Presence updates.
The "welcome message" that shows up to players when a game starts up and Achievements are active will now either tell the player upon load that there's no support for achievements, or will wait until the first attempt to load the game's badge either succeeds or fails and then display a full message with title and progress and status. This is in part facilitated by a boolean field for when to display a welcome message, set to true upon loading and to false upon a message being displayed.
If achievements were disabled but a player token is in settings, prior to this change the Achievement Manager dialog would show a box with no player name and score zero, which is unnecessary.
Due to an oversight in our CMakeLists, pkg-config would attempt to find *minizip* 3.0.0 (which doesn't exist) instead of *minizip-ng* 3.0.0, or at least it was on my Manjaro Linux machine. This has been fixed. The new submodule is using minizip-ng 3.0.4, the same version that was being used before.
NetBSD doesn't put packages in /usr/local like /CMakeLists.txt thought.
The `#ifdef __NetBSD__` around iconv was actually breaking compilation
on NetBSD when using the system libiconv (there's also a GNU iconv
package)
A C program included from C++ source broke on NetBSD specifically, work
around it.
This doesn't fix compilation on NetBSD, which is currently broken, but
is closer to correct.
967280f140 broke linking against
libLLVM.so because it used the outdated way to link against LLVM from
CMake. This causes a compilation failure on systems that don't have the
LLVM static libraries, such as Arch Linux. On systems that have the
static libraries, it'll use them and increase binary sizes massively.
Switch to the newer llvm_config CMake macro from LLVM.
Previously the Achievements option would only show up if achievements were already enabled, requiring users to manually create a config file in the file system; this now makes it visible no matter what.
Bugfix for hardcore-disabled items being disabled when hardcore was true but achievement integration was false, which should mean hardcore is effectively disabled. Now everything checks the IsHardcoreModeActive method in AchievementManager which processes the setting AND the game state to determine if hardcore mode is actually active.
Spectator Mode is a new mode added by rc_client that allows for achievement and leaderboard functionality, but does not submit this data to the site, partially allowing for offline achievements. It effectively replaces the former settings for disabling achievements, leaderboards, and RP, which are now always active internally as long as the client is active.
The client can take care of itself and handle its own hardcore status when it toggles, so I can tell the settings widget to contact the manager directly to set it.
Also, gradually reorganizing the settings dialog over the next handful of commits.
The client can handle media changes natively so disabling can take place internally. This code uses the same external calls to load data, but will call either BeginLoad or BeginChangeMedia based on whether any media is already loaded.
Due to the client's handling of media changes (it simply disables hardcore if an unknown media is detected) the existing functionality for "disabling" the achievements is no longer necessary and can be deleted.
Two portions of this need updating.
Anything related to points and unlock counts and scoring uses game_summary now instead of the TallyScore method. Unfortunately this comes with the drawback that I cannot easily at this time access the number of points/unlocks from the other hardcore mode, so things like the second progress bar have been deleted.
Rich presence, which no longer needs to be stored, but can be calculated at request. As the AchievementHeader can now update just the Rich Presence, DoFrame can now simply call a header update with .rp=true and the current Rich Presence will be calculated immediately.
As the two items above are the last remaining things to use a number of the components in AchievementManager, this also deletes: Request V1 (V2 is renamed accordingly), ResponseType, PointSpread, TallyScore, UnlockStatus, and the RP generation and ping methods.
UpdateData in AchievementsWindow now only updates the components being requested, massively improving the window's performance. The parameter is UpdatedItems in AchievementManager, which tracks which portions of the system have been updated for every update callback.
Similarly to the Progress widget (though without the separate object for each box, because each Leaderboard unit is just three text fields stacked vertically), AchievementLeaderboardWidget.UpdateData will now accept three options: destroy all and rebuild, update all, or update a set of rows.
As part of this, AchievementManager::GetLeaderboardsInfo has been refactored to GetLeaderboardInfo to return a single leaderboard for the ID passed in.
AchievementProgressWidget maintains in memory a map of AchievementBox pointers so that UpdateData can operate on them individually. UpdateData is overhauled for three options: UpdateData(true) will destroy the entire list and re-create it from scratch as before, to be used if the game or player changes/closes/logs out. UpdateData(false) will loop through the map and call UpdateData on every achievement box, to be used for certain settings changes such as enabling badges or disabling hardcore mode. UpdateData(set<IDs>) will call UpdateData on only the IDs in the set, to be used when achievements are unlocked.
AchievementBox is an extension of QGroupBox that contains the data for a single achievement, initialized with the achievement data and able to reference AchievementManager to update itself.
While state loading is not allowed in the hardcore mode that most players will use, it is allowed in softcore mode; more importantly, if something fails to unlock or unlocks when it shouldn't in either mode the player can create a save that retains the current achievement state.
This is not a 1 to 1 relationship with how the events look primarily because currently achievement
progress messages are in OnScreenDisplay, which currently vanishes messages automatically.
As this covers the last remaining runtime-based event from the old event handler, that handler has been deleted and the new event handler has been renamed to take its place.
Up to four leaderboards are displayed in a window in the bottom right of the screen (vertically above challenge icons, if there are any). As per RetroAchievements standards, the markers only display the current leaderboard values with no further context necessary.
The active leaderboard data (leaderboards currently being attempted, which get displayed on screen) is now tracked. When a leaderboard is started its value is added to a vector (sorted by start frame). There are a separate set of client events specifically to handle leaderboard trackers, that are used to populate and manage this vector. The top portion of this vector (by RetroAchievement standards, the first four items) is exposed to be displayed on screen.
Also deletes the old runtime-based Achievement Triggered event from the old handler, and the methods used by it to publish to the server and reactivate/deactivate achievements in the runtime.
This change was primarily made to refactor the badge fetching to use the client instead of the runtime, but in the process I also refactored the code to cut down on complexity and duplication. Now the FetchBadge method is passed a function that generates the badge name; this is used to ensure that once the badge is loaded that it is still the desired badge to avoid race conditions.
HashGame has become LoadGame, similar structure with the file loaders but using the client instead. LoadGameCallback has been created to handle the results. The old LoadGameSync has been deleted as have
several hash and load methods that it called.
Deletes AchievementManager::Login, renames LoginAsync to Login, and replaces the one synchronous call in the AchievementSettingsWidget with the async call. There is a minor usability regression in that the UI currently does not notify the user when a login has failed; this will be addressed in a later change (possibly in a different PR).
On Windows 11, when playing windowed in a separate window/widget from the main emulator window, we don't want the window to have rounded corners, as it prevents the corner pixels from being visible
Also make the `Decrypt` method private.
As far as I can tell, the only motivation for exposing the `SetBytes`
and `Reset` methods is to allow `CBoot::SetupWiiMemory` to use the same
`SettingsHandler` instance to read settings data and then write it back.
It seems cleaner to just use two separate instances, and require a given
`SettingsHandler` instance to be used for either writing data to a
buffer or reading data from a buffer, but not both.
A natural next step is to split the `SettingsHandler` class into two
classes, one for writing data and one for reading data. I've deferred
that change for a future PR.
This is a JitArm64 version of 219610d8a0.
Due to limitations on how far you can jump with a single AArch64 branch
instruction, going above the former limit of 128 MiB of code (counting
nearcode and farcode combined) requires a bit of restructuring. With the
restructuring in place, the limit now is 256 MiB. See the new large
comment in Jit.h for a description of the new memory layout.
To ensure memory safety, callers of GetPointer have to perform a bounds
check. But how is this bounds check supposed to be performed?
GetPointerForRange contained one implementation of a bounds check, but
it was cumbersome, and it also isn't obvious why it's correct.
To make doing the right thing easier, this commit changes GetPointer to
return a span that tells the caller how many bytes it's allowed to
access.
