This was causing an issue where DolphinQt couldn't save graphics options
(DolphinWX doesn't hit this code path), because this function was being
called before the in-memory config was flushed to disk.
With this PR, the in-memory config isn't reset, and only SYSCONF-related
variables may get changed.
7f0834c9 moved the locations of the Real XFB (now XFB to RAM) and
Disabled XFB (now Immediate Mode) settings. There are programs
other than Dolphin that parse DTM headers, so this is not good.
Note that Immediate XFB actually is the inversion of Disabled XFB.
I hope that's not too much of a problem...
All file scope variables are able to be made internally linked.
CD3DFont is essentially used as an extension to the utility interface, so
this is able to be made internal as well, removing a global from
external view.
This lets Dolphin know if a configured GameCube Controller should actually
be treated as connected or not.
Talked to @JMC47 a bit about this last night. My use-case is that all of
my controllers are the same hardware (Xbox One controllers) so share the
same configuration (modulo device number). Treating them all as always
connected isn't a problem for most games, but in some (Smash Bros.) it
forces me to go find a keyboard/mouse and unconfigure any controllers
that I don't actually have connected. Hotplugging devices (works on macOS,
at least) + this patch remove my need to ever touch the Controller Config
dialog while in a game.
This patch makes the following changes:
- A new `BooleanSetting` in `GCPadEmu` called "Always Connected", which
defaults to false.
- `ControllerEmu` tracks whether the default device is connected on every
call to `UpdateReferences()`.
- `GCPadEmu.GetStatus()` now sets err bit to `PAD_ERR_NO_CONTROLLER` if
the default device isn't connected.
- `SIDevice_GCController` handles `PAD_ERR_NO_CONTROLLER` by imitating the
behaviour of `SIDevice_Null` (as far as I can tell, this is the only use
of the error bit from `GCPadStatus`).
I wanted to add an OSD message akin to the ones when Wiimotes get
connected/disconnected, but I haven't yet found where to put the logic.
This is already initialized in the class definition. This would
previously cause a -Wreorder warning on macOS, as m_config is
defined after m_currently_mapped.
Originally, Layer contained a std::map of Sections, which containted a std::map
containing the (key, value) pairs. Here we flattern this structure so that only
one std::map is required, reducing the number of indirections required and
vastly simplifying the code.
No code is relying on this unexplained null byte check, since
the only code that calls UTF16ToUTF8 on non-Windows systems
is UTF16BEToUTF8, which explicitly strips null bytes.
Axis range was previously calculated as max + abs(min), which relies on the assumption that
min will not exceed 0. For (min, max) values like (0, 255) or (-128, 127), which I assume to
be the most common cases, the range is correctly calculated as 255. However, given (20,
235), the range is erroneously calculated as 255, leading to axis values being normalized
incorrectly.
SDL already handles this case correctly. After changing the range calculation to max - min,
the axis values received from the evdev backend are practically identical to the values
received from the SDL backend.
This has no effect now, as we've never bumped the database version.
Instead, it adds future proofing, and makes moving between a future
version with a bump and master clean.
We shouldn't try to create folder names that contain characters
such as : or / since they are forbidden or have special meanings.
(No officially released disc uses such characters, though.)
Now that all inputs are corrected to zero-centered, we can use getFlat()
to ignore movements that are just noise.
This eliminates a lot of drift when the controller is at rest, notably
on the character select screen in Melee.
Android reports the same physical axis multiple times for analog
triggers, and this handles this case.
There are also some controllers with broken mappings (eg the analog
triggers on a PS4 DualShock 4). These axis don't center correctly.
There are also some controllers (again, the PS4) that send both a button
press and an axis movement. This ignores the buttons so we can use the
analog axis. Otherwise, since the button comes before the axis moves
far we would always take the button.
Stenzek