## 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
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
#121
## Description of change
This implements a seperate ICCA card workflow for the slotted readers
acting how Resort Anthem expects, enabling cards to be inserted.
Additionally this fixes a bug where both card units would be treated the
same (for keypad reads) under Resort Anthem.
The slotted reader workflow was implemented as a seperate function for
two reasons - it would be nice to not mess with any existing code to
avoid breaking all the functional games, and the way the slotted readers
are handled by RA seemed different enough to how everything was already
designed to where it didn't make sense to keep adding special edge cases
for RA.
## Testing
IIDX18 was tested and cards could be inserted on both P1 and P2 side.
IIDX19 through 22 was tested to make sure nothing had broken for
wavepass emulation.
## Known Issues
In IIDX18, when a card isn't set but the insert key is pressed, after
the card timeout the game will error out with an invalid state error.
## Link to GitHub Issue, if one exists
n/a
## Description of change
Apply SOCD cleaner algorithm to deal with the case where both
counter-clockwise and clockwise buttons are pressed at the same time.
In SDVX, default algorithm is to prefer the most recently pressed
direction. This is better for dealing with slams in rapid succession,
for example, as you don't have to completely let go of one direction to
hit the other now.
In IIDX, default algorithm is neutral (same behavior as before). Using
last or first algorithm results in double scratches which means you'll
likely end up with an excessive poor after hitting a scratch, so neutral
is actually beneficial. Besides, if you are serious about playing on the
keyboard, you should be using `TT +/-` and `TT +/- Alternate`.
## Testing
Tested SDVX 3, EG (old cab), EG valk cab modes, IIDX 24, 27, 33
(tdj/ldj)
## Link to GitHub Issue, if one exists
#452
## Description of change
* Split the MDXF I/O option into three: auto, thread, and backfill.
`auto` is the same as what `thread` used to be before this change (based
on I/O poll rate), but `thread` now always forces thread poll mode.
`auto` is the default (behavior wise, same as before)
* For the poll rate measurement, start polling after 20s mark to avoid
frame drops during game boot
* Minor code clean up
## Testing
manual test in windowed + full screen
## Description of change
Extension of #460
An option was exposed to `spicecfg` (`P4IOBufferMode`) for toggling
between the Thread and Backfill buffer fill implementations from the
prior PR.
## Testing
- Verified the option properly toggled between the two implementations
## 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
#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
While testing the emulator on 60Hz for a while, I noticed there was a
pretty consistent timing bug with steps that had quick releases in
between them (mainly footswitches and sometimes jacks). As mentioned in
my previous commits, `arkmdxp4` determines press/release times for steps
based on a 7-poll history on every frame, which is normally populated at
~250Hz from the MDXF board in `libacio2`, yielding around 28ms of
polling history. When emulated, this is instead being populated
internally from `arkmdxp4` once per frame, meaning the 7-poll history
could have up to `1000/60 * 7 = 117ms` worth of step history at 60Hz. In
the case of a footswitch/jack, if you account for the real-time press
and release event that's inserted from `rawinput` during that time,
there'd actually be up `1000/60 * (7-2) = 83ms` worth of step history.
This is still a large enough window of time for `arkmdxp4` to start
confusing older on-state polls with more recent ones. Here is a real
ring buffer I logged when I reproduced the bug:
```
Frame #6: 82ms | 1
70ms | 1 <- rawinput real-time press
Frame #5: 66ms | 0
Frame #4: 49ms | 0
Frame #3: 34ms | 0 <- rawinput real-time release (coincided with frame update)
Frame #2: 16ms | 1 <- stale "held" poll
Frame #1: 0ms | 1 <- stale "held" poll
```
When `arkmdxp4` determines that a new press event occurred, it uses the
timestamp of the oldest on-state poll in the ring buffer as the press
time. In this case, it uses time 0ms instead of the correct 70ms,
resulting in the game thinking the player stepped 70ms before they
actually did. For reference, that same ring buffer snapshot would've
looked like this in the real implementation:
```
Frame #6: 82ms | 1
78ms | 1
74ms | 1
70ms | 1
Frame #5: 66ms | 0
62ms | 0
58ms | 0
```
The correct time 70ms would be assigned to that step in this case. This
demonstrates the importance of keeping the ring buffers filled with only
recent poll history, closer to the threshold of around ~28ms that the
real implementation expects.
## Description of change
~~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.~~
EDIT: The prior thread implementation was replaced with new logic that,
on each call to the update function, backfills the ring buffer with
entries representing the last known state of the controller. For
example, given the ring buffer with a single entry:
```
0ms | 0
```
When the update function is called on the next frame at 60Hz, the
function will insert intermediate entries as "padding" before updating
to its current state:
```
16ms | 1 <- state at current frame
12ms | 0 <- "padding"
8ms | 0 <- "padding"
4ms | 0 <- "padding"
0ms | 0 <- last known state
```
## Considerations
~~In the future, it might be worth exploring a route that interpolates
polls instead of relying on a thread for inserting polls (in other
words, creating intermediate poll entries based on the known real-time
press and release events from `rawinput`). For example, if `rawinput`
reported a press at time 10ms and a release at time 30ms, it's known
that any poll in between those times would report an on-state for that
arrow. However, considering this would involve adding multiple entries
per call (for times in the past) and how the update function can be
called from two separate threads, it may be introduce hard-to-debug edge
cases and add unnecessary complexity overall.~~
EDIT: Implemented
## Testing
~~-Verified the thread was inserting polls at the expected cadence
-Verified the thread is only created when the game's refresh rate is
below the threshold
-Verified the thread introduced no significant increase in CPU~~
- Verified the entries were being backfilled correctly on several
different refresh rate instances
- Verified the bug could no longer be reproduced
## 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.
## Description of change
In the real `libacio2.dll` implementation,
`ac_io_mdxf_get_control_status_buffer` returns the ring buffer entry at
`(head - index) mod size` but this function was using `(head + index)
mod size` instead. Basically, `index` is supposed to indicate how many
entries back, not forward. This was causing the polling history of each
player to be returned backwards. A few other things were updated to
bring the function's behavior closer to the real implementation:
1. Number of ring buffer entries per player were increased to 16 (this
is the size of them in the real implementation)
2. `ac_io_mdxf_get_control_status_buffer` now returns the current head
of the ring buffer (instead of a success/failure boolean), which is what
`arkmdxp4.dll` expects.
## Testing
I played a few songs to make sure nothing was broken. I also attached a
debugger and verified the ring buffer entries are *actually* now being
returned in reverse chronological order as intended.
## Description of change
In its current state, the emulated `libacio2.dll` functions
`ac_io_mdxf_get_control_status_buffer` and
`ac_io_mdxf_update_control_status_buffer` only operate using a single
head pointer (`COUNTER`) for the ring buffers of
`[panel_state,timestamp]` (simplified for brevity here) polls for both
players, when they should be maintaining a separate head pointer for
each ring buffer. On every frame, `arkmdxp4.dll` makes calls to
`ac_io_mdxf_update_control_status_buffer`, which [in this emulated
version] advances the head pointer, creates a new entry for the latest
panel state info along with the current time, and stores it at the head
of the ring buffer. This function is called for each player: After the
call for 1P, the head pointer is advanced by 1, so by the time it's
called for 2P, the head pointer had already been advanced by 1, meaning
the new entry for 2P's panel state ring buffer is written two entries
ahead of where the last entry for 2P was written. This is an example of
how the entries were written for each ring buffer:
```
Frame 1:
1P[0] = t0
2P[1] = t0
Frame 2:
1P[2] = t1
2P[3] = t1
Frame 3:
1P[4] = t2
2P[5] = t2
Frame 4:
1P[6] = t3
2P[0] = t3
...
Frame 7:
1P[5] = t6
2P[6] = t6
Frame 8:
1P[0] = t7
2P[1] = t7
```
This is an issue because `arkmdxp4.dll` calls
`ac_io_mdxf_get_control_status_buffer` on every frame to load the last 7
polls for each player, which depends on the ring buffer entries being in
reverse chronological order to properly determine when an arrow is
pressed and when it was released, but this is what it sees from the ring
buffers after 8 frames:
```
1P: t7 -> t3 -> t6 -> t2 -> t5 -> t1 -> t4
2P: t7 -> t3 -> t6 -> t2 -> t5 -> t1 -> t4
```
In this case, `arkmdxp4.dll` assigns step times based on polls that are
out of order, resulting in unpredictable timestamp assignment to each
step, with the issue compounding at lower framerates since the timestamp
deltas between each poll will be greater (see side note). After
implementing two separate head pointers for each ring buffer, those same
two arrays become:
```
1P: t7 -> t6 -> t5 -> t4 -> t3 -> t2 -> t1
2P: t7 -> t6 -> t5 -> t4 -> t3 -> t2 -> t1
```
This is how `arkmdxp4.dll` expects this data to be structured, so timing
should become more consistent after this change.
Side note: in this particular p4io implementation, the only place the
polls are updated is once per frame on the calls to
`ac_io_mdxf_update_control_status_buffer`, meaning the polling rate of
the controller used is locked to the framerate of the game. There should
be another thread not tied to the main one that listens to input from
the OS and updates these ring buffers on a much faster cadence.
## Testing
I played a few songs to make sure nothing was broken. I also attached a
debugger and verified the ring buffer entries are now being returned in
reverse chronological order as intended.
## Link to GitHub Issue, if one exists
n/a
## Description of change
When an exception is caught during ACIO hook init, print a special
message to suggest the user to disable RTSS and MSI Afterburner, since
they are known to cause issues.
## Testing
Tried with RTSS enabled with High detection and with it disabled. Also
tried to crash the game a different way and check that the message is
not printed and the callstack is shown propeerly.
## Link to GitHub Issue, if one exists
Fixes#295
## Description of change
Add missing `Start` and `10KEY` lights output, as see in the test menu.
## Compiling
👍
## Testing
Seems fine in museca test mode.
bicarus