Android Studio 2022.2 "Chipmunk" changes the code formatting rules a
little. Let's apply the new formatting in this PR so that the lint bot
doesn't take it out on innocent PRs.
Without this, debug builds of Dolphin fail to launch. The OS tries
to locate org.dolphinemu.dolphinemu.debug.DolphinApplication
but fails to find it because its actual name is
org.dolphinemu.dolphinemu.DolphinApplication.
Partially reverts 6b74907f9d.
This refactorization is done just to match the order that I made
WriteToHardware use in 543ed8a. For WriteToHardware, it's important that
things like MMIO and gather pipe are handled before we reach a special
piece of code that only should get triggered for writes that hit memory
directly, but for ReadFromHardware we don't have any code like that.
This fixes a problem where Dolphin could crash if a non-translated
read crossed the end of a physical memory region.
The same change was applied to WriteToHardware in ecbce0a.
The currentValue variable doesn't use InputOverlay.OVERLAY_
constants, it uses NativeLibrary.ButtonType constants.
Sigh, why do enums have to be so bad on Android that Google
recommends against using them :(
Anyway, simply not doing anything is a reasonable option here.
What happens then is that if the currently selected button is
invalid for the current controller, none of the available options
in the dialog will be pre-selected.
This was requested by a forum user, and I thought why not.
It's a simple change to make since DiscIO already supports it,
and I assume command-line users know roughly what they're doing.
Turns out there's some Freeloader disc for the GC that triggers this
despite being a good dump. This warning is mostly intended to catch
Wii games that have been truncated at the 4.00 GiB or 4.38 GiB mark
anyway, and if someone does have a Datel dump that has been truncated,
they'll still get the "unusual size" warning.
According to the documentation, getActionIndex should only be
used with ACTION_POINTER_DOWN and ACTION_POINTER_UP. We've had a
few crashes reported in the Play Console regarding invalid pointer
indices for getY, and I'm hoping this will help with that.
Previously we were using this workaround when using framebuffer fetch
to emulate dual source blending, but it seems like we also need to use
it when using framebuffer fetch to emulate logic ops, otherwise some
Adreno devices get a crash when compiling OpenGL ES ubershaders.
Using the workaround in specialized shaders doesn't seem to be
necessary, but I've made the same change there for consistency.
This gets us closer to fixing https://bugs.dolphin-emu.org/issues/12791
but doesn't actually fix it.
On devices which have hardware support for dual source blending
but not logic ops, this lets us skip performing the framebuffer
fetch in situations where the game isn't actually using logic ops.
This saves the GUI from having to manually call SDIO_EventNotify.
With that out of the way, we can let users change the
"Insert SD Card" setting on Android while a game is running.
In a code block where a guest register is accessed at least twice and the
last access is a write and the register is not discardable immediately
after the second-to-last instruction (perhaps there is an instruction
in between that can cause an exception), currently Dolphin's JITs will
flush the register after the second-to-last instruction.
It would be better if we replaced the flush after the second-to-last
instruction with a flush that only happens if the exception path is
taken. This change accomplishes that by marking guest registers as
"in use" not just when they are used as inputs but also when they are
used as outputs, preventing the loop in DoJit from flushing the
register until after the last access.
This makes codegen faster (by perhaps 10-20% in the case of Jit64,
I didn't measure too closely), which helps speed up NBA Live 2005
a little. But the game still has serious performance issues.
Fixes https://bugs.dolphin-emu.org/issues/12827.
A description of what was going wrong:
JitArm64::Init first calls CodeBlock::AllocCodeSpace, after which
CodeBlock and Arm64Emitter consider us to have 96 MB of code space
available. JitArm64::Init then calls AddChildCodeSpace, which is
supposed to take 64 MiB of that space and give it to m_far_code.
CodeBlock's view of how much space there is gets updated from 96 MiB
to 32 MiB, but due to the missing call, Arm64Emitter keeps thinking
that it has 96 MiB of space available.
The last thing JitArm64::Init does is to call ResetFreeMemoryRanges.
This function asks Arm64Emitter how much code space is available and
stores a range of that size in m_free_ranges_near, meaning that
m_free_ranges_near ends up being backed by both nearcode and farcode!
This is a ticking time bomb; as soon as we grab memory from
m_free_ranges_near which is backed by farcode, we're in trouble.
The crash I ran into in my testing was caused by fastmem code being
allocated in farcode (our backpatch handler only handles accesses made
from nearcode), but you may as well get errors caused by code intended
for nearcode overwriting code intended for farcode or vice versa.
So why did NBA Live 2005 crash when most games had no problems,
and why was the bug bisected to the commit that increased the size
of far code from 16 MiB to 64 MiB? Well, as long as we're only
using the first 32 MiB of the big 96 MiB range, everything works.
What happens with NBA Live 2005 (I have not investigated exactly
through what mechanism this happens) is that at some point the range
in m_free_ranges_near gets split into two ranges, one which is
backed by nearcode and one which is backed by farcode. Dolphin
prefers to select the biggest range available (we don't want to
pick a tiny 1 KiB range that may not be able to fit the whole block
we're about to emit, after all), and after increasing the size of
farcode to 64 MiB, farcode is bigger than nearcode.
Apparently there are phones where accessing Dolphin's app-specific
directory isn't just annoyingly hard but actually impossible.
To give users of those phones at least some kind of way to manage
their data (even if it's a lot less convenient than if we were
allowed to let the user open the app-specific directory in a
file manager), I'm adding a way to export the directory to a
zip file and then import it back.
These files cannot compile correctly as C, so there's no reason to have
ifdefs for C compatibility.
We switched to not checking the __cplusplus macro in our JNI code some
time ago, but it seems like I forgot to remove it from these two files.
We don't have a timeout like this on other platforms, and it doesn't
accomplish anything useful as far as I can tell. If you trigger it,
all that happens is that you don't get a working game and also can't
press Exit Emulation without Dolphin hanging (stuck in Core::Shutdown).
Turning off primitive restart increases performance a lot on
Adreno for some reason. We're talking numbers like 50%-100% faster
in situations which are bottlenecked by rendering.
Currently, disabling mGBA when building gets rid of the ability to
change the GBA saves directory in DolphinQt, but it doesn't actually
get rid of Dolphin loading and storing the setting and creating the
folder. If the setting is set to a path you don't want to use
(perhaps you are trying to turn Dolphin portable), this is annoying.
To avoid accidentally making mistakes like this in the future,
I'm gating the existence of the setting behind an ifdef.
If the purpose of calling SetFullscreen using RunAsCPUThread is
to make sure that the GPU thread is paused, the fix in ef77872
is faulty when dual core is used and a panic alert comes from
the CPU thread. This change re-adds synchronization for that case.
The fix in ef77872 worked for panic alerts from
the CPU thread, but there were still problems with
panic alerts from the GPU thread in dual core mode.
This change attempts to fix those.
This matches BootManager.cpp's old behavior.
Note: The other settings of the "Controls" section (WiimoteSource
and WiimoteSourceBB) are still handled in BootManager.cpp.
JosJuice