## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
- Replace unnecessary precision timers with standard sleeps to reduce
wakeups and background CPU usage.
- Reuse buffers in raw input, touchscreen, and HID output paths to
eliminate steady-state allocations.
- Pre-index HID button groups and correctly process batched HID reports.
No functional changes.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
Regressed by #790
## Description of change
Avoid enumerating every display mode with `EnumDisplaySettings` during
the first raw touchscreen report, as it can take a couple hundred
milliseconds.
The latency-sensitive path now refreshes only the current display size
using `GetWindowRect(GetDesktopWindow())` and orientation using
`EnumDisplaySettingsEx(..., ENUM_CURRENT_SETTINGS, ..., EDS_RAWMODE)`.
Full `EnumDisplaySettings` enumeration runs only when native resolution
is needed for aspect compensation.
Jubeat and Reflec Beat now enable aspect compensation before
initializing touch input.
## Testing
Sanity checked rb/jb on laptops with non-16:9 ratio
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Fix a long-standing issue of hotplug not working for keyboards and mice.
The code only registered for HID notifications; we also need to do it
for the keyboard GUID and mouse GUID.
## Testing
Confirmed that keyboards and mice can be hot unplugged and plugged.
## Link to GitHub Issue or related Pull Request, if one exists
Regressed by #793
## Description of change
Due to lock inversion, when binding an analog axis as a button, spice
deadlocks. Fix that.
Also create a separate `unordered_map` that keeps track of device
handles so that `WM_INPUT` handle can look up devices without having to
acquire the larger `devices_mutex` which could be held by (potentially)
lengthy operations like hotplug.
Fix more synchronization issues around hotplug. Latent bug exposed by
MIDI 2.0 issues.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Fixes held touch contacts briefly dropping under rapid multi-touch (e.g.
holding several jubeat buttons and tapping elsewhere many times would
make the holds briefly release and the hold again).
A HID digitizer reports a fixed number of contact slots per report and
cycles the rest through later reports, so the touch layer keeps an
unreported contact alive for a few reports (a per-contact TTL). The TTL
was only set for contacts in the current report and had no slack, so
when the contact count rose (from the rapid taps) the reporting cycle
got longer and stationary holds were expired before the device cycled
back to them.
Now, the cycle length is recomputed every report and every tracked
contact's TTL is extended to it (never shrunk), so a rising contact
count can't starve a currently held contact. The 50 ms last-report
timeout still removes genuinely lifted contacts.
## Testing
Tested on jb, rb.
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Two changes:
1. Handle all HID events in `WM_INPUT` and not just the first one. This
only really affects 4000Hz / 8000Hz HID devices.
2. Go back to `3x3` as the default for rb IR touch emulation and remove
`1x1` as an option as it does not perform as well as I expected.
## 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
Fixes#697
## Description of change
Adds aspect-ratio compensation for raw input touch handler.
This addresses the problem with playing rawinput touch games - namely
jubeat and reflec beat - on a display that is not 16:9, and user chose
to preserve the aspect ratio. This happens a lot on:
* 16:10 touch screens
* touch screen laptops (which range from 3:2, 16:10, and so on).
Root cause is a **Windows Raw Input limitation**. Unlike
`WM_POINTER`/`WM_TOUCH`, where the OS already maps digitizer coordinates
to screen space (applying the display's calibration/scaling), Raw Input
delivers the HID digitizer's *raw* logical coordinates, spanning the
whole physical panel, with **no calibration or display-mapping data
attached**. We have to reconstruct that mapping ourselves.
When a game runs at a display mode whose aspect ratio differs from the
panel's native resolution, Windows scales the image with
letterboxing/pillarboxing (black bars). That is standard OS/GPU
behavior. Because Raw Input gives us no mapping to account for those
bars, touches land off-target. This change detects the mismatch and
remaps each touch from panel-space into the displayed image region;
touches inside the black bars are treated as released.
Adds new launcher option **`-rawtouchaspect`**.
Notes:
- Native resolution is the largest-area mode from `EnumDisplaySettings`
on the **primary** display, consistent with the existing primary-only
touch pipeline.
- Math assumes centered, aspect-preserving scaling; only one axis is
ever inset.
- A small epsilon (0.01) makes near-matched panels (e.g. 1366×768 vs
true 16:9) a no-op.
- If the user forces a stretched image, then the touches will be off
again. In this case, the user needs to use the `force off` setting.
## Testing
On my tiny Surface Go tablet,
* checked that jubeat squares align correctly
* good enough to full combo level 11 for reflec beat
## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Closing spicecfg was blocked for up to ~495 ms. Runtime behavior is
unchanged: same flush interval and same output path during normal
operation. Only shutdown teardown is faster.
## Testing
Opened and closed spicecfg.exe repeatedly; the window closes immediately
with no hang
## Link to GitHub Issue or related Pull Request, if one exists
Fixes#681
## Description of change
`Sleep` and `sleep_for()` can be very inaccurate and varies depending on
what the OS gives us...
### `timeBeginPeriod(1)`
On boot, we are now calling `timeBeginPeriod(1)`, which affects the
whole process but makes `Sleep` more accurate. There is some risk here
if any game was relying on doing things like `Sleep(1)` and expecting it
to run for 15.6ms. Most games already call `timeBeginPeriod(1)` in the
game engine, though not the whole time, so I'm hoping that this is not
too impactful.
### Opt out of Win11 power throttling
Ensure that timer resolution change above is respected even when the
window is occluded / minimized by opting out of throttling via
`PROCESS_POWER_THROTTLING_IGNORE_TIMER_RESOLUTION`.
### Use Win10 high resolution timer instead of Sleep
On Win10 1803 and above, there is a new OS-level API for high resolution
timers; if this is available, use it
(`CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`). Worth noting that WINE
doesn't support this currently.
If not, fall back to `Sleep`, which is significantly better than
`sleep_for()` in my experiments.
Callers of Sleep / sleep_for were replaced with this new timer. Most of
them anyway; calls to Sleep() with more than 100ms+ was left alone.
### Add an option as a chicken bit
To opt out I'm adding a new option called `Use Legacy Timers` which will
revert to behavior before this PR. The code paths that switched from
`sleep_for` to `Sleep` will remain in place though, not affected by the
option.
## Expected changes
In some I/O emulation modules, poll threads may run more frequently,
resulting in lower latency.
It also means that spice overall may use more CPU resources and power.
If you don't like this, you can always enable the option to opt out;
e.g., if you're on old arcade cab PC.
## Testing
DDR p4io - ok
drs touch hook - ok
IIDX camera hook - ok
CCJ trackball - ok
## Link to GitHub Issue or related Pull Request, if one exists
#616
## Description of change
Fix UI labels being wrong for analog stick up/down (they were reversed).
Adjust deadzone so that when sticks are bound as digital buttons, they
are not as sensitive.
Small refactoring of code.
## Testing
Tested via spicecfg using my xbox one controller.
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Some crappy DDR soft mats (either USB-based or console pads with crappy
adapters that lack a dedicated "DDR pad mode") use X and Y analog axis
for arrows, which means they cannot cleanly report Up+Down or Left+Right
input.
According to some ancient Stepmania code, a lot of these report a middle
value (value between center and right, for example, for left+right).
Borrow this hack from Stepmania and implement it in spice as analog
input for DDR.
Also, for rawinput/xinput automatic bind scenario, update the logic so
that face buttons are always detected before analog axis / dpads for
consistency. This would help with binding any DDR pads that
simultaneously input face buttons / dpad / analog axis, so that we can
prefer face buttons when detected.
## Testing
I don't have any soft mats that have this, but it was tested with an
xbox controller.
## Link to GitHub Issue or related Pull Request, if one exists
regression caused by #653
## Description of change
Some controllers - like the Xbox One controller I have - reports
0xffffffff as the max range value for analog, despite reporting 16-bit
width. This causes us to consider 0xffffffff as -1 so the range became
[0, -1] which is invalid.
Our automatic calibration does eventually fix this (-1 will fix itself
to become the highest actual value reported, which would be 0xffff).
This seems to be a common issue with XInput-based controllers in
general: see `Correct_Axis_Max` in
https://github.com/argonlefou/DemulShooter/blob/master/DsCore/RawInput/RawInputController.cs#653 removed the fix that was masking this issue. Put in a new fix that
fixes these up.
## Testing
Tested with Xbox One controller.
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Official GuitarFreaks controller has the motion sensor values with
`valuemin=-127` to `valuemax=127` and we don't deal with negative values
correctly.
## Testing
tbd
## Link to GitHub Issue or related Pull Request, if one exists
Fixes#648
## Description of change
Deal with devices in hybrid packet mode that send garbage data in second
packet when it's out of bounds (outside the number of contact points).
MSDN says they're supposed to be (0, 0), but some devices don't follow
the spec.
## Testing
I don't have a device that reports garbage values but this should fix it
in theory.
I tested on my Dell touch monitor which is in hybrid mode & sends 5
touches at a time, but can split across two packets to send up to 10
touches. It sends (0, 0) for the remaining slots when there are 6-9
touch points, but confirmed that there was no regression.
## Link to GitHub Issue or related Pull Request, if one exists
#624
## Description of change
See bug. Add locale hooks specifically for CCJ.
also, fix y axis direction for XInput, it was flipped because XInput
uses opposite values from what RawInput does
## Testing
Tested card in / play one round with Windows regional format set to
French (France) and other language set to English.
## Link to GitHub Issue or related Pull Request, if one exists
#616
## Description of change
The IDs don't really get used anywhere if it's not a real HID or MIDI
device, but putting them for completeness since they show up in Controls
overlay menu.
## Testing
## 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
Fixes#563
## Description of change
When buttons are presented as NotRange and instead an array of single
buttons, we are calling `HidP_GetUsages` expecting at most one result
back, but in reality we need to expect all possible buttons on that
usage page since `HidP_GetUsages` returns all buttons in the usage page
+ link collection which would be the entire array of buttons - see
documentation for `HidP_GetUsages` on MSDN.
## Testing
Tested with my own controller modifying USB descriptors... more
controller testing is needed.
## Link to GitHub Issue or related Pull Request, if one exists
## Description of change
Introduce a new modal dialog for picking out some of the options to
improve UX.
Implemented a few for now:
1. UI for picking ASIO drivers from a list (for -iidxasio, -sdvxasio,
-asioconvert, etc)
2. Button to generate card numbers for -card0 and card1
3. Processor Affinity selector (very similar to what's in Windows Task
Manager, list of checkboxes)
4. file selector (file open dialog for various file path overrides like
log file)
5. folder selector (folder override)
I wrote a selector for COM ports as well but how we use the value was
inconsistent (\\\\.\\COMx vs. COMx) and didn't see a huge point in it so
I didn't check it in.
## Testing
## Link to GitHub Issue, if one exists
n/a
## Description of change
Game expects primary monitor to be in 90 deg rotation, and does the
touch calculation accordingly.
If the user does 270 deg rotation ("portrait, flipped") then the game's
touch calculation is flipped upside down. Detect this and provide the
fixed up values in the touch hook.
## Testing
Tested with SDVX in 90 deg, 270 deg rotation, and 1080p, forced 1440p.
## Link to GitHub Issue, if one exists
Fixes#512
## Description of change
Fix digital wailing not being recognized consistently.
Also address the fact that wailing was completely broken when lefty mode
was on. This requires a new option that the user needs to check off in
the configurator since we can't magically guess if the user is holding
the guitar in lefty mode.
- [x] fix downward wail
- [x] digital lefty mode
- [x] implement all of this for arena model i/o
- [x] test dx cab 2p
- [x] lefty toggle in overlay
- [x] fix analog not working for 2p guitar
- [ ] analog lefty mode?
## Testing
Checked GW and GW Delta
## Link to GitHub Issue, if one exists
#452
## Description of change
(Another extension of #450)
Merged the old threading implementation into the current backfill
implementation because it was showing signs of having slightly better
timing performance. The following description is taken from the
strikethrough text from the referenced PR above:
>When the module is booted, it counts how many times
ac_io_mdxf_update_control_status_buffer was called in the first three
seconds, then calculates the approximate refresh rate of the current
game instance. If the refresh rate is under THRESHOLD_REFRESH_RATE
(120Hz), a low-priority thread dedicated to inserting polls into the
ring buffers is started and run at THREAD_REFRESH_RATE_HZ (125Hz).
Combined with the polls inserted by the main arkmdxp4 thread and
rawinput real-time events, the 125Hz update cadence is enough to bring
the span of poll history represented by the ring buffers closer to
parity with what arkmdxp4 expects.
The default mode is `THREAD_MODE` but can be switched to `BACKFILL_MODE`
(which could possibly be made as a `spicecfg` option).
There was also a fixed bug in the `ac_io_mdxf_get_control_status_buffer`
function, which should not have been writing to the `head` pointer. This
was allowing for an edge case situation where the `head` pointer was
advanced in another thread then rewound back to the previous `head` in
this thread. The real implementation only reads the pointer and returns
it.
## Testing
- Logged the ring buffer states after many iterations and verified
regular structure
- Same playtesting as the prior PRs
## Link to GitHub Issue, if one exists
n/a
## Description of change
This would save a handful of instructions at best but it was bothering
me
## Testing
Tested with two controllers + naive with ddr
## Link to GitHub Issue, if one exists
#452
## Description of change
- Extension of #450
- Moved the call to `arkGetTickTime64()` outside the update function to
bring the timestamps closer to real-time
- Changed the update function to only call `getState()` if called from
`rawinput`, otherwise just fill the ring buffer entries with the last
known state
- Changed the update function to only write one ring buffer entry if
called from `rawinput`
- Moved the call to `mdxf_poll()` within `rawinput.cpp` outside the loop
that iterates over all devices
## Testing
- Logging was done to verify the span of poll history covered by each
request for 7 ring buffer entries was ~28ms, as the game expects
- Observed some improvement in timing precision since the prior
implementation
## Context
In the real implementation of `ac_io_mdxf_update_control_status_buffer`,
it doesn't actually add entries to the pad state ring buffers (it only
marks the head entry as the "last consumed" entry), and `arkmdxp4.dll`
expects the ring buffers to be updated at regular intervals inside
`libacio2.dll` at ~250Hz per player. Instead, in the emulated version,
the updates happen in this function and that regular interval is
established internally using the game's refresh rate (60Hz, 120Hz,
144Hz, etc.). This effectively locks the polling rate of pad input to
that refresh rate, which is quite low for pad input.
## Description of change
The polling rate lock was circumvented by calling
`ac_io_mdxf_update_control_status_buffer` as soon as the game receives
controller input in `rawinput.cpp`. A simple wrapper function
`mdxf_poll` was exposed so press and release events could be added to
the ring buffers in real time as they happen. After each controller
event in `rawinput.cpp`, `mdxf_poll` calls
`ac_io_mdxf_update_control_status_buffer` for each player, checking the
pad's current state and adding it to the ring buffer if it's changed
since the last call. This results in the 0 -> 1 (press) and 1 -> 0
(release) state transitions used for gameplay to be based only on the
real-time events inserted from `rawinput.cpp`, while leaving the rest of
the entries generated from the main `arkmdxp4.dll` thread as "padding"
the game expects (I actually tried reducing the ring buffers to *only*
write entries on state transitions, but it broke gameplay, which means
the game still depends regular reporting of the pad state). Here's an
example of how a ring buffer would look if an arrow was pressed at some
time 32ms (assume 165Hz game refresh rate, ~6ms updates):
```
Old (only frame updates):
1 | 36ms
0 | 30ms
0 | 24ms
0 | 18ms
0 | 12ms
0 | 6ms
0 | 0ms
```
The game only sees the press event at time 36ms on frame update, so time
36ms is assigned to the press time of that arrow (4ms later than the
real press time).
```
New (frame updates + event updates from rawinput.cpp):
1 | 36ms
1 | 32ms <- from rawinput.cpp
0 | 30ms
0 | 24ms
0 | 18ms
0 | 12ms
0 | 6ms
```
The game sees the real press time 32ms on frame update, so the correct
press time 32ms is assigned.
## Testing
- Played on various refresh rates and verified the controller input
remains highly responsive.
- Inspected the ring buffers with a debugger and verified entries for
press and release events from `rawinput.cpp` were correctly being added
for their respective players.
## Link to GitHub Issue, if one exists
n/a
## Description of change
For HID device descriptor, use the "W" version of Windows API, and make
sure UTF-8 is being used throughout since that's the only format IMGUI
supports.
Before this change, non-Latin characters would have shown up as `HID ???
?????` for a mouse, for example.
Due to the way ImGui loads fonts, only the following languages are
supported:
* Simplified Chinese
* Cyrillic
* Japanese
* Korean
* Thai
* Vietnamese
## Testing
Tested various combination of Windows UI language and non-Unicode
language.
## Link to GitHub Issue, if one exists
Fixes#364
## Description of change
The game attempts to hook raw input, but raw input API can only be used
by one window per process. Hook `RegisterRawInputDevices` and prevent
the game from registration for raw input notifications.
## Testing
Tested that HID keyboard works with `Bind` option.
## 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-dev