cchike
6f58d9ab68
## 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.
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.