Don't copy null terminators from the log's `header.gameid` into
`FifoDataFile`'s `m_game_id`.
Doing so would cause an infinite loop in `Core::GenerateScreenshotName`
as the various concatenations and `fmt::format` calls would then
effectively drop all the timestamps and disambiguating arbitrary numbers
since they followed the null terminator in the gameid, and so the
`File::Exists` calls would always return true.
Fixes https://bugs.dolphin-emu.org/issues/14002.
Previously, SDL would `find_package(libusb)` which would actually overwrite the user preference in the case where both USE_SYSTEM_LIBUSB and USE_SYSTEM_SDL were OFF. This coincidentally also allows SDL to use libusb on Windows.
Our FindLibUSB.cmake was previously entirely unused unless SDL was being built from Externals, we now rely on it again. It will use PkgConfig if applicable or fall back to looking around on the system, and more importantly it will always create an imported target.
cURL tries to find ZSTD anyways due to the lack of setting it in CACHE, and for both ZLIB and ZSTD if we had done find_package previously, cURL would still use ZLIB/ZSTD regardless of the set variable.
This also fixes the CMake build on Windows, since it would fail to find our target defined in Externals and would fall back to trying to redefine it, which produces an error.
Currently, configuring from System>Bundled doesn't work, it instead produces cryptic errors. And configuring from Bundled>System wont produce errors, but wont use the system libraries either. This change produces a clear error in both cases.
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.
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.
Fixes a macOS Metal crash when stopping immediately after boot starts.
m_upload_encoder and m_texture_upload_encoder could be dealloc'd during shutdown before endEncoding could be called, which causes a Metal assertion failure.
Co-authored-by: OatmealDome <julian@oatmealdome.me>
Don't set cached array bases to invalid pointers. If a game tries to set
an invalid base just keep the old one, which might cause game problems
but won't crash the emulator.
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.
Mistakenly thought the change media call would close the current
game if the new media failed to hash. This wasn't the case so
instead I'll close the current game myself. This fixes an issue
where a default ISO would immediately load achievements when
starting up the Wii menu.
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.
Notable changes:
- CMake
- Fixed a bug where SDL couldn't use a vendored libusb or libhidapi (see 29b3fcfb1bc834d0187a8114debdcbbf8381cd61)
- Fixed long startup times on Windows when some non-compliant input devices are present
- Controller support
- Added support for the Razer Raiju V5 Pro
- Improved Switch 2 controller support
- Improved NVIDIA SHIELD controller support
- Fixed various controllers showing up twice on macOS
- Fixed handling GameCube adapters in PC mode on Linux and macOS
Set suggested aspect ratio to 4:3 due to dolphin incorrectly setting it to 16:9 automatically.
Apply suggestion from @jordan-woyak
Co-authored-by: Jordan Woyak <jordan.woyak@gmail.com>
The logic in the code was deliberately avoiding index `2` (**Selected
Font**; the debug font) by using `std::min(index, 1)`. Presumably, the
reason was that there was no debugger in Qt version of Dolphin at the
time.
Test plan:
- Select a debug font via the **Options > Font...** action.
- Show the **Log** tab via the **View > Log** action.
- In the **Log** tab, choose the **Selected Font** item in the combobox.
- Restart Dolphin.
**Without** the patch, the **Monospaced Font** item is wrongly selected
in the combobox.
**With** the patch, the **Selected Font** item is now properly restored
from the saved settings, and the selected debug font is correctly used
in the log messages.
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.
Overrides now also apply in reverse for accepted connections.
IP Override UI now includes a description.
Mario Kart Arcade GP 4x Multicabinet now works on one PC without any tricky IP configurations.
Added AMMBCommandBind, NetDIMMBind, and some helper functions.
Removed redundant settings.
Fixed a bug caused by static usage of Core::System::GetInstance()
Removed unused headers
Removed unneeded code
Optimised code
Added sanity checks
Added SafeCopyFromEmu/SafeCopyToEmu
Set Triforce buttons to be translatable
Removed unneeded code
Removed unused code
Added EINPROGRESS to fix networking on Linux systems
Added function NetworkBufferCheck and NetworkCMDBufferCheck to verify buffer sizes
Added NetworkCMDBufferRead/NetworkCMDBufferWrite/NetworkBufferRead/NetworkBufferWrite
Added multiply buffer size checks
Rewrote GetGameType()
Moved AMMediaboard::Shutdown to DVDInterface::Shutdown()
Changed JVSIOMessage overrun check
Changed SwapBuffers function to be a member function
Added sanity checks for buffer sizes
Added translation prefix for Triforce buttons
Updated text for misconfigurations when trying to boot normal games with Triforce hardware connected
Fixed NAMCAM for Mario Kart GP
This PR provides formatting updates to Sonic Mega Collection.
All regions:
* Formatting fixes.
* Updated to follow my code naming convention for Sega games.
Added control scheme to codes.
Split .ini files based on Rev 0/1.
Added controller mapping instructions.
Added other regions and removed redundant lines.
Added Grass Deterioration cheats.
Changed wording regarding Right Stick variant.
Removed credits from RA Verified list.
Update ApprovedInis.json from PatchAllowlist test.
Updated approved list hash to match AchievementManager.
Attempted to fix the approved hash list again.
Update approved INI list and PatchAllowlist verification data
JIT code related to Branch Watch was emitted if the debugging UI was active: the emitted code would dynamically check whether Branch Watch is active.
However, this causes two problems:
1. It decreases performance by just having the debugging UI enabled
2. It clutters the host assembly in the JIT tab, making it harder to read (unaware readers will wonder what these instructions are for)
With this PR, code related to Branch Watch is emitted only if Branch Watch itself is active, fixing the issues above.
The JIT cache will now be wiped whenever the feature is toggled, causing a slight stutter. However, this isn't the kind of feature that is toggled over and over, so IMO it is an acceptable trade-off.
Call `OnStateChanged` when creating CheatsManager to update the AR and
Gecko code tabs with codes for the currently running game (if any).
Previously, creating CheatsManager while a game was running wouldn't
show any codes until the next time the core state changed (excluding
Starting or Stopping which had no effect).
Fixes https://bugs.dolphin-emu.org/issues/13977.
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.
Changes it to select rows then extracts one item from each row to operate on. The behavior and data across each item in a row was already identical, so using rows doesn't change anything.
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.
Add a minimum value for the automatic size of the performance metrics
graph. The graph can still be manually resized smaller than this limit.
This prevents the graph from automatically resizing itself to be too
small to contain the full graph and legend, which happened when using
native resolution with `Auto-Adjust Window Size` enabled.
Fix a bug causing the performance graph to not resize when the render
window changed size:
* When changing the render window size during emulation the performance
graph wouldn't update its size until the next emulation session.
* When changing the render window size with no emulation active (by
changing the Internal Resolution with Auto-Adjust Window Size enabled)
the performance graph wouldn't update its size until the second
emulation session after the change.
Before explaining why the bug happened, here are some details about Dear
ImGui (henceforth ImGui) for context:
* In order to allow programs to specify initial ImGui window sizes while
also allowing the user to resize them, `SetNextWindowSize` takes a
flag from the `ImGuiCond_` enum specifying under what circumstances
that function should actually have any effect.
* ImGuiCond_FirstUseEver causes ImGui to only apply the command when the
window doesn't have any saved size information for that session or in
the ini file specified by `ImGui::GetIO().IniFilename`. Since we set
that filename to `nullptr`, in practice the resize command is applied
on the first frame of each ImGui/emulation session.
* Qt saves the most recent size of the render window across emulation
(and even Dolphin) sessions, which is then used to set the initial
value of `ImGui::GetIO().DisplaySize` in the next emulation session.
* It takes multiple frames for the size of the render window to update
when changed by setting the internal resolution. This means that
`ImGui::GetIO().DisplaySize` will have a stale value in the
intervening frames, and specifically for the first few frames of
emulation if the resolution was changed beforehand.
When changing the resolution during emulation the call to
`SetNextWindowSize` had no effect because of the
`ImGuiCond_FirstUseEver` flag. `DisplaySize` would be updated several
frames later, and then the next emulation session would update the graph
size on its first frame.
When changing the resolution outside emulation and then starting a game,
the call to SetNextWindowSize on the first frame took effect but used
the stale value of `DisplaySize`. `DisplaySize` would be updated a few
frames later, but the graph wouldn't be resized until the first frame of
the second emulation session.
This commit fixes the issue by using the `ImGuiCond_Always` flag in the
performance graph's call to `SetNextWindowSize` when the render window
size changes.
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.
It turns out that it is possible to create a login alias in RetroAchievements
such that you can log in with a username that doesn't match your display name.
AchievementManager was treating this as a synchronization error, but this is
desired behavior, so this removes the check.
Remove unused vector `controller_names` from `LoadConfig` and
`SaveConfig`. The vector has names added to it but they're never used.
Prior to d03f9032c1 these vectors were
passed to `DynamicInputTextureManager::GenerateTextures`, but that
commit removed those calls.
If using CMake and Ninja or any CMake generator that isn't Visual Studio on Windows, the `-include` will be ignored and the implot fix will not be applied.
Yellow squiggly lines begone!
Done automatically on .cpp files through `run-clang-tidy`, with manual corrections to the mistakes.
If an import is directly used, but is technically unnecessary since it's recursively imported by something else, it is *not* removed.
The tool doesn't touch .h files, so I did some of them by hand while fixing errors due to old recursive imports.
Not everything is removed, but the cleanup should be substantial enough.
Because this done on Linux, code that isn't used on it is mostly untouched.
(Hopefully no open PR is depending on these imports...)
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 the call to `Open` a perf map fails don't set `s_is_enabled` (though
it could already be true if you're also using VTUNE) and don't call
`std::setvbuf` with a null stream.
Also fix a typo in a comment (`if` -> `in`)
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.
When we're emulating single-precision FMA using an FMA instruction,
there's no precision benefit from using a double-precision instruction,
assuming all inputs are single-precision. But when we're emulating
single-precision FMA using separate multiplication and addition
instructions, there is.
This change increases the precision of inaccurate FMA to the same level
as Jit64, which matters since the only reason we have the inaccurate
FMA mode is for sync compatibility with Jit64.
The check only happened if `USE_VTUNE` wasn't defined, and in that case
it was immediately followed by the same check again.
The check used to avoid an unnecessary call to `StringFromFormatV` in
certain circumstances, but that call was removed in
be81fe86e1.
The patches rearrange some branching to insert a call to VIWaitForRetrace in the main game loop.
This allows ImmediateXFB to work properly so it is no longer forced off by the game ini.
Building on macOS with a recent CMake version would result in the
following error:
CMake Error at Source/Core/MacUpdater/CMakeLists.txt:48 (add_custom_command):
The following keywords are not supported when using
add_custom_command(TARGET): DEPENDS
As it turns out, this form of `add_custom_command` does not accept
DEPENDS, but versions of CMake prior to 3.31 silently dropped it.
The TextureInfo constructor creates a vector of MipLevels. This could be
good for performance if MipLevels are accessed very often for each
TextureInfo, but that's not the case. Dolphin creates thousands of
TextureInfos per second that it never accesses the mipmap levels of
because there's a hit in the texture cache, and in the uncommon case of
a texture cache miss, the mipmap levels only get looped through once.
To make the common case of texture cache hits as fast as possible, let's
not create a vector in the TextureInfo constructor. This commit
implements a custom iterator for MipLevels instead.
In my testing on the Death Star level of Rogue Squadron 2, this speeds
up TextureInfo::FromStage by 200%, giving an overall emulation speedup
of a bit over 1%. Results on the Hoth level are even better, with
TextureInfo::FromStage being close to 300% faster and overall emulation
being over 4% faster. (Single core, no GPU texture decoding.)
Profiling Dolphin using Heaptrack, this turns out to be the cause of
more than half of all temporary allocations. Though since it's in a
separate thread, I suppose it wasn't affecting performance very much.
Combined with the previous commit, this brings the TrampolineInfo struct
down to 48 bytes. This matters, because Jit64 has a big
std::unordered_map where it stores many megabytes of TrampolineInfo
entries.
The key saving comes from shrinking the len member from u32 to u16. It
should be safe to even turn it into a u8, but going that far brings no
additional savings due to how the padding works out.
By moving members of the OpArg struct around, we can cut down on how
much padding the struct needs. Now it has a size of 16 bytes, small
enough for function calls to pass it in two registers instead of on the
stack.
Re-added a line of code from a cancelled PR (that I thought was in
main already) that RetroAchievements uses to properly synchronize
memory reads and writes with the emulator frames. This appears to
fix some pretty major freezing and deadlocks in the RA dev tools.
CMake support for c++23 was added in 3.20.
Remove statements explicitly setting the following policies to NEW.
These policies were introduced in or before 3.20, and now that 3.20 is
the minimum version they will automatically have the NEW behavior.
Policy: Introduced in
CMP0079: 3.13
CMP0084: 3.14
CMP0091: 3.15
CMP0092: 3.15
CMP0099: 3.17
CMP0117: 3.20
Disable scanning c++ source files for module imports (introduced as
CMP0155 in 3.28) since we don't use modules and that policy triggers
build errors with Clang if the clang-scan-deps tool isn't installed.
cpp-ipc is explicitely only available on Windows, Linux, QNX, and FreeBSD. Trying to build dolphin on any another BSD such as OpenBSD or Haiku currently leads to failure because of this.
During my quest to rid Dolphin of the memory-unsafe GetPointer function,
I didn't realize that DSPHLE had its own set of memory access functions
that were essentially duplicating the standard ones. This commit gets
rid of them and replaces calls to them with calls to MemoryManager.
Move the constructor and destructor after the definition of the class
`Internal`.
This fixes an error generated by Clang from the destructor of
`std::unique_ptr<Internal>` when setting the standard version to c++23:
`invalid application of 'sizeof' to an incomplete type 'Metal::ObjectCache::Internal'`.
Fix an error generated by Clang from the destructor of
`std::unique_ptr<FileInfo> m_file_info` when setting the standard
version to c++23:
`invalid application of 'sizeof' to an incomplete type 'DiscIO::FileInfo'`
* This fixes some UI elements (3-dot menu background, status bar when scrolling down in settings) not following Material You colors.
* It doesn't cause any issues on Android versions without dynamic colors (tested on Android 9, 11, 16)
Signed-off-by: Leonardo Ledda <leonardoledda@gmail.com>
Checked on hardware that this bias was not added because I had assumed the other way around would be true, forgot to ask about making a PR for this when I initially had done so
If we're on an x64 CPU that doesn't have the MOVBE extension, trying to
SwapAndStore a host register results in that register's value getting
clobbered with the swapped value. Jit64::stX and Jit64::stXx detect this
case, and if necessary, emit a MOV to a register that's fine to clobber.
This logic was broken by the merge of PR 12134. Jit64::stX and
Jit64::stXx were assuming that if RegCache::IsImm returns true for a
guest register, calling RegCache::Use or RegCache::BindOrImm for that
guest register would result in an immediate. However, PR 12134 made it
possible for a guest register to have both a host register and an
immediate in the register cache at the same time. When this happens,
RegCache::IsImm returns true, yet RegCache::Use and RegCache::BindForImm
return an RCOpArg whose Location returns a host register. (To make it
extra confusing, RCOpArg::IsImm calls RegCache::IsImm if the RCOpArg
came from RegCache, so RCOpArg::IsImm returns true!)
To fix this, in cases where Jit64::stX and Jit64::stXx explicitly need
an immediate to avoid having to emit an extra MOV, let's call
RegCache::Imm32 so that we're certain that we're getting an immediate.
This fixes an issue on older x64 CPUs that manifested as e.g. completely
broken graphics in Spyro: Enter the Dragonfly.
The constant propagation PR made it so that a guest register can be
present in the register cache as both a host register and an immediate
at the same time. If such a guest register is requested from the
register cache, the register cache prefers returning it as a host
register. However, RCOpArg::IsImm still returns true in this case. This
is confusing, especially since OpArg::IsImm does not return true if the
RCOpArg is converted into an OpArg.
This commit makes RCOpArg::IsImm check whether RCOpArg::Location returns
an immediate, so that RCOpArg::IsImm returns false when a host register
is being used. Code that wants to know whether an immediate exists in
the register cache rather than whether an immediate is currently being
used should call RegCache::IsImm instead.
Recently came across a strange issue where Dolphin would hard crash in most games with this error:
```sh
/usr/include/c++/15.2.1/optional:1165: constexpr const _Tp* std::optional<_Tp>::operator->() const [with _Tp = InputCommon::ImagePixelData]: Assertion 'this->_M_is_engaged()' failed.
```
The culprit turned out to be accessing `host_key_image` which is an `std::optional` thay may return `std::nullopt`. I'm not sure why this issue started occuring for me since I've had no issue with my Dynamic Input Textures in the past? But this fixes a crash if the image fails to load.
Aside from being unnecessary, on Windows the flag prevents two instances
of Dolphin (one instance from before 2509-371 when the flag was
introduced and the other after) from running the same ROM
simultaneously.
Attempting to do so generated the false error `"[Rom]" is an invalid
GCM/ISO file, or is not a GC/Wii ISO.` followed by `Failed to init core`
and emulation shutdown on the second instance to start the game. Fixing
the incorrect error message is a task I'm deferring to another PR.
The problem didn't happen when both instances were 2509-371 or later,
but I ran into it while bisecting an issue and it'd be nice to avoid
that problem in the future.
We have an optimization where the guest carry flag is kept in the host
carry flag between certain back-to-back pairs of integer instructions.
If the second instruction falls back to the interpreter, then
FallBackToInterpreter should flush the carry flag to m_ppc_state,
otherwise the interpreter reads a stale carry flag and at some later
point Jit64 trips the "Attempt to modify flags while flags locked!"
assertion.
An alternative solution would be to not store the guest carry flag in
the host carry flag to begin with if we know the next instruction is
going to fall back to the interpreter, but knowing that in advance is
non-trivial. Since interpreter fallbacks aren't exactly intended to be
super optimized, I went for the flushing solution instead, which is how
JitArm64 already works. In most cases, the emitted code shouldn't even
differ between these two solutions.
Note that the problematic situation only happens if the first integer
instruction doesn't fall back to the interpreter but the second one
does. This used to be impossible because there's no "JIT disable"
setting that's granular enough to disable some integer instructions but
not all, but with the constant propagation PR, it's possible if constant
propagation is able to entirely evaluate the first instruction but not
the second.
This makes SetUID take more emulated time giving the host more time to actually do the work.
The Wii menu "Data Management" -> "Save Data" -> "Wii" screen is no longer nearly as hard to emulate at full speed.
Constructing the UIDSys from the filesystem is a major bottleneck in the Wii menu "Data Management" -> "Save Data" -> "Wii" screen and this change makes it about twice as fast.
Call `UseNoImm` instead of `Use` on parameter `a` of `MultiplyImmediate`
since `Ra` gets passed to `IMUL` which asserts that parameter is not an
immediate.
This fixes a build error when `-DENABLE_TESTS=ON` and `-DUSE_RETRO_ACHIEVEMENTS=OFF` are both set together, since AchievementManager is also behind an ifdef.
This is a follow-up to 0f1ecf41f9. Our policy is to use three-character
game INIs for settings unless a game has multiple releases and the
setting shouldn't be applied to all of them.
SAHE69.ini was simply renamed to SAH.ini. RL6E69.ini was deleted
entirely, because RL6.ini already exists and contains the same setting.
There was a LINUX check added in b3bdad4, but this should be removed as this change applies to all Qt supported platforms. Simply put, GuiPrivate CMake files were introduced in Qt 6.9 and are now enforced in Qt 6.10 and are not platform-dependent.
Having it be static leads to a race condition if two different threads
call RunOnCPUThread with wait_for_completion set to true. (There's
currently nobody calling RunOnCPUThread from anything other than the
host thread, so this hasn't led to any consequences yet.)
This is an Android port of 7ed61c50a1. It looks like we don't have
descriptions for any of the RetroAchievements settings in the Android
GUI, so I haven't added descriptions for these two new settings either.
LoginDialog sets these to gone when a login starts or fails. Whether we
use gone or invisible needs to be consistent between LoginDialog and the
XML file, otherwise we'll blank space that shows up or disappears when
login starts or fails.
The optimizations for subfcx introduced in #13852 also apply to subfx.
Rather than duplicating the logic, we merge the handlers, like we did
in #10120 for x86.
We only use this class in one in one single function since its introduction with 12aa1071cb in 2021. If we do need it elsewhere we can always bring it back.
The cpp-ipc dependency was included in #13870; it was overlooked that
`install()` commands in the library would lead to ancillary files being
installed along side Dolphin on Linux.
`EXCLUDE_FROM_ALL` is now set in the `add_subdirectory()` call to
prevent cpp-ipc from being part of the installation.
In particular, the following files should no longer be seen in the build
logs or in the final builds:
```
-- Installing: /app/include/libipc
-- Installing: /app/include/libipc/condition.h
-- Installing: /app/include/libipc/buffer.h
-- Installing: /app/include/libipc/export.h
-- Installing: /app/include/libipc/def.h
-- Installing: /app/include/libipc/rw_lock.h
-- Installing: /app/include/libipc/shm.h
-- Installing: /app/include/libipc/mutex.h
-- Installing: /app/include/libipc/pool_alloc.h
-- Installing: /app/include/libipc/ipc.h
-- Installing: /app/include/libipc/semaphore.h
-- Installing: /app/lib/libipc.a
-- Installing: /app/share/cpp-ipc/cpp-ipc-targets.cmake
-- Installing: /app/share/cpp-ipc/cpp-ipc-targets-release.cmake
-- Installing: /app/share/cpp-ipc/cpp-ipc-config.cmake
-- Installing: /app/share/cpp-ipc/cppIpcConfigVersion.cmake
```
In 405baed805, we made the assumption that whether OpenAndroidContent
is able to create a new file depends on the open mode, the document
provider, and the positions of the celestial bodies. However, I'm
fairly sure that it can't create files at all as currently implemented.
First, ContentResolver.openFileDescriptor is documented as throwing
FileNotFoundException if the file doesn't exist. Now, the SAF
documentation is notoriously unreliable on matters like these, and
document providers can do whatever they want anyway, so we can't
actually trust this to mean that FileNotFoundException will always
be thrown if the file doesn't exist. But second, the Dolphin function
ContentHandler.unmangle is also unable to handle files that don't
already exist (unless the passed-in URI isn't mangled to begin with,
but to the best of my knowledge, there's no way to get a non-mangled URI
for a file that doesn't exist (unless you make assumptions about how the
document provider's URI scheme works, which we don't do in Dolphin)).
Summed up, it looks a lot like OpenAndroidContent can't create files,
or at the very least can't do so reliably.
Therefore I'm making DirectIOFile throw an assertion and return false
in situations where it's being asked to create a file under SAF. For
reference, there's no code in Dolphin that actually tries to create a
file under SAF. In all instances where we use SAF to write to files, the
file is created by the system file picker before it returns the URI of
the file to us.
What does this change gain us? First, if someone in the future tries to
use DirectIOFile to create a file under SAF, they'll be immediately
informed that this isn't supported rather than discovering it doesn't
work and chalking it up to SAF being bad for unpredictable reasons.
Second, we get rid of a call to File::Exists, which is a notable
performance improvement for game list scanning due to SAF and Dolphin's
"unmangling" being bad for reasons that unfortunately are entirely
predictable to those of us who have stared into the SAF void.
I've tested that game list scanning and game conversion still works.
These settings were recently changed with 113c86f1b4 to be floats instead of ints.
This commit also changes the Android UI to use the direct convergence value instead of the percentage to match the Qt UI.
When BindToRegister is called, the register cache marks the relevant
guest register as no longer containing an immediate. However, subfcx was
calling GetImm after BindToRegister. This led to a lot of panic alerts
after 2995aa5be4 added an assert to GetImm to check that the passed-in
register is an immediate.
Both before and after 2995aa5be4, the actual value of the immediate
wasn't overwritten by BindForRegister, only the fact that the register
is an immediate. Because of this, the emitted code happened to work
correctly.
If the build is an Android build, identify it as such in the AchievementManager user agent so that android builds can be tracked separately for debug purposes.
We were previously excluding this folder from Android builds because it
didn't contain any files that were used on Android. However, we now have
an OSD font file that we do want to use on Android, and there's also a
few PNG files that will be needed by the RetroAchievements integration.
In terms of file size, this is what gets added:
OSD font: 48.1 KiB
RetroAchievements graphics: 3.5 KiB
Unused graphics: 116.8 KiB
We're still excluding Sys/Themes/, which is 1.1 MiB and entirely unused.
Like Jit64, JitArm64 now keeps track of the location of a guest register
using three booleans: Whether it is in ppcState, whether it is in a host
register, and whether it is a known immediate. The RegType enum remains
only for the purpose of keeping track of what format FPRs are stored in
in host registers.
Like the previous commit did for Jit64, JitArm64 can now handle the
combination of a value simultaneously being in a host register and being
a known immediate.
Unlike with Jit64, I've put the codegen-affecting changes in this commit
and the move away from the RegType enum in a follow-up commit. This is
in part because the design of JitArm64 made it easy to implement the
codegen-affecting changes without combining it with a big bang
refactorization, and in part because we need to keep RegType around for
keeping track of different float formats in Arm64FPRCache, complicating
the refactorization a bit.
They're now stored in ConstantPropagation instead.
I've also removed the LocationType enum. The location of each guest
register is now tracked using three booleans: Whether it is in ppcState,
whether it is in a host register, and whether it is a known immediate.
The first two of these booleans are stored in the register cache, and
the last one is stored in ConstantPropagation. This new model allows us
to handle the combination of a value simultaneously being in a host
register and being a known immediate. It also keeps track of which
registers are dirty, which was previously kept track of in X64CachedReg.
The old model maps to the new model as follows:
default host_reg immediate
Default true false false
Discarded false false false
Bound (!dirty) true false
Immediate false false true
SpeculativeImmediate true false true
[previously unrepresentable] (!dirty) true true
This commit makes the JIT set/clear the individual registers of
ConstantPropagation immediately instead of at the end of the
instruction. This is needed to prevent Jit64::ComputeRC, which reads
from a register written to earlier during the same instruction, from
reading back stale register values from ConstantPropagation in the next
commit.
To find out whether a host register needs to be unlocked, FlushRegisters
checks if the guest register is known to be a zero immediate. This works
right now, but it will stop working correctly once we gain the ability
to have a guest register be a known immediate and be in a host register
at the same time, because a register that's known to be a zero immediate
may have had a host register allocated prior to the call to
FlushRegisters. Instead, we should check whether the register is
RegType::Register after we're done calling BindForRead.
Restructuring things in this way brings two immediate benefits:
* Code is deduplicated between Jit64 and JitArm64.
* Materializing an immediate value in a register no longer results in us
forgetting what the immediate value was.
As a more long-term benefit, this lets us also run constant propagation
as part of PPCAnalyst, which could let us do cool stuff in the future
like statically determining whether a conditional branch will be taken.
But I have nothing concrete planned for that right now.
Sliders can trigger change listeners very rapidly, so let's add some
rate limiting so dragging a slider doesn't cause the whole UI to lag.
(Now the input overlay looks laggy when dragging a slider, though.)
In the dialog where you can choose what controller the input overlay
should be controlling, there's an OK button. If you change controller
but don't press OK, your selection will be saved, but the input overlay
won't refresh to show the new controller unless you perform some other
action that would cause it to refresh. This is not good UX.
This commit changes the behavior not only of this dialog but also other
dialogs spawned by EmulationActivity so that everything is properly
updated when dismissing a dialog, as if you had pressed OK.
warning: definition of implicit copy constructor for 'BitField<2, 2, ColorChannel>' is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy]
Redundant access specifier has the same accessibility as the previous access specifier.
this line:
- --filesystem=xdg-run/app/com.discordapp.Discord:create
specifically targets the flatpak version of discord, so anyone using the native package wouldnt get rich presence
Fusion is one of the built-in styles that Qt ships with, and that is
generally supported in all platforms and handles custom color palettes
properly.
The color palettes have been borrowed from the Dolphin Memory Engine
buddy application.
The new styles are:
- **Fusion Light**
- **Fusion Dark Gray**
- **Fusion Dark**
A demo of each style on Windows:
| System | Light | Dark | Fusion Light | Fusion Dark Gray | Fusion Dark |
| ------ | ----- | ---- | ------------ | ---------------- | ----------- |
| <img width="1920" height="1080" alt="Dolphin Emulator System style" src="https://github.com/user-attachments/assets/7f55a19d-d9a1-43d1-a435-1e1d5b29abe2" /> | <img width="1920" height="1080" alt="Dolphin Emulator Light style" src="https://github.com/user-attachments/assets/4c70f2f9-16b8-4777-b72b-55b2dffcd1e4" /> | <img width="1920" height="1080" alt="Dolphin Emulator Dark style" src="https://github.com/user-attachments/assets/5e669477-d2a5-4d19-b2c5-a2ed9bb1e6fe" /> | <img width="1920" height="1080" alt="Dolphin Emulator Light Fusion style" src="https://github.com/user-attachments/assets/b1f95c47-0691-4809-bd74-99e913c17684" /> | <img width="1920" height="1080" alt="Dolphin Emulator Dark Gray Fusion style" src="https://github.com/user-attachments/assets/c9d30aa3-f941-4fc5-806f-d3fbd2cae0cc" /> | <img width="1920" height="1080" alt="Dolphin Emulator Dark Fusion style" src="https://github.com/user-attachments/assets/123d2125-e126-4e8c-aa42-793ded8ffacc" /> |
> [!NOTE]
> Notice that the **Light** and **Dark** styles remain available only on
> Windows due to limitations on how styles in the various platforms
> handle (or mishandle) custom color palettes.
> [!IMPORTANT]
> Due to [`KDE-511547`](https://bugs.kde.org/show_bug.cgi?id=511547),
> after having used Breeze (default style in Plasma systems), top tool
> bars in tools areas will lose their correct background color; a
> restart will be required in order to get the updated color in the main
> window.
>
> UPDATE: The issue has been fixed upstream and should be available in
> KDE Plama 6.5.3 and newer.
extractNativeLibs is deprecated. Native lib packaging is already controlled by
packaging.jniLibs.useLegacyPackaging (which we already have), so the manifest override is unnecessary.
The core no longer cares which thread is the host thread.
Cleaning up Android's HostThreadLock is left for another PR, in part
because the HostThreadLock in NativeConfig.cpp still serves a purpose,
and in part to make any issues easier to bisect.
By letting threads other than the host thread use things like
CPUThreadGuard, we can do a significant cleanup in AchievementsManager
in a later commit of this pull request.
Note: Some functions still can't be called from the CPU thread (or
threads the CPU thread might block on, like the GPU thread), but can
be called from any other thread.
The bug in CVE-2025-0665 causes crashes on Android 11 and above, as the default fdsan behavior was changed to abort when a violation is found.
While curl 8.17.0 is the latest release, we can't upgrade to it right now due to mbedtls 2.28.0 (which we are currently using) being incompatible with it.
Co-Authored-By: OatmealDome <OatmealDome@users.noreply.github.com>
Tapping outside the System Update dialog would previously close it and leave the update in a partially canceled, inconsistent state. This change disables outside-touch dismissal to avoid accidental interruptions and ensure the process completes cleanly.
If bind was called more than once for a SwitchSettingViewHolder, the
line `binding.settingSwitch.isChecked = setting.isChecked` would
accidentally trigger the listener registered during the previous bind
call.
Trigraphs support is generally disabled by default, but some compilers
(e.g. GCC) may still warn when one hypothetical trigraph is encountered.
For example, one of these warnings was introduced as part of #14067:
```
.../Source/Core/DolphinQt/MainWindow.cpp:1433:77: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
1433 | this, tr("Select a File"), dialog_path, tr("All Save States (*.sav *.s??);; All Files (*)"));
|
.../Source/Core/DolphinQt/MainWindow.cpp:1445:77: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
1445 | this, tr("Select a File"), dialog_path, tr("All Save States (*.sav *.s??);; All Files (*)"));
|
```
The warning is generally not interesting and has been disabled now.
We can now route Android analytics through Common::HttpAnalyticsBackend, drop the Volley sender, and keep the JNI layer limited to only transfer metadata since https://bugs.dolphin-emu.org/issues/11772 has been fixed.
Push and wait on WorkQueueThread items using PushBlocking. Previously we
created a Common::Event sync_event on the caller's stack, called Wait on
it, then had the WorkQueueThread call Set on the sync_event once the
thread was done.
In addition to being simpler the new way avoids a use-after-free that
could happen in convoluted and unlikely yet possible thread scheduling
sequences.
One such case can be triggered as follows:
* Set your audio backend to Cubeb
* In CubebStream::SetVolume set a breakpoint at the call to Wait and at
the call to cubeb_stream_set_volume.
* Start a game.
* Continue until the Cubeb Worker thread hits the
cubeb_stream_set_volume breakpoint and Emuthread hits the Wait
breakpoint, freezing each thread when it hits its breakpoint.
* Unfreeze Cubeb Worker.
* In Event::Set set a breakpoint at the end of the scope containing the
lock_guard such that the guard has been constructed but not destructed
when the breakpoint is hit.
* Continue until that breakpoint is hit by Cubeb Worker. If other
threads hit it first keep going.
* Freeze Cubeb Worker.
* For convenience remove the breakpoint in Event::Set so other threads
don't trigger it.
* In CubebStream::SetRunning set a breakpoint at the call to Wait.
* Unfreeze Emuthread and continue until the breakpoint is hit.
* In Cubeb Worker go to Event::Set and examine the values of m_mutex's
member variables. In Visual Studio Debug these are locking_thread_id
== 0xcccccc01 and ownership_levels == 0xcccccccc. This is the result
of Visual Studio overwriting the memory used on the stack by
sync_event in CubebStream::SetVolume with cc bytes to represent
uninitialized memory on the stack (since that function already
returned), and then allocating enough memory on the stack when calling
AudioCommon::SetSoundStreamRunning and then CubebStream::SetRunning
that it overwrote one byte of the memory formerly occupied by
locking_thread_id.
* If you unfreeze Cubeb Worker at this point it will trigger the lock
guard's destructor which will then try to unlock m_mutex. Since
m_mutex is no longer in scope this is a use-after-free, and in VS
debug triggers a debug assert due to locking_thread_id not matching
the current thread id.
Displays a different message at game launch if RetroAchievements fails specifically due to an invalid or expired API token, instructing the player to log back in with the game closed.
When the interpreter calls MSRUpdated, we should update the membase
variable. Not because the interpreter itself needs it, but because the
JIT needs it if it's falling back to the interpreter for an instruction
that sets the MSR.
Additionally, the JIT's FallBackToInterpreter needs to read back the new
membase value afterwards.
This fixes games crashing on JitArm64 if mtmsr is set to fall back to
interpreter. I was unable to reproduce the issue on Jit64, presumably
due to a fortunate series of coincidences (instructions that set MSR are
always followed by an exception exit, and
PowerPCManager::CheckExternalExceptions was always calling
JitInterface::UpdateMembase, and Jit64::WriteExceptionExit was always
calling Jit64::EmitUpdateMembase.)
In a few places in Dolphin, we're using BottomSheetDialogFragments.
These unhelpfully tend to start out in a "collapsed" state when in
landscape mode (presumably depending on factors like screen size). The
user then has to manually expand them before they can meaningfully
interact with them.
We've been automatically setting BottomSheetDialogFragments to the
expanded state if the device Dolphin is running on doesn't support
touch, since with d-pad navigation it's impossible to expand these
sheets. But I think we should set them to expanded on devices that
support touch too. I haven't encountered a single case where you can do
anything useful with any of Dolphin's BottomSheetDialogFragments while
they're collapsed, so the user always has to expand sheets manually if
they start out collapsed. And just because a device supports touch
doesn't necessarily mean you're interacting with it through the touch
screen right now - you could be using a gamepad, for instance.
Remove "env, " from "return env, GetControlPointer..." since the left
side of a comma operator has no effect.
This was presumably a copy/paste error from the function above it.
This is a hassle-free BBA option intended for local play with multiple
Dolphin instances running *in the same system*. After selecting
**Broadband Adapter (IPC)** in the **SP1** slot in the GameCube section
in the settings, games that support LAN play will be able to discover
each other, without requiring third-party software or relatively complex
TAP setups.
The implementation is based on cpp-ipc, a high-performance inter-process
communication library that uses shared memory as transport layer.
Supported platforms are:
- [x] Linux
- [x] Windows
- [ ] macOS (cpp-ipc does not support this platform)
- [ ] FreeBSD (cpp-ipc does not support this platform)
- [ ] Android (cpp-ipc needs some adjustments; while it could work,
launching two Dolphin instances within the same Android system may be
both challenging and impractical)
PauseAndLock is now only called with do_lock=true, and unpause_on_unlock
only ever was used when do_lock is false (which is now handled in
RestoreStateAndUnlock instead), so both parameters are unnecessary.
Replace calls of PauseAndLock(do_lock=false) with new function
RestoreStateAndUnlock for clarity.
Callers of PauseAndLock ignored the return value when do_lock is
false, so RestoreStateAndUnlock doesn't need to return anything.
RestoreStateAndUnlock was only called with control_adjacent=true. Remove
the parameter and unconditionally call the function that was gated
behind it being true.
CPUManager::PauseAndLock is now only called with do_lock=true, and
unpause_on_unlock only ever was used when do_lock is false (which is now
handled in RestoreStateAndUnlock instead), so both parameters are
unnecessary.
Replace call of CPUManager::PauseAndLock(do_lock=false) with new
function RestoreStateAndUnlock for clarity.
Callers of Core::PauseAndLock ignore the return value when do_lock is
false, so in that case was_unpaused in Core::PauseAndLock doesn't need
to be set and so RestoreStateAndUnlock doesn't need to return anything.
Make s_have_fake_cpu_thread a class member instead. In addition to
getting rid of a bit of static state, this simplifies refactoring in an
upcoming commit.
OProfile is not used at all these days, most major distributions do not ship it anymore (Debian, Fedora, and Alpine to name the few I've checked) and following a discussion on Discord, nobody is apparently using it, most devs not even being aware of it. This removes an optional dependency from Dolphin.
Allow loading a custom font by naming it OSD_Font.ttf and placing the file in the User/Load folder, to load that font instead. Useful for future testing.
Don't log a warning in GetPropertyHelper when the property isn't
present. The function returns an optional, so any callers that want to
log a warning when nullopt is returned can do so themselves.
This prevents plugged-in devices (an Xbox One controller in my case)
from spamming the message "W[COMMON]: CM_Get_DevNode_Property returned:
37" twice per second (that value being CR_NO_SUCH_VALUE).
Added some new visibility toggles so players can choose what to show (or hide) during their RetroAchievements runs:
Toggle for the Speedrun Leaderboards timer
Toggle for Achievement Challenge badges
Check if the return value of std::filesystem::remove_all is -1 rather
than 0; the former is the specified return value if there's an error
while 0 just means the directory already didn't exist (which is the end
result we want).
Previously error messages such as the following were possible:
E[COMMON]: DeleteDirRecursively: [path]/User/RedirectSession/ failed The
operation completed successfully.
Also adds a period in the error string to make it look nicer.
Rename m_session to m_last_value_session to better reflect its meaning
and distinguish it from m_current_value_session which will be introduced
in another commit.
macOS does not support `SO_PRIORITY` on sockets, but it does apparently
support configuring sockets with a priority flag via a parameter called
`SO_NET_SERVICE_TYPE`. It doesn't appear to be especially well
documented, but it seems to exist as far back as 10.11 (El Capitan).
This patch sets QoSSession to treat connections as
"responsive multimedia audio/video", which some docs appear to describe
as "low delay tolerant, low-medium, loss tolerant, elastic flow,
variable packet interval, rate and size".
Preserve the configured logging verbosity unless the user actually
changes it, rather than capping it to LINFO on release builds.
Rename LogManager::m_level to m_effective_level and distinguish between
the config and effective level in various function/variable names.
Make m_effective_level atomic to prevent data races when setting the
effective log level from the config changed callback.
USBDevicePicker: Modify USBDeviceAddToWhitelistDialog to be more generic, and use it for a new "More Options..." selection in Bluetooth Passthrough adapters
The `QtUtils::AdjustSizeWithinScreen()` function now centers the
widget on their parent window after the widget's size is adjusted. This
is required in some desktop environments (generally on Linux systems) to
ensure that the just-resized widget remains aligned with its parent
window.
The creation of the **Cheats Manager** dialog is now deferred to first
show, as creating it within the main window's constructor prevents the
dialog from knowing the real position of its parent window, which is
only properly calculated on first show.
For the same reasons, the analytics prompt is now shown only when the
application is ready (i.e. when the main window has been shown).
| Before | After |
| ------ | ----- |
| <img width="1920" height="1080" alt="[Dolphin Emulator] Misplaced analytics prompt" title="[Dolphin Emulator] Misplaced analytics prompt" src="https://github.com/user-attachments/assets/c3e43b3b-cf79-4398-b531-7de6068c583e" /> | <img width="1920" height="1080" alt="[Dolphin Emulator] Centered analytics prompt" title="[Dolphin Emulator] Centered analytics prompt" src="https://github.com/user-attachments/assets/a10d06d9-7438-4032-b96c-dfcb48826349" /> |
| <img width="1920" height="1080" alt="[Dolphin Emulator] Misplaced Settings dialog" title="[Dolphin Emulator] Misplaced Settings dialog" src="https://github.com/user-attachments/assets/f35b10ee-4f07-48d4-86f9-2537ad5ca7ca" /> | <img width="1920" height="1080" alt="[Dolphin Emulator] Centered Settings dialog" title="[Dolphin Emulator] Centered Settings dialog" src="https://github.com/user-attachments/assets/33e37237-77a4-44f6-a0e2-b709f65b672b" /> |
| <img width="1920" height="1080" alt="[Dolphin Emulator] Misplaced Cheats Manager dialog" title="[Dolphin Emulator] Misplaced Cheats Manager dialog" src="https://github.com/user-attachments/assets/1fbd3836-5639-4d5a-b57e-e2e21f21c9db" /> | <img width="1920" height="1080" alt="[Dolphin Emulator] Centered Cheats Manager dialog" title="[Dolphin Emulator] Centered Cheats Manager dialog" src="https://github.com/user-attachments/assets/3f2b1b50-de16-49b7-bac4-c444c6cab0bc" /> |
Without cache emulation, these instructions are functionally identical.
In the interpreter, their only difference is related to HID registers checks, which the JIT already doesn't do for `dcbz`.
A loop with `dcbz_l` is used in the SDK function `LCEnable`, which is called frequently in some games.
When opening a file dialog to set the location of a custom path, use the
corresponding user path as the starting location instead of the current
custom path.
When no custom path was set the dialog would be opened with a blank path
which causes Windows (not sure about other platforms) to open the dialog
at the same location where the last dialog was closed, or at the current
working directory if no previous dialog had been opened.
If a nonempty custom path has been set then it has also set the
corresponding user path, so the behavior in that case is unchanged.
`MaxAnisotropy = 0` is no longer the safest setting because it forces 1x
even if the game asks for more.
`ForceFiltering` was replaced by `ForceTextureFiltering` in
afe9d5b098. The one remaining occurrence
was merged later.
`ForceTextureFiltering` is an int option and shouldn't be set to False.
Just Dance 3, Just Dance: Best of, and Just Dance: Greatest Hits look
fine on AMD GPUs without manual texture sampling. On Nvidia GPUs they
have a single stripe that I think doesn't warrant forcing manual texture
sampling for everyone.
The NES games I tried worked fine with anisotropic filtering, it just
doesn't do anything.
Various games don't actually have any issue with anisotropic filtering
as long as it's not forced. The only game I could find that actually
requires the default aniso setting is Spider-Man: Shattered Dimensions.
Boogie SuperStar works fine with any texture filtering setting.
Adds `DocumentsContract.Root.FLAG_SUPPORTS_IS_CHILD` to the list of the flags in order to show up for third-party apps for easier file syncing with local/cloud file server providers
Adds `DocumentsContract.Root.FLAG_LOCAL_ONLY` to the list of the flags in order to show up for third-party apps for easier file syncing with local/cloud file server providers
The callback mechanism AchievementManager had until now only supported
one caller registering a callback, and it didn't have any
synchronization. This isn't a problem for DolphinQt, but the PR to add
Android support for RetroAchievements exposes these problems. Let's
replace it with HookableEvent, which can handle all of this.
The instruction implementations that were shifting the size by 4 would
emit an incorrect instruction when given a size of 64. The correct
implementation is to count the number of leading or trailing zeroes in
the size parameter, which is what IntLog2 does.
No callers are affected by this, as they all use sizes other than 64.
Actually, some of these instructions are even invalid with a size of 64,
but I'm changing them anyway for consistency with the others.
We should attempt to use not only mirrored versions of the immediate as
an ORR base, but also the immediate itself. This lets us emit certain
64-bit constants using fewer instructions.
IsolateWasOverwritten and IsolateNotOverwritten share the same basic
logic and have almost exactly the same code, with the only difference
being the comparison function used to keep or discard branches. To avoid
unnecessary code duplication and ensure that the functions stay in sync
after any future changes, create a helper function that takes the
comparison function as a parameter and have IsolateWasOverwritten and
IsolateNotOverwritten call that helper.
Show "(off)" instead of "" when the default post-processing effect is
selected. This also indirectly fixes issues with keyboard navigation of
the post-processing effect combobox when the default is selected,
resolving https://bugs.dolphin-emu.org/issues/13863.
m_post_processing_effect was previously using the ConfigStringChoice
constructor that assumes the text and data of each option are identical.
This is true for all the other effects, but since "(off)" has the config
value of "" this assumption was failing for it, causing the combobox to
be blank.
Equivalent to a negation, no need to materialize the zero.
Before:
0x52800015 mov w21, #0x0 ; =0
0x6b1802b6 subs w22, w21, w24
After:
0x6b1803f6 negs w22, w24
This case can be handled as a move. It also generates a constant carry
flag.
Before:
0x52800013 mov w19, #0x0 ; =0
0x6b1302b3 subs w19, w21, w19
After:
0x2a1503f3 mov w19, w21
Keep the BalloonTip open when the BalloonTip's arrow prevents the cursor
from being inside the spawning ToolTipWidget, which triggers the
ToolTipWidget's leaveEvent and would previously close the BalloonTip.
When that happens track the cursor until it either leaves the
ToolTipWidget's bounding box or leaves the BalloonTip and goes back to
the ToolTipWidget, and respectively close the BalloonTip or leave it
open.
This lets us get rid of the Reset call in ProcessInputPayload, which was
causing us some threading headaches (see 74ed5e5532). Instead we handle
disconnection in the same way as the libusb implementation does.
We can register a BroadcastReceiver to have Android tell us when a GC
adapter gets connected instead of having a loop where we continuously
call SleepCurrentThread(1000) and poll the current status. When waiting
for a GC adapter to connect, this both reduces power usage and improves
responsiveness.
Note that I made openAdapter get the UsbDevice that's been stored by the
hotplug code instead of having openAdapter find the UsbDevice on its own
like before. This is only because I want to ensure that the UsbDevice
being tracked for disconnection is the same as the UsbDevice actually
being used, in case the user has multiple adapters connected.
Aims to fix https://bugs.dolphin-emu.org/issues/13686.
I'm using a less efficient approach for Jit64 than for JitArm64. In
JitArm64, I'm flushing in the slow access code, but in Jit64, I'm
flushing before the split between the slow access code and the fast
access code, because Jit64 doesn't keep register mappings around for
when it's time to emit the slow access code. But the flushing code is
only emitted when there are memory breakpoints with conditions, so I'd
say that this is a performance loss we can live with.
The next commit will add another piece of code that depends on this
assumption that we've been making. Good opportunity to document it.
In practice, all callers of EmitBackpatchRoutine are locking X30.
Delete old Updater.log file from GetExeDirectory().
The log was moved to GetUserPath(D_LOGS_IDX) in 5.0-14529, but users
looking to make a bug report might find the old one instead so let's
delete it to prevent any confusion.
If you downloaded Android Studio, install it with the default options and open the project located in `dolphin/Source/Android`
Install Android Studio with the default options if you do not already have it.
## Setting Up Android Studio
1.Wait for background tasks to complete on the bottom of the window.
2.Launch the Android SDK Manager by clicking on its icon in Android Studio's main toolbar:
![Android Studio Package Icon][package-icon]
3. Install or update the SDK Platform. Choose the API level as defined in the app module's [build.gradle](Source/Android/app/build.gradle#L7) file.
4. Install a CMake version as defined in the app module's [build.gradle](Source/Android/app/build.gradle#L99) file. The option won't appear until you select `Show Package Details`.
5. Select `Build Variants` on the left side of the window to choose the build variant and ABI you would like to compile for the `:app` module.
6. Select the green hammer icon in the main toolbar to build and create the apk in `Source/Android/app/build/outputs/apk`
1.Open the `Source/Android` project in Android Studio, let any background tasks finish, and Android Studio will automatically download the required SDK components and tooling.
2.Use the hammer icon or **Build > Assemble 'app' Run Configuration** to compile the `:app` module, then choose **Build > Generate App Bundles or APKs > Generate APKs** to produce the APK in `Source/Android/app/build/outputs/apk`.
## Import the Dolphin code style
The project maintains a custom IntelliJ/Android Studio style file to keep Java and Kotlin formatting consistent.
* Go to **File > Settings > Editor > Code Style** (or **Android Studio > Settings > Editor > Code Style** on macOS).
* Click the gear icon and choose **Import Scheme**.
* Select `Source/Android/code-style-java.xml` from the repository.
* Ensure that Dolphin-Java is selected.
## Format code before opening a pull request
Before committing or submitting a pull request, reformat any Java or Kotlin files you modified:
* Use **Code > Reformat Code** (or press `Ctrl+Alt+L`/`⌥⌘L` on macOS) with the Dolphin code style selected.
* Re-run formatting after edits to keep spacing, imports, and wrapping consistent with the rest of the project.
## Compiling from the Command-Line
For command-line users, any task may be executed with `cd Source/Android` followed by `gradlew <task-name>`. In particular, `gradlew assemble` builds debug and release versions of the application (which are placed in `Source/Android/app/build/outputs/apk`).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
OatmealDome
JosJuice
Dentomologist
Craig Carnell
Joshua Vandaële
JMC47
Simonx22
TellowKrinkle
Jordan Woyak
Lilly Jade Katrin
Admiral H. Curtiss
FrankyBuster
cristian64
Andrew Strauss
TryTwo
Sepalani
crediar
Windsurf7
spaceage64
Martino Fontana
dreamsyntax
Martino Fontana
ElTioRata
oltolm
Gabriela Orzechowska
Sam Belliveau
OatmealDome
Sintendo
iwubcode
Ballai Péter
Tillmann Karras
Leonardo Ledda
Mrlinkwii
matellush
Filippo Tarpini
Anarky
Nuh Uh
Mateus B. Cassiano
Biendeo
Jason E. Hale
Naim2000
da pwo
AndrewGDX
VampireFlower
iTrooz
cobalt2727
fizzlepicklepop
Xphalnos
Matthieu Speder
Farmerbilly27
Ryan McGrath
Matheus Willder
JordanTheToaster
Marocco2
Dr. Dystopia
y21