システム コンポーネント (IE、レンダリング、物理、ロジック、入力、スクリプトなど) を異なるスレッドに分割するゲーム アーキテクチャを作成する場合、リアルタイム通信が必要な場合はどのように処理しますか?
たとえば、スクリプトで画面にボックスを描画する場合、レンダリング コンポーネントが「FrameDrawn」イベントを発行して、各フレーム描画の最後にボックスが画面の上に描画されるようにするのが理想的です。 . スクリプティング コンポーネントとレンダリング コンポーネントが互いに異なるスレッド上にある場合、これはどのように可能になるのでしょうか?
通常、レンダリングスレッドは、画面に物を描画する唯一のスレッドです。ただし、スレッドは通信できるため、スクリプトスレッドは、レンダリングスレッドに「ねえ、次のフレームにボックスを描画したい」と伝えることができます。
プロジェクトがスレッド通信を処理する方法は、2つの方法のいずれかです。動的に編集されるもの（オブジェクトのリスト、移動する車両など）の場合、データが変更されるときにデータをロックするミューテックスを作成します。レンダラーがそれを描画したいが、更新スレッドがそのオブジェクトを削除している場合、レンダラーは待機する必要があります。uiのような他のものについては、uiスレッドによって書き込まれ、レンダラーによって読み取られるグローバルフラグがあるだけなので、ミューテックスは必要ありません。
ほとんどのゲームには、大量のデータと、必要に応じてそのデータのサブセットを参照する複数のスレッドがあります。スレッド間の通信が明示的であることはめったになく、より一般的には暗黙的であり、1 つのスレッドによって引き起こされたデータの変更を通じて行われ、後で 2 番目のスレッドによって通知されます。変更はミューテックス、セマフォ、またはその他の低レベルの同期プリミティブによって保護されます。
描画の例では、スクリプト スレッドが GUI コンポーネントの一部のデータを変更し、レンダリング スレッドが次に GUI をレンダリングするときに、その新しいデータを確認し、それに応じてボックスを描画します。
ただし、ほとんどのゲーム開発者は、あなたの例のようにスレッド化しないことに注意してください。これは、大量のデータを共有し、正確さのために低レベルのロックに依存しているモデルで効果的にスレッド化することが難しいためです。理想的には、より多くのゲーム開発者が、より少ないデータを共有するモデルに移行することですが、ソフト リアルタイム プレゼンテーションの応答要件のために、それは困難です。
あなたが求めていることは実際には不可能です。そのため、一般的なルールはUIスレッドを1つだけにすることです。別のスレッドが画面に何かを表示したい場合は、UIスレッドにメッセージを送信して、レンダリング時にメッセージを表示する必要があります。