2f538fe2e469c92edaf8c87cbff0e6f129ace8dd
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  cchikeandGitHub
|
6776b08bce |
MDX: Refactored p4io.cpp (#467)
## Link to GitHub Issue, if one exists #452 ## Description of change Added `Sleep(4)` call to regulate how fast the `device_io` function will call `getState` for each button. The panel buttons were commented out because those are handled by the MDXF Control Status Buffer functions anyways, so the work was redundant. It's also why the timing precision from this function doesn't matter, so it can afford a longer sleep ## Testing - Verified IO still functions properly - Verified decrease in overall CPU usage |
||
|
cchikeandGitHub
|
42d8bbc92f |
MDX: Exposed P4IO Buffer Filling Mode to Spicecfg (#463)
## 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 |
||
|
cchikeandGitHub
|
f113eb4f52 |
MDX: Merged Thread and Backfill Implementations (P4IO Timing Fix) (#460)
## 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 |
||
|
cchikeandGitHub
|
e618a05b08 |
MDX: Updated Ring Buffer Backfill Implementation (P4IO Timing Fix) (#456)
## 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 |
||
|
cchikeandGitHub
|
8545f1cbdc |
MDX: Added Backfill Logic For Ring Buffer Health (P4IO Timing Fix) (#450)
## 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 |
||
|
cchikeandGitHub
|
6f58d9ab68 |
MDX: Decoupled Input Polling Rate From Game Refresh Rate (P4IO Timing Fix) (#446)
## 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. |
||
|
cchikeandGitHub
|
dc7d8515d3 |
MDX: Fixed Ring Buffer Traversal Direction (P4IO Timing Fix) (#441)
## 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. |
||
|
cchikeandGitHub
|
e5808257ca |
MDX: Fixed Status Control Buffer Emulators (P4IO Timing Fix) (#439)
## 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. |