[Feature] Expand the TimerInterface to reduce the chances of missing splits

[kitlith]

Currently, the interface consists of the current gametime, a gametime -> seconds conversion factor, and an Action. The Action is encoded using an enum with states for splitting, pausing, resuming, (re)starting, etc.

Recently, I've written an autosplitter that uses this interface, and I noticed that sometimes it just fails to notice a split (EDIT: specifically when working with Portal. I have not tested with Portal 2). I've traced this to splitting occurring in-between loading and resuming, and can only assume that the split happens and then almost immediately afterwards the game resumes, so I miss the split event. This may simply be an issue of not polling often enough, but this is not entirely under my control.

I'd suggest making pause state a separate Boolean (or a single bit in the Action variable) so that the other actions (which are relatively infrequent) are easier to detect. Optionally, I'd suggest adding an additional gametime variable for 'time of action', in case the current gametime variable is updated before the action is detected. (this would also allow for detection of actions when the action type has not changed, e.g. two splits in a row, since there are no longer pause and resume events to help seperate them.)

[kitlith]

This would require modification of sar.asl and any other autosplitters using the interface. I am willing to contribute code to anything involved if this is deemed a worthwhile change.

[NeKzor]

After some deep investigations with simple profiling I could not replicate this without crazy settings like host_timescale 10 and a timer refresh rate of 30Hz. Timing results on my machine with default game settings were around 30-70ms between split and resume, tested with SteamPipe and SourceUnpack. If my math is correct this should be enough if you scan with 60Hz.

However I understand that pause and resume actions are kinda useless, and the timer refresh rate could always be capped. So I revisited the interface with some slight improvements based on your suggestion:

struct TimerInterface {
    char version[16];      // 0x00 "SAR_TIMER_001"
    ...
    unsigned int actionId; // 0x1C
} pubInterface;

Change	Description
actionId	Incremented on each action change.
version	Replaces start and end. This makes it extensible for future updates.
Fixed static offset	Avoids scanning all memory pages and ensures reading valid values.

Further changes for the autosplitter:

• Detect missed splits: actionId.Old != actionId.Current - 1
• Crash detection: Save time on process exit and restore it with -hijack

[kitlith]

Yeah, I'm still not entirely sure what the issue was/is myself. I should really re-investigate on my end, I bet it's that the refresh rate was failing to get high enough (or was dipping) -- because in that case, the timer is in need of much profiling and optimization :/