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.
This matches BootManager.cpp's old behavior.
Note: The other settings of the "Controls" section (WiimoteSource
and WiimoteSourceBB) are still handled in BootManager.cpp.
The "DSP" game INI section name was supported by BootManager.cpp
before the section was ported to the new config system.
For backwards compatibility, we should keep supporting it.
Should fix https://bugs.dolphin-emu.org/issues/12792
It's a complete coincidence that both SIDEVICE_GC_CONTROLLER (6)
and SIDEVICE_WIIU_ADAPTER (12) are divisible by 6. Dividing
by 6 because of that doesn't make sense, especially not if we
want to add support for more kinds of SI devices on Android later.
We don't use sampler2DMS, but we do use sampler2DMSArray.
I can't reproduce it on my phone, but a user who was running GLES
on a Tegra X1 reported a shader compilation error related to this.
At least on Android, SyncGPU has really bad performance compared to
single core. It's less stable too - I get fatal GPU desyncs in
Pokémon XD using the default settings.
It's always a good sign when the comments say "this will definitely
crash" and "I don't know if this is for a good reason".
Fixes https://bugs.dolphin-emu.org/issues/12762.
These GetPointer calls could cause crashes, in part because the
callers didn't do null checks and in part because GetPointer
inherently is unsafe to use for accesses larger than 1 byte.
JosJuice