ゲームラグ白書 › L2 クライアントのOS・端末
タイマー分解能 Timer resolution (Windows 15.6ms)
原因ID co-timer · 主担当 ゲーム開発チーム・クライアント開発
図と実験のあるメインページでこのカードを開く →
Windowsのデフォルトのタイマーは15.6ms単位なので、「1msだけ待つ」が実際には次のタイマー周期まで、長いと15.6msまで延びます。
なぜ フレームレート制限・パケット送信をSleep（短い待機）で実装 → すると OSが15.6ms単位でしか起こしてくれない → 画面では フレーム間隔と入力の送信間隔がばらつく
- 症状
- カクつき
- 要因
- ジッター
- 誰に起きるか
- 自分だけ
- いつ
- 常に
- 担当
- 主担当 ゲーム開発チーム・クライアント開発
- ゲーム開発チームの対応
- 高分解能タイマーの使用、Sleepで待つ代わりにイベント・V-Syncを基準にしたペーシング。
- 数値の目安
- 15.6ms単位では16.7msの間隔に合わせられず、フレーム間隔が15.6msと31.2msの間を行き来します。
- グラフでは
- 最初から常に高い · フレーム間隔の分布
- 確認箇所
- PresentMonのMsBetweenPresents（フレーム間隔）の分布と、powercfg /energyレポートの「Platform Timer Resolution」項目（タイマー分解能を変更したプロセス）を確認
- 該当する場合
- フレーム間隔が15.6msと31.2msのように15.6msの倍数に集中し、ゲームがより高いタイマー分解能を要求していない
- 該当しない場合
- 間隔が均等に散らばっているなら、タイマーよりも「バックグラウンドプロセスによるCPU占有」やフレーム負荷側
- 確認手段
- ユーザー側の環境で確認
- もっと詳しく
- 以前のWindowsでは、1つのプログラムがタイマーを1msに変更すると、すべてのプログラムに適用されていました。そのため「ブラウザを開いておくとゲームが滑らかになる」という話もありました。Windows 10 バージョン2004からは要求したプログラムにだけ適用され、Windows 11では、最小化されたり完全に隠れていて音も出していないウィンドウの要求を適用しないことがあります。
出典
- _WDF_TIMER_CONFIG (wdftimer.h) Microsoft
通常のタイマーの精度はシステムクロックのティック間隔であるデフォルト15.6ms、高分解能タイマーは1ms - timeBeginPeriod function (timeapi.h) Microsoft
Windows 10 バージョン2004より前はグローバル設定、それ以降は要求したプロセスにだけ適用。Windows 11は隠れたり最小化されたりしたウィンドウのプロセスに高い分解能を保証しない - CreateWaitableTimerExW function (synchapi.h) Microsoft
高分解能の待機タイマーのフラグCREATE_WAITABLE_TIMER_HIGH_RESOLUTION - PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents：今回のPresent()呼び出しと前回の呼び出しの間の時間（ms） - Results for the Idle Energy Efficiency Assessment Microsoft
デフォルトのシステムタイマー分解能は15.6ms。エネルギーレポートの「Platform Timer Resolution」項目で、タイマー分解能を変更したプロセスを見つける - Powercfg command-line options Microsoft
powercfg /energy：システムを分析してエネルギーレポート（HTML）を作成
あわせて読みたい原因
同じ層：L2 クライアントのOS・端末
同じ症状（カクつき）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る