## Link to GitHub Issue or related Pull Request, if one exists
Fixes#635
## Description of change
Adds optional **button modifiers**, allowing a binding to require one or
more "modifier" buttons to be held before it activates.
- New "Modifiers" controller page in the overlay config to bind the
Modifier 1–4 source buttons.
- Each binding gains a 4-bit modifier_mask (Modifier 1-4). It is
persisted as an optional modifiers XML attribute on button nodes and
controller-preset entries. The attribute is optional and defaults to 0,
so existing config files and presets load unchanged and the feature is
off unless the user opts in.
- The button Edit properties popup gains a "Modifiers" dropdown to pick
which modifiers a binding requires. Doesn't apply to MIDI though.
- Input evaluation skips a binding whose required modifiers are not
held, falling through to its alternatives; velocity reporting uses the
same gated path.
- Controller-preset templates gain a "Modifiers" group for importing and
exporting.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
Fixes#603
## Description of change
Scanning for midi devices can take a while on Windows 11 with MIDI 2.0
service. Sometimes it'll take a couple seconds. Sometimes, on a PC with
zero MIDI devices, it takes 10-11 seconds.
This was causing two issues:
1. slow startup time
2. crash on invalid memory access due to a race condition
Address both.
Also fix a bug: when a device change event fires, we do a MIDI scan, and
invalidated all existing MIDI devices in favor of creating new handles.
Stop doing this, and instead check for duplicates by matching the ID and
keep existing device handles alone. Properly clean up devices on unplug.
Also: fix MIDI buttons being stuck on when unplugged while holding a
key.
## Testing
Tested with Nostroller in MIDI mode. rtpMIDI works too.
## Link to GitHub Issue or related Pull Request, if one exists
#181
## Description of change
Implement analog relative mode and delay option using a new
millisecond-based algorithm.
## Testing
WIP
## Link to GitHub Issue or related Pull Request, if one exists
Related to #181
## Description of change
This PR removes two features marked as "experimental" for analog axis -
`Delay` and `Relative Axis`.
They have been in spice as experimental option for almost 2 years.. but
they have a fundamental problem of being tied to how often the analog is
polled. Not just how often the game's I/O emulation code polls it, but
literally any source (spice API, overlay, etc).
For `Delay`, the only real usage I'm aware of is for #181 which is
delaying IIDX turntable input. For this, I will follow up with a
separate PR that adds back the delay option specifically for IIDX.
For `Relative Axis` - I'm not quite sure if any one actually uses this.
This could be implemented per-game if some game demands it. Polaris
Chord already has one, for example.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Currently, all analogs are treated as circular values that wrap around.
This works for knobs and turntables, but can get weird for linear values
(like tilt sensors and sliders) especially once analog options are
enabled, such as sensitivity.
This PR groups analogs into 3 buckets: circular, linear (centered), and
linear (positive). Linear types get different algorithms applied to it
when options are set (e.g., sensitivity caps out at 0, 1 instead of
wrapping around).
In linear mode:
* Sensitivity value applies an exponential response curve (power curve)
to the original value.
* Multiplier/divisor serves as a linear cut-off.
* Relative mode works as you expect, but of course, values don't wrap
around.
* Invert and deadzone work as you expect (since they applied to the
controller input anyway)
* Smoothing is removed from the UI and has no effect.
* Delay is unaffected.
Also, fix a small bug with -/+ button not working for analog `Delay`
option.
## Testing
WIP
## Link to GitHub Issue or related Pull Request, if one exists
#653
## Description of change
By default, BAT Positive / Negative binds trigger when the stick is
tilted 10% off the center.
This needs a bit more customization since:
1. User may want to customize the center point (e.g., guitar controller
neutral position)
2. User may want to adjust the sensitivity (e.g., guitar controller tilt
angle to trigger wailing).
## Testing
WIP
## Link to GitHub Issue or related Pull Request, if one exists
#616
## Description of change
`Naive` button is now called `Naive/XInput` and detects XInput
controllers
Add vibration output as "Lights"
Add proper hotplug support and multiple controllers
Fix misc bugs on x86
## Testing
I tested with two xbox controllers.
## Link to GitHub Issue or related Pull Request, if one exists
#616
## Description of change
Adds preliminary support for XInput controllers. Enough to manually bind
buttons and map analogs.
## Link to GitHub Issue or related Pull Request, if one exists
#576
## Description of change
Add `Reset All` buttons to these tabs which clears out bindings to none
/ default.
For keypads, introduce a special `Use Preset` button which lets users
pick between numpad and top row number keys.
Update UI-visible string used for vKeys, especially the numpad ones
(e.g., `.` is now `Numpad .` to distinguish from the regular `.`
period).
Breaking change: if the user never had `P1 Keypad 00` set, the default
will change from `Enter` to `Numpad -` since both enter keys trigger the
same. This will affect a small number of popn/ddr players. They can just
change it back.
## Testing
*how was the code tested?*
## Link to GitHub Issue or related Pull Request, if one exists
#574
## Description of change
Refactor so that grouping of lights are in common I/O code. Add this to
IIDX/SDVX/DDR/GitaDora.
## Testing
## Link to GitHub Issue, if one exists
#0
## Description of change
Occasionally we would read a bad "vKey" for an analog axis and end up
accessing invalid memory (beyond the size of a vector) and potentially
crash or read junk values.
## Testing
Fixed based on minidump, this was a rare repro though.
## Link to GitHub Issue, if one exists
Fixes#139
## Description of change
Add an option for detecting window focus when accepting input.
The new default will be to have the following:
* naive bindings will check for window focus
* rawinput binds are not affected, will continue to be accepted
regardless of focus
Other options (always / never choices) can be picked by the user to
tweak the behavior if needed.
Clean up usage of `0xff` constant to represent invalid naive vkey.
## Testing
Still in progress, especially in regards to performance.
On a i7-9700 system, 10000 calls to `superexit::has_focus()` takes
250-350 microseconds, so this should not be a big deal at all.
bicarus