さて、いつでもキーの状態を取得出来るようになったので、実際にちょっと組んでみましょうか。
こんな感じですかねぇ。
このプログラムには欠点があります。
それは、マシンの処理速度(描画速度)が速ければ速い程、キャラクタの移動速度も
上がってしまうという事です。つまり、処理速度の違うパソコンによってゲーム速度が変わって
しまうというのです(まぁフリップである程度抑えられますが・・・)。
というわけで、疑似タイマー処理(?)を紹介します。まぁ以前「
DirectDraw基礎 第5回」
でも書いたのですが、もうちょっと変更してみます(^^;
プログラムはこんな感じです(今回のサンプルコードと同じ)
さて、まずメインループの最初でWaitSet()関数を呼び出しています。これは自作関数なので
コードを見てもらえば解ると思いますが、グローバル変数wait_timeに、timeGetTime()関数を呼び出し、現在の時間をミリ秒(1秒=1000ミリ秒)で保存しておきます。
その後、メインループでいろいろな処理をし、最後にWait()関数が呼ばれています。これも自作関数です。
このWait()関数の内容は主にメッセージループなのですが、現在の時間(timeGetTime())が、最初に記憶しておいたwait_time+Wait()関数の引数msecよりも小さい間はひたすたメッセージループを回しています。
つまり、WaitSet()を呼び出した時間から、Wait()の引数msecミリ秒時間が経つまでWait()関数内で止まっている事になります。
Wait()の引数を1000にすれば、秒間1回更新、500で2回更新・・・。1000/nでn回更新となります。ただ、この方法にも欠点があるのですが、
それはWaitSet()を呼び出してから、いろいろな処理をし、Wait(DWORD msec);を呼ぶ場合、「いろいろな処理」の時間がWaitの引数「msec」より大きくなってしまうと、
Wait()関数内は、ほぼ素通り(1回はメッセージループの処理をやります)になり、いわゆる「もたつき」だとか「処理落ち」と言った現象になります。
普通、ゲームでは秒間30回更新(1ループ33msec)を目安にしたほうがいいですね。これより小さいと、動作がカクカクに見えてしまうし、大きいと、処理落ちする可能性が
大きくなります。まぁ場合によりますので、いろいろ試してみて下さい(^^;