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

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

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

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

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

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

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

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

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

コンロにあたる仕組みをプログラムの世界ではスレッドと呼びます。

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

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

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

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

TRPGさん1号はUIがないので実はメインスレッドでの処理があまりありませんが、処理の流れなどの管理に使うと思います。

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