Windowsのメッセージループを、ゲームのメインループとして使いたい場合、GetMessage()関数を使うとメッセージが来るまでの間、処理が止まってしまうので、PeekMessage()関数を使う。
例：
while (1) {
if (PeekMessage (&msg, NULL, 0, 0, PM_NOREMOVE)) {
if (GetMessage (&msg, NULL, 0, 0) <= 0) break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else {
/* ゲームの処理 */
}
}
return msg.wParam ;
追記 :
この例は、色んなサイトに書いてあったのを寄せ集めて作ったが、処理に無駄があるかもしれない。
PeekMessage()関数とGetMessage()関数の両方を使っている理由は、関数の実行に失敗した場合を考慮してるからだと思う。
GetMessage()関数は、どうやら実行に失敗すると-1を返すらしいので。
マルチスレッドにはしないの？
そういえば研究室の彼もマルチスレッドは
あまり好きじゃなかったなあ。
と死んだ人みたいに扱ってみるてすと。
前に作ったゲームではマルチスレッドにしてたんだけど、たぶんその彼に言われてシングルスレッドに挑戦してみることにしたよ。
なんか試されてるような気がして（笑）。
僕は別にゲームプログラマーになるつもりはないから、１つの方法を確立するより、色んな方法試してみて、それで経験積める方が嬉しいからさ。
PeekMessageはメッセージをとりださないんじゃなかったけ？そういえば。
だから、もういっかいGetＭessageをよんでるんじゃない？
第４引数までは、GetMessage関数と同じでしょ？
実際、PeekMessage関数しか使ってないサンプルコードも、希にだけどあったから、工夫すればGetMessageの代用としても使えるんだと思う。
Peekって頂点のってことだから
FIFOの一番上のメッセージを参照するっていう
APIで、
No Removeのオプションがついていれば
その頂点のデータを消さないってことでしょ。
このオプションがなければ
データはメッセージループから消されるわけだから
GetMessageと同じになるってこと。
うん、そう思うんだ。
だから、PM_NOREMOVEをPM_REMOVEに変えたら、GetMessageは必要なくなるよね。
そしたら上のソースも、もうちょっと簡単になるんじゃないかなって思うのさ。