ゲームでは、世界のタイルを正方形のセルに表示する GridPane があります。プレーヤーは、キーボードを使用して、列\行で表示されているものを移動できます。私が考えたアプローチは次のとおりです。 GridPane を使用して、表示されているタイルをプログラムで変更し、プレイヤー入力の x ステップだけすべてを移動します。GridPane を ScrollPane にラップし、ScrollPane のスクロールをキーボード入力に結び付けます。
私の質問は、視界から外れているが同じマップ上にあるものが常に読み込まれていると仮定すると、各アプローチの効率的な長所と短所は何ですか? 最も具体的には、GridPane を ScrollPane にラップすると、画像が画面外にある場合でも画像が読み込まれたままになり、パフォーマンスに影響を与えるのではないかと考えています。また、私が考えたことのない 3 番目のより効率的な方法があるかどうかも疑問に思っています。
私はJavaFX8を使用しています
一般的方法
非常に大きな世界に限られたビューポートを提供する最も効率的な方法は、世界にタイル ベースのモデルを使用し、グラフィック リソースのみを読み込み、現在のビューポートに必要なタイルを表示することです。
サンプル キャンバス ベースの実装
これを実現する方法の概要は、 eppleton ブログ投稿で説明されている eppleton JavaFX タイル エンジンです。その特定の実装では、シーン グラフ ノード指向のアプローチではなく 、 Canvas直接描画ベースのアプローチを使用します。
サンプル シーン グラフ ノード ベースの実装
シーン グラフ ベースのアプローチは、仮想コントロールと呼ばれるものに依存しています。コントロールは、基礎となるデータ モデルへのウィンドウであるセルを提供します。JavaFX ListViewおよびTableViewは、仮想化されたコントロールの例です。これらの仮想コントロールは、何千もの項目を含むデータ構造を裏付けることができますが、現在表示されている数十項目のビジュアル項目のみが実際に画面に表示されます。コントロールがスクロールされるか、その基になるデータ構造が変更されると、コールバックが呼び出されて、表示されている各セルのグラフィカル ノードが更新されます。
グリッドのシーン グラフ ベースの仮想コントロールの例は、 ControlsFX GridViewです。キャンバス ベースの eppleton タイル エンジンとは異なり、ControlsFX GridView は、ゲーム エンジンのコア タイル ベースのレンダラーとして特別に構築および最適化されていないため、GridView をそのような方法で使用する場合は、大幅に追加する必要があります。 GridView のフォークまたは拡張により多くの機能を追加して、完全なゲームプレイ タイル エンジンと同等の機能を実現します。
既存の仕様とツールセット
TMXなどのタイル マップ形式の既存の仕様と、そのような形式に準拠するファイルを作成するための既存のエディターがあることに注意してください。タイルマップの使用は、リアルタイム ゲームとターン ベース ゲームの両方に適しており、ゲームのジャンル以外でも役立つ場合がありますが、従来の使用方法はビデオ ゲームの作成です。
追加の質問への回答
GridView の意味が最適化されていない場合でも、詳しく説明していただけますか?
あなたの主なアプリケーションは、タイル ベースのゲーム エンジンを作成しているようです。このようなエンジンは、通常、タイル マップ データ、タイル イメージ データの読み取り、アニメーション化されたスプライトのタイルへのオーバーレイなどのサポートを提供します。これらの種類の機能は ControlsFX GridView には含まれていません。ファイルディレクトリのイメージ)。要点は、GridView がパフォーマンスに関して最適化されていないということではありません (最適化されているため)。要点は、GridView は、特定のアプリケーション (タイル ベースのゲーム) に必要なすぐに使える機能の最適なセットを提供しないということです。 ）。
私の場合、エンティティはピクセルごとではなくタイルごとに移動することを忘れていました
これにより、個別の座標にあるタイルについてのみ考慮する必要があり、現在の位置のオフセットやタイル間のレンダリングなしでエンティティを正確なタイル座標にすることができるため、実装が簡単になります。ただし、常に世界全体をレンダリングするのではなく、現在見えるものだけをレンダリングする仮想化されたビューポートを世界のみに使用するアプローチ全体が実際に変わるわけではありません。
このすべてを 1 年前に知っていたら、開発において非常に異なるルートをたどっていたでしょう。
調査をすることで得をすることもあれば、間違って学ぶこともあります :-) ジョン・カーマックが当時知っていたなら、元の Doom を別の方法で書いていただろうと確信しています。そのようなことをあまり心配させません。自分が今どこにいるのかを評価し、そこから進んでください。