私はシューティング ゲームに取り組んでおり、画面をエンティティ (弾丸、Mob など) であふれさせることを計画しています。画面上のすべてを更新するためにグローバル タイマーを試してみましたが、思い通りに画面をあふれさせると、深刻な fps の低下が発生しました。
ですから、私には 2 つの選択肢があると考えています。個々のエンティティにタイマー スレッドを与えるか、レベルをチャンクに分けて、各チャンクに独自のタイマーを与えることができます。
最初のシナリオである独自のタイマー スレッドを持つエンティティでは、何百ものエンティティが作成され、それぞれ独自のスレッドでタイマーが実行されます。
セクション オプションでは、複数のエンティティを一度に更新するタイマーを使用してマップの複数のセクションを作成し、エンティティがあるセクションから別のセクションに移動するタイミングを検出します。
私はメモリ効率を念頭に置いたプログラミングに慣れていないので、どの方法を使用するのが良いでしょうか?
私は似たようなことを実験していましたが、明確な答えはありません。しかし、Java-Gaming.org から得たフィードバックの中には、役立つものや興味深いものがあるかもしれません。
私が試したのはこれでした: 各エンティティには独自のスレッドがあり、衝突は画面の非常に詳細なマップ (基本的には画面の 2 番目のバージョン) を介して処理されます。次に、画面の表示を処理する別のスレッドがあります。
500 以上のエンティティがアニメーション化された、これの「初期」バージョンがオンラインで公開されています: http://hexara.com/pond.html
後のバージョンでは、より精巧な形状と境界線 (エンティティを死に至らしめたりエッジでフリーズさせるのではなく) と、互いに跳ね返る衝突や重力などの衝突ロジックを使用しています。また、「ホタル」の点滅などのスプライトの側面で遊んでいました。Web ページで「アクター」について言及していますが、コードは厳密にはそうではありません。
java-gaming.org の何人かの人々は、非常に多くのスレッドを持つことは効率的ではないと強く考えていました。彼らからは興味深いフィードバックがたくさんありました。まだ時間がありません。 http://www.java-gaming.org/topics/multi-threading-and-collision-detection/25967/view.html
彼らは、ハイパースレッディングやアクタの acca フレームワークなどについて話し合っていました。
ScheduledExecutorServiceを試すことができます。
これは、Java 高レベル同時実行 APIの一部です。いくつのスレッドが存在する必要があるかを決定することができます (毎回新しいスレッドを作成するオーバーヘッドを回避するために、さまざまなタスクにスレッドを再利用するため、常に新しいスレッドを作成するよりもはるかに効率的であることが期待されます)、またはキャッシュされたスレッド プールを使用できます。 （必要な数のスレッドを作成しますが、スレッドが終了すると、それを再利用して新しいタスクを実行します）。
この API のもう 1 つの利点は、Runnables を実行できるだけでなく、Callables も使用できることです。これにより、将来使用する値が返される可能性があります (したがって、異なるスレッドで計算を実行し、各スレッドの結果を使用して、最終結果）。