cchike
e5808257ca
## 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.
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.