Recent SereneIO testing has focused on something more important than whether a button press reaches the game.
We also need to know when it happened.
Older input paths often record an event when the engine processes it. That is not always the same moment the player pressed the button. If an event waits for the next frame or polling cycle, the timestamp can describe when OutFox noticed it rather than when the device produced it.
For ordinary menu input, that difference may not matter much, but for gameplay timing, it does.
SereneIO is being built so that OutFox can keep track of where an input timestamp came from. Some backends provide their own event timing, while others rely on callbacks, polling or compatibility paths with less precise information.
Those routes can all remain useful, but they should not all be treated as though they provide the same evidence.
During testing, we found that some older input paths were still reaching the engine without enough information about how their timing had been captured. The inputs worked, but we could not use them to support stronger timing claims until that provenance was clear.
That does not mean those devices or drivers are being removed.
OutFox supports keyboards, game controllers, dance pads, MIDI equipment, arcade I/O and a wide range of older hardware. Some of those systems need compatibility routes, and keeping them working remains important.
The aim is to distinguish those routes honestly.
Where a backend provides a reliable timestamp, SereneIO can preserve and use it. Where the engine has to fall back to polling or older behaviour, that path can remain available without pretending it offers the same timing certainty.
This also gives us a clearer way to test specialist hardware. Rather than assuming every controller behaves alike, we can look at how each input was captured and decide whether that route is suitable for normal play, compatibility support or more demanding timing use.
For players, the result should remain simple, presses should arrive reliably, and judgement should reflect when they happened as closely as the hardware and operating system allow.
For us, the important part is knowing which input paths can support that claim, and which ones still need more work.