Gecko codes are a core foundation of most netplay sessions and most general modding cases. It has gone so far as to now have an ini for almost every game.
After the massive UI overhaul, the gecko code sorting defaults to Alphabetical with no option to change it. This removes the possibility for netplay builds to have important and necessary codes at the top for easy selecting, and removes the ability to sort massive code lists in categories.
This will also make the sorting consistent with AR codes, which are sorted manually.
glBlitFramebuffer() does not bypass the scissor test, which meant that
part of texture copies (e.g. XFB) could have been clipped when running
under OpenGL ES, as glCopyImageSubData() is not supported.
floatindex is clamped to the range [0, 9]. For non-negative numbers
floor() is equivalent to trunc(). Truncation happens implicitly when
converting to uint, so the floor() is unnecessary.
These country codes have the unfortunate property that they are used
by Wii disc games in two different regions. We already correct for this
in VolumeGC::GetCountry and VolumeWii::GetCountry, so this commit
shouldn't really have any effect on how the game list behaves,
but it will be useful if we in the future would want to call
CountrySwitch directly without having extra code in the caller for
handling region weirdness.
This avoids out-of-bounds warnings when replaying FIFO captures.
The value of XF_REGS_SIZE is written into the DFF header and we only
read the min of XF_REGS_SIZE and the header value, so this change is
backward compatible and doesn't break forward compatibility for old
Dolphin versions either.
With the nature of android updates invalidating save states, it's best to hide
these options unless enabled by the user. The option to use savestates can now
be enabled via the General settings menu.
* Removed the Cancel button since the code doesn't react to it anyway.
* Only show a window title, not the help icon (?), and disable the close button
* Set the title to "Dolphin" instead of repeating the label text
Switch to using additional overloads of sf::Packet, so we can eliminate
some of the messy code and just use the normal syntax for
BigEndianValue.
We can't avoid helper functions with u64 due to SFML's non-standard way
of defining 64-bit integer types.
The current approach results in the UI thread creating a graphics device
whilst the core is running, leading to races on function pointers, and
potentially crashing.
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de 00 movabs rax,0xdeadbeef
7: 00 00 00
With this change, it will instead rely on the fact that on x64 writes to
32-bit registers are automatically zero extended to 64-bits, allowing
us to emit a 5 or 6-bytes instruction with the same effect for certain
immediates.
0: b8 ef be ad de mov eax,0xdeadbeef
Fixes a critical regression from 8bb08d1ca6.
In that commit, I replaced a 1024 byte buffer with a SHCIEventCommand.
However, it looks like some Bluetooth adapters actually require such
a large buffer, so this change needs to be reverted.
This fixes severe image flickering in some cutscenes of Twin Snakes. The game appears to sometimes load a previously made XFB copy as a texture before it is actually rendered to the screen, which we took as an invitation to invalidate the XFB copy.
Prior to this commit, the emitter would unconditionally emit a 10-byte
instruction known as MOVABS when loading a 64-bit immediate to a
register.
0: 48 b8 ef be ad de ff movabs rax,0xffffffffdeadbeef
7: ff ff ff
With this change, it will instead emit a 7-byte instruction when it is
possible to express the 64-bit immediate using a signed 32-bit value.
0: 48 c7 c0 ef be ad de mov rax,0xffffffffdeadbeef
Two reasons for this change. First, it appears that some android launchers do some sort of call into
the application when long pressing the app icon, which in turn calls the DirectoryInit service. This
was ok to do prior to Oreo but will cause crashes with the new restrictions on services running
in the background. Which leads to the second reason that DirectoryInit doesn't need to be a service
at all since these actions are required for dolphin to function and shouldn't be a scheduled action.
So we instead just kick this off in a new thread and send the broadcast when done.
If, for whatever reason, the XFB has to be loaded from console memory, it's possible that the texture is returned at native resolution instead of EFB-scaled resolution. In this case, our xfb_rect.right adjustment must also happen at native resolution instead of scaled resolution.
The header of a Wii disc can be read from two places: The
unencrypted area at the beginning of the disc, or the beginning of
the game partition. The two copies are usually identical (except
for 0x60 and 0x61), but there are exceptions. For most of Dolphin's
history, we have been reading from the header inside the game
partition when getting metadata. This was however not the case
starting with 4.0-4901 and ending with 5.0-3762. This commit once
again makes Dolphin read metadata from the unencrypted header,
because of the following reasons that I recently was informed about:
- The "pink fish" disc has the game ID 410E01 in the unencrypted
header but the placeholder game ID RELSAB in the partition header.
- The revisions of some games differ between the two headers,
with the unencrypted one making more sense.
(See https://bugs.dolphin-emu.org/issues/11387)
For better or worse, this also means that sloppily hacked games where
only the game ID in the unencrypted header has been changed now will
use that modified game ID. And unlike with the partition header,
there is no signing or hashing that can tell us whether the
unencrypted header has been modified by someone other than Nintendo.
Dolphin has traditionally treated the SI IO buffer (128 bytes) as a set of
32 little endian u32s. This works out fine if you only ever read/write
using aligned 32bit accesses. Different sized accesses or misaligned reads
will mess it up. Byte swapping reads/writes will fix this up, but all the
SI devices that use the SI IO buffer need to be adjusted.
The LogManager code had trouble detecting the "/Source/Core/" substring
for two reasons, neither of which seemed to happen a few years ago:
1. __FILE__ is in lowercase on MSVC
2. __FILE__ uses backslash as the directory separator on MSVC
Fixes https://bugs.dolphin-emu.org/issues/11366
Several functions (and one variable) were being given external linkage.
Instead, relocate them all to anonymous namespaces to make them
internally linked.
Puts the comment in the header where it's more likely to be seen
initially. We can also remove the TODO, given doing nothing or returning
an error is what is generally done for the JIT interface if the JIT
instance isn't valid.
With 7aa305ea35 merged, all that remains
within Profiler.cpp is an unused function that just forwards to the
equivalent function within JitInterface. Given that, we can just remove
the source file.
This global belongs in the JitOptions structure, as it's a conditional
setting (A.K.A. option) that changes the behavior of what the JIT does.
Plus it keeps the scope of the variable constrained to the general area
it's intended to be used and nothing further.
swap32() has a const u8* overload that swaps the data being pointed to as
if it were a 32-bit word. We can just use that instead. It gets rid of
undefined behavior, as we're not type punning a pointer and dereferencing it,
and gets rid of the need to cast entirely.
In both cases of the x64 and AArch64 JITs, these would have const casted
away from them, followed by them being placed within an emitter and
having breakpoint instructions written in them.
In this case, we shouldn't be using const period if we're writing to the
emitted data.
Similar in nature to e28d063539 in which
this same change was applied to the x64 emitter.
There's no real requirement to make this const, and this should also
be decided by the calling code, considering we had places that would
simply cast away the const and carry on
Xlib supports many mouse buttons, though there are 9 standard buttons, and they aren't arranged like other mouse APIs. Using only 5 buttons was preventing the use of buttons besides left/right/middle click and the scroll wheel. Here's what all the standard buttons are:
1. left button
2. middle button (pressing the scroll wheel)
3. right button
4. turn scroll wheel up
5. turn scroll wheel down
6. push scroll wheel left
7. push scroll wheel right
8. 4th button (aka browser backward button)
9. 5th button (aka browser forward button)
The remaining button indices are non-standard and device-specific, and technically far more than 32 are supported, but this seems like a reasonable limit to avoid cluttering the list with tons of useless mouse buttons. What mouse has more than 32 buttons anyways?
