displayGrid1とdisplayGrid2の2つの配列のそれぞれに1200という番号のCCSpriteのプールがあります。壁や床を表示するときは、それらを表示または非表示にします。床にはさまざまなテクスチャがあり、z次数に依存しません。壁にもいくつかのテクスチャがあり、z次数に依存します。
移動時に約6〜7フレームを取得していますが、これはターンベースのアイソメトリックローグライクなので問題ありません。ただし、シミュレータにちらつきがないため、パフォーマンスに関連していると思われるわずかなちらつきも発生しています。
パフォーマンスを向上させたい。Zオーダーに依存しないフロアに配列CCSpriteBatchNodesを使用することを検討していますが、この配列の要素間でスプライトを頻繁に追加および削除するコストが懸念されます。これは必要だと思います。
パフォーマンスを改善する方法について誰かアドバイスしてもらえますか？
コメントで述べたように、個別にロードされた複数の小さなスプライトファイルを使用しているため、個々のスプライトの周囲に余分なピクセルデータを格納するために使用されるメモリが無駄になるため、パフォーマンスの問題が発生する可能性があります。OpenGLテクスチャのピクセルデータの各行には、パフォーマンス上の理由から、合計2の累乗のバイト数が必要です。iOSでのOpenGLESはこれを自動的に行うと思いますが、パフォーマンスに大きな打撃を与える可能性があります。スプライトを適切なサイズの単一のテクスチャにグループ化すると、レンダリングパフォーマンスに大きな恩恵をもたらす可能性があります。
Zwoptexのようなアプリを使用して、これらすべての小さなスプライトファイルをより大きくて管理しやすいスプライトシート/テクスチャアトラスにグループ化し、スプライトシート/テクスチャアトラスごとに1つのCCSpriteBatchNodeを利用できます。
Cocos2Dは、テクスチャアトラスを備えたスプライトシートを利用するための非常に優れたサポートを備えており、コードを個々のファイルの代わりにこれらを使用するように変換することで、わずかな労力で実行できます。テクスチャアトラスから個々のスプライトを作成するのは簡単です。ファイルからではなく、名前でスプライトを呼び出すだけです。
CCSpriteBatchNodesは、スプライトのスプライト呼び出しをグループ化します。これは、バッチ処理と呼ばれるプロセスです。これにより、オペレーティングシステムとOpenGLは、GPUへのラウンドトリップを少なくする必要があり、パフォーマンスが大幅に向上します。残念ながら、CCSpriteBatchNodesは、それらを支えるテクスチャのスプライトのみを描画できるように制限されています（スプライトシート/テクスチャアトラスを入力してください）。