私はスレッド、SDL、およびグラフィックが一般的にどのように機能するかについては初めてです。私は LazyFoo の SDL チュートリアルをすべて見てきましたが、非常に役に立ちました。しかし、マルチスレッドに関する彼のチュートリアルでは、別のスレッドでビデオ関数を使用しないでください。そうしないと、問題が発生する可能性があるとコメントしています。グラフィックスとスレッドについてはまだ漠然としか理解していないので、どのように行うべきか興味があります。
私のプロジェクトの 1 つがシューティング ゲームであるため、すべてのグラフィックを表示する 1 つのスレッドを作成し、1 つのスレッドが船のすべてのプレイヤー入力を受け取り、別のスレッドが敵の AI を受け取るかどうかを考えていました。
これがどうあるべきかではない場合(間違っていると思います)、ユーザー入力と敵AIをスレッドでグラフィックスを実装する方法について誰かアドバイスがありますか?
Lazyfoo のチュートリアルについては、次のリンクを参照してください: http://lazyfoo.net/SDL_tutorials/
始めたばかりのときは、責任に基づいてスレッドを分離する方がはるかに簡単です。これにアプローチするより「正しい」方法は、スケーラビリティの向上につながりますが、スレッド プールを使用することです。SDL 用のものを含む、事前に構築されたスレッド プール ソリューションがあります。
レンダリングに OpenGL や DirectX を使用している場合、これらの API の呼び出しが多くのオーバーヘッドを生成するとは思えないため、少なくともゲーム ループの (必然的に) シーケンシャルな部分をメイン スレッドで実行できます: 入力の取得、更新世界モデル (ai calcs の結果の使用を含む)、レンダリング。次に、AI、ネットワークスレッドを並行して実行できます。したがって、別のレンダリング スレッドについて心配する必要はありません。これには例外が 1 つあります。ソフトウェアで計算量の多い (レイキャスティング/レイトレーシングが多いという意味です) レンダリングを行っている場合は、並列スレッドで「ロジック」のレンダリングを何らかの方法で実行し、フレーム バッファに書き込む方がよいでしょう。次に、メインスレッドで上記のシーケンスを実行し、準備されたフレームバッファーを例を使用してブリットします。GDI。
レンダリングに関しては、はい、単一のスレッド（メインスレッド）のみからのAFAIKレンダリングは、一般的に、たとえば. OpenGL では問題ありません。繰り返しになりますが、これは主要なプラットフォームではもはや問題ではありません。また、GDI と DirectX のどちらが個別に同じ問題を抱えているかもわかりません。
一般的に、レンダリングスレッドをUI/AIスレッドから分離することは良い考えだと思います。コードをより理解しやすくするのに役立ちます。ソースコードにはたくさんのゲームがありますので、どうやって作ったのか見てみませんか？