古の技術でゲームプログラミング 第6回
ゲームのメインループはどうするんだ？というお話。
メッセージループにおけるGetMessageがゲームに向いてないよねっていうことを以前書きましたが、じゃあPeekMessageを使ってやるのか？っていうとそれも地味に気持ち悪いので今回はマルチスレッドで解決していきます。
スレッドというのはいわゆる並行処理をするための実行単位のことです。
WinMainから始まってGetMessageを使ったメッセージループでぐるぐるするヤツはプライマリスレッド。
もう一つスレッドを作ってそっちでゲーム関連の処理を行いながら独自のループでぐるぐるするつくりとします。
スレッド間ではメモリ空間は共有されるためデータのやり取りにおいては直接メモリを見ることができちゃいます。
しかしデータ更新の途中でつじつまのあっていないデータを参照してしまうなどの事故を防ぐために排他制御ってのが必要になったりします。
この点がマルチスレッドにした場合のデメリットになるかと思います。
ゲームにおいてプライマリスレッドとゲーム処理用スレッドの間でやり取りするデータっていうのは基本的に画面に表示する画像データのみなのでそこだけうまくやってあげれば問題ないはずです。
で、この点についても先人の知恵によりダブルバッファリングってので出来ちゃうんじゃないかという目論見です。
やばい、メインループの話を書こうとしてたらスレッドやら排他制御やらいろいろ広げてしまった…。
ってことで本記事ではとりあえずプライマリスレッドのメッセージループの形と、スレッドを用いたときのイメージ図だけ載せて終わろう。
プライマリスレッドのメッセージループ：
MSG msg;
// メイン メッセージ ループ
while (GetMessage(&msg, nullptr, 0, 0))
{
DispatchMessage(&msg);
}
return (int)msg.wParam;
テンプレからいらんものを削ってスリム化してます。
まじでこんだけ。もうこれでいいでしょう。
PeekMessageとか使ってもめんどいだけだし。
DispatchMessageしたあとの動きとしては、WM_PAINTでの画面更新だけはいずれ書いたほうがいいかなと思ってます。
あとはこれがマルチスレッドにしたときのイメージ。
WinMainから始まるプライマリスレッド(左側)は、ゲームスレッドの生成とウインドウのWM_PAINTでやる画面更新ができれば基本はおっけー。
ゲームスレッド側はFPSの制御、入力チェック、描画処理と、そもそものゲームの処理本体ができればよさそうだね。
※この記事を書いてる時点でゲーム処理本体以外はもう出来てるのでまずはオセロでも作ってみようかと思ってたりもする
おしまい。
