モニタのフレームレート（リフレッシュレート）は家庭用TVでも何種類かある。
日本ではNTSCという規格がメインで、59.94Hzである。
海外ではPALも多く、これは50Hzである。
PCのモニタは50〜120Hzくらいは普通に設定できるものがある。

ゲーム（に限らず画面の動くもの）を作る場合、動きをスムーズにするために表示の更新をモニタのフレームレートにあわせる。
ところが、何も考えずに「→を押したら1フレームに1ドット右に動く」のような作り方をすると、60Hzの環境と120Hzの環境で2倍も速度が違ってしまうことになる。
（携帯ゲーム機のようなフレームレート固定の環境なら問題にはならないのだが。）

そこで、この問題について考察する。
表示を更新する間隔をSYNC、画面の座標等を更新する間隔をLOOPと呼ぶとしよう。
SYNCは環境によって固定されていて、LOOPは好きに設定できる。
しかし、単純にSYNC=LOOPにすると上記の問題が起きる。
ところが、SYNC≠LOOPにすると、1SYNC中のLOOP数が一定でなくなり、一定速度で動いてるものが一瞬止まる/早く動くと言うことが起こり、カクカク動いて見える。

この問題を解決するために、単純に考えつくのは、SYNCに応じてLOOPでの処理を変えることだろう。
[実装1]
while(1)
{
    float time = GetLoopTime(); //前回の呼び出しからの経過時間を取得
    GameLoop(time);
    Draw();
    WaitVSync();
}
GameLoop(time)では、timeに応じて移動距離などを調整する。
これだとSYNCによってパッドの反応速度等は変わってしまうが、そこまで気づく人はいないと思われる。（いない…よね？）
通常時はこれで問題はないだろうと思う。
多少の処理落ちも吸収できる副作用もある。

この実装において、リプレイを再生する場合を考えてみる。
リプレイデータは、乱数の種と各フレームのtimeとパッドの入力とする。
リプレイの再生は次のような処理になる。
float t_replay=0;
float t_sync=0;
int i=0;
while(1)
{
    float time = GetLoopTime(); //前回の呼び出しからの経過時間を取得
    t_sync += time;
    while(t_replay<t_sync)
    {
        t_replay += replay[i].time;
        i++;
        if (i>=replay.len)
        {
            // リプレイ終了
        }
        SetPad(replay[i].pad);
        GameLoop(replay[i].time);
    }
    Draw();
    WaitVSync();
}

timeとreplay[i].timeが完全に一致してれば1SYNCに1LOOPが再生され、スムーズに見える。
しかし一致しなかった場合、1SYNC中に2LOOP再生されたり1LOOPも再生されなかったりして、カクついて見えることが予想される。

そこで回避策として、表示より十分早い固定レートでGameLoopを実行することも考えてみた
[実装2]
float t = 0;
while(1)
{
    float time = GetLoopTime(); //前回の呼び出しからの経過時間を取得
    t += time;
    while(t>LOOP_TIME)
    {
        t -= LOOP_TIME;
        GameLoop(LOOP_TIME);
    }
    Draw();
    WaitVSync();
}
ここでLOOP_TIMEをいくつにするか考察してみる。
家庭用TVゲームの場合は50/59.94/60Hzの何れかであると思ってよい。
これらの最小公倍数を取ってみると299700Hzとなり、明らかに非現実的である。
59.94はおおよそ60であるとして、50と60の最小公倍数の300Hzというのが現実的なところである。
しかし日本で一番多い59.94Hzについて妥協するのは得策とは思えない。
またCPU負荷の問題もある。

■実験
59.94Hzのモニタを使用し、オブジェクトを等速運動させながら、(1/LOOP_TIME)を50, 60, 70, 120, 140, 300の6段階で変更してみた。
（70,140は50Hzのモニタで60,120を再生したときを想定）
・ 50：×ガクガク
・ 60：△スムーズだが時々カクっとなる
・ 70：×ガクガク
・120：△時々カクっとなるが、60よりは違和感は小さい
・140：×50や70よりはスムーズだがカクカクする
・300：○時々カクついているはずだが、ほとんど分からない。
という結果になった。
70,140でカクカクするということは、50Hzのモニタで60,120で再生したときにカクカクするということである。
この手法をとるなら300以上にするべきであろう。

以上。

********************************************************************

実装1ではあたり判定などの処理を適当にやると、処理落ちしたときに敵の弾をすり抜けるとかいうことが起きる。
実装2のLOOP_TIME=300はCPUパワーがかなりあやしい。
実装1で毎フレーム時間を計るのをやめて、起動時にフレームレート取得してtime固定にするかな？

さて他のゲームはどうしてるんだろう…
動画は24fpsと30fps混合のときは最小公倍数の120fpsにするようだけど。

卒論/修論の季節ですね。