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.
The wrong filename was used so the settings weren't being applied.
The graphical issues reported were from enhancements that create graphical issues.
EFBToTextureEnable solves some graphical issues but those issues appear for only a few frames, the bulk of the game does not benefit while the setting while it is very sore on performance.
Arbitrary Mipmap Detection doesn't work when GPU Texture Decoding is
enabled, so disable GPU Texture Decoding for games where the .ini
enables Arbitrary Mipmap Detection.
Co-authored-by: jeremyie <73066289+McAchi@users.noreply.github.com>
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.
Tilka