Use large card view rounded corner guidelines
Fix action bar theming
Needed to import android back button clip art to fix material 3 theming issue. The DolphinSettingsBase style used to inherit from the Theme.MaterialComponents.DayNight.DarkActionBar theme which would provide the light text and icons but this is no longer available with Material 3.
Fit box art more snugly in CardView
Change card height to match cover art
Add padding to top of games list recyclerview
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.
New dolphin-tool command: "header"
-b / --block_size
-c / --compression
-l / --compression_level
Informative RVZ/WIA header2 value "compression_level" is now a s32 instead of a u32, because negative compression is a thing.
Speaking of, it is now possible to use negative compression levels in dolphin-tool's convert command (not the GUI, though).
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.
If libusb fails to initialize, an assertion fails, but if that happens before the main window is created, then Dolphin just dies. Now, the panic alert is properly shown and the user can ignore it.
These messages hid other, more important, ones often. I have left AttemptMaxTimesWithExponentialDelay and GetSysDirectory/SetSysDirectory as info, since those are called infrequently and can be useful to the end-user.
This message would be logged, usually multiple times, for EVERY. SINGLE. PIXEL. That's pretty much useless and just makes the log unreadable. Plus, the current support (which acts as RGB8) is close enough that for end-user purposes, it's fine. I don't think the hardware backends support RGB565_Z16 and its antialiasing functionality correctly either, but they don't have similar logspam.
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.
Currently, the axes for the main and C sticks range from 0-255, with
128 being the mid-point; but this isn't symmetrical: the negative axis
has 128 values not including 0, while the positive axis has 127 values
not including 0.
Normalizing so that the range is 1-255 makes the positive and negative
axes symmetrical. The inability to yield 0 shouldn't be an issue as a
real GC controller cannot yield it anyway.
I.e. flush pokes before running an EFB peek, if the cache tile isn't present. If the cache tile is present, then EFB pokes should have been written to the cache tile and thus don't need to be flushed.
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.
Previously, when Pause at End of Movie was disabled, the game would continue running as it should, but the menu bar would think the game was paused, showing the play button instead of the pause button. To make things worse, clicking the play button would then restart the game, instead of pausing or doing nothing. F10 paused/unpaused as normal, though.
The old behavior was essentially to enable stepping/pause mode (via `CPU::Break()`) and then if Pause at End of Movie was disabled, to un-pause on the host thread (via `CPU::EnableStepping(false)`). For reasons which aren't entirely clear to me, the first one notified the menu bar (through the `Host::UpdateDisasmDialog` callback, not the `Settings::EmulationStateChanged` one), and the second did not. In any case, this approach does not particularly make sense; I don't see any reason to pause and unpause if Pause at End of Movie is disabled; instead, we should only pause when Pause at End of Movie is enabled.
This behavior was probably introduced in c1944f623b, though I haven't tested it.
directly_mapped_vars was added in #69 (4129b30494), but for some reason FIFO_BP_LO/HI were split out from it in in #885 (65af90669b). As far as I can tell, this code (and the code that existed at the time) is identical, so there's no reason to have it handled separately.
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.
The DSP JIT only applies on x64, so if it doesn't work on esoteric compilers then that's not a problem. (And if it fails to compile, then it'll still produce an error on that platform, just no warnings on other platforms)
The size variable started to be unused when I created std::array variants of ReadArray, but we should follow it in case any files have fewer registers stored than they should (otherwise the remaining registers would end up with garbage data from later in the fifolog). Though, there probably aren't many fifologs where this is relevant.
Large amounts of logging can have an impact on performance, so moving the ones that have been determined to not matter to the warn level gives a way to hide those messages without hiding actual errors (and also gives a fast visual way of distinguishing between ignored and non-ignored ones due to the different colors).
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.
It doesn't make sense for alpha to add the bias ONLY when dividing by 2, while color doesn't apply the bias for divide by 2 only; hardware testing indicates that alpha should have the bias.
This fixes the menus in Mario Kart Wii (https://bugs.dolphin-emu.org/issues/11909) but reintroduces the white rectangle in Fortune Street.
This reverts commit 5aaa5141ed (and several other matching changes elsewhere).
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.
* Disabled: disables the overlay pointer
* Follow: default behaviour, IR pointer follows touch position
* Drag: IR pointer moves relative to the initial touch event position
At least in GLSL, after calling EmitVertex() the value of all 'out' variables (including gl_Layer and ps) becomes undefined. On OpenGL it seems like they were unchanged, but on Vulkan they became 0, resulting in bad rendering.
Fixes https://bugs.dolphin-emu.org/issues/12001
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.
DiscIO depends on some IOS functions and other functions, which are in Core and not Common. This results in link errors if using DiscIO on its own (which is why DolphinTool had a listed dependency on videocommon; videocommon has a dependency on core so adding that made things build).
Fixes a crash that could occur if the static constructor function for
the MainSettings.cpp TU happened to run before the variables in
Common/Version.cpp are initialised. (This is known as the static
initialisation order fiasco.)
By using wrapper functions, those variables are now guaranteed to be
constructed on first use.
Using unsigned char* or signed char* results in a deprecation warning, which is treated as an error. It needs to be casted to regular char* for it to work.
Simonx22