へーそう。ゲームスレッドの連携を考える。

Windowsはメッセージ駆動型と呼ばれる仕組みになっていて。
えーっと、いまは違うのかな?はてな。

例えばボタンが押されたり、ウインドウが閉じられたりするとWindowプロシージャというハンドラ(プログラムと呼び変えてください)が呼び出される。

Windowプロシージャには「何が起きたよ」という情報が渡されるので、プログラムはそれを分岐材料にして処理を行う。
上のボタンが押されたらキャラクターの座標を上に移動させたり、下のボタンが押されたらキャラクターの座標を下に移動させたり。
ここで渡される「何が起きたよ」という情報をメッセージと呼ぶのでメッセージ駆動型と呼ばれるわけで。たぶん。
 
一見するとこれでもゲームは作れそうなのですが、実は問題がある。
Windowプロシージャはメッセージを1件ずつ処理するので、何か重い処理を行っていると次以降のメッセージを待たせてしまう。

時間が長くかかる処理をおこなってしまうと、ゲームの進行そのものが止まってしまうことに。

例えば。
お腹が空いたのでパスタを作ろうと考えました。

・コンロが1つだとパスタを茹でるとソースを作る時間をずらさなければならず
・コンロが2つあったなら、並行して火をかけ同時に調理をすすめられる
・電子レンジはブレーカーが落ちるので使えない。くそう貧乏が憎い
・でもコンロが2つなら、コンロが1つの時に比べ調理完了までのお時間は半分!

ここで例にあげたコンロに相当するものが、標準ではWindowプロシージャの分しかありませんが、じぶんでコンロを増設することができて。

コンロを増やして個別の調理を進めると、ゴハンが時間比でゴージャスになるよ。
やったね。
 
お話をゲームに戻すと。(どこいしょー)
コンロにあたる仕組みを増設すれば、裏で次の画面を読み込んだり、アニメーションを処理したり、キー入力も待たせることなく処理することができる。

コンロにあたる仕組みをプログラムの世界ではスレッドと呼ぶ。(ちょっと極端な例だけれど)

今回の解決案はこんなイメージかな。
実行スレッドの関係の検討
Windowプロシージャのメッセージを一度「記憶領域」にため込んで、それを別のスレッドから60分の1秒ごとに確認させてみる。

「記憶領域」を仲介させることで、Windowプロシージャは1メッセージの手続きをすぐに終えられるため、次のメッセージを待たせる必要がなくなる感じ。

ゲームなどの用いられる描画更新の単位は1秒間に60回、60フレームが多いためこの値。
これはブラウン管時代にあった走査線の1巡する時間に合わせた考え方。

このへんはだんだん変わってきている気もするけれど、なんとなく残っている文化のような気も。
(VSYNCというやつだね。HSYNCで読み取りアドレスをいじってラスタースクロールさせちゃえ)

TRPGさん1号はUIがないので、実はメインスレッドでの処理があまりなく。
んー。処理の流れなどの管理に使おうかな?

補足:タイトルの「へーそう」は「並走」と引っかけていますが、はずかしいので絶対に口にしないよ。内緒ね。