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
This is the GitHub page for code development. If you just want to download the latest spice2x EXE, visit the homepage instead:
🌶️🌶️ https://spice2x.github.io/ 🌶️🌶️
If you have problems, read Known Issues (FAQ) wiki page first, most of your questions are already answered.
spice2x
Overview
spice2x is a continuation of SpiceTools project. Original development of SpiceTools has stalled in 2022; spice2x is led by a new group of developers.
spice2x team does not provide any tools to circumvent software copy protection, nor distribute any copyright-protected game data.
How do I set up game data & start playing?
By policy,
- we do NOT provide links on where to acquire game data
- we do NOT provide tools or instructions on decrypting data
- we do NOT provide guides on setting up & basic troubleshooting
please do not ask for these, as it will never happen here.
Submitting to the Issue Tracker
Please file bugs if you find them! If you just complain about something in Discord servers, we can't see them, so they'll never be fixed.
Rules for filing a new issue or adding comments to existing issues in the tracker:
- Low effort submissions will be simply deleted, and repeated attempts will get you banned.
- Check the known issues page first before reporting a new issue. If you have some new information or workarounds for a known issue, you can file a documentation bug as well.
- Use the search function and see if there is an existing issue.
- This is not the place to obtain a guide or receive basic troubleshooting.
- Don't file a bug demanding game XYZ to be supported.
- Do not upload game data - any part of it, XML files included!
- Do not mention or link to external websites that distribute game data!
- Do not link to external websites that provide guides on how to run games!
New GitHub accounts are prevented from creating new issues to prevent spam. Maintainers of this project reserve the right to close or delete any issues that violate the rules above, or any low effort issues. If you ask for very basic troubleshooting help with setting up a game, we'll just delete them without warning.
Contributing
We encourage the community to submit bugs and suggestions via the issue tracker, and to contribute code changes by opening pull requests
If you want to resolve any reported (or not reported) bugs, implement features, add support for new games, or fix a known issue - feel free to reach out via the Issue tracker or by opening a Pull Request. All submitted code is assumed to be GPLv3 compliant.
We explicitly do NOT have a Discord server for dicussions - we try to do everything out in the open on this GitHub repo. That being said we haven't opened a Discussions tab here because we know it's going to be immediately filled with support requests.
Please see CONTRIBUTING page for a full list of guidelines when submitting code.
Additional information
Please read README.md inside src/spice2x.