mirror of
https://github.com/spice2x/spice2x.github.io.git
synced 2026-08-02 14:50:41 -07:00
cchike
8545f1cbdc
## 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