Handle QueryPerformanceCounter failure with fallback#694
Handle QueryPerformanceCounter failure with fallback#694themuffinator wants to merge 1 commit intomasterfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Sys_Printf("QueryPerformanceCounter failed; falling back to timeGetTime (low resolution).\n"); | ||
| qpc_available = false; | ||
| fallback_base = timeGetTime(); | ||
| } | ||
|
|
||
| DWORD current = timeGetTime(); | ||
| unsigned msec = current - fallback_base; | ||
| if (msec < last_msec) |
There was a problem hiding this comment.
When QueryPerformanceCounter fails, fallback_base is set to the current timeGetTime() while last_msec still holds the absolute QPC-derived milliseconds since boot. The very next call computes msec = current - fallback_base (near zero) and clamps it to last_msec, but fallback_base is not offset by that value. The result is that Sys_Milliseconds returns a constant last_msec until timeGetTime() has advanced by at least that many milliseconds—potentially freezing the timer for many minutes or hours after the fallback is triggered. Consider seeding fallback_base so timeGetTime() continues from last_msec immediately.
Useful? React with 👍 / 👎.
1 participant
Summary
Testing
Codex Task