## Link to GitHub Issue, if one exists
#452
## Description of change
* Split the MDXF I/O option into three: auto, thread, and backfill.
`auto` is the same as what `thread` used to be before this change (based
on I/O poll rate), but `thread` now always forces thread poll mode.
`auto` is the default (behavior wise, same as before)
* For the poll rate measurement, start polling after 20s mark to avoid
frame drops during game boot
* Minor code clean up
## Testing
manual test in windowed + full screen
## 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
## 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
bicarus-dev