OpenGLは全く新しいので、愚かな質問の場合は申し訳ありません。また、違いがあるのかどうかは分かりませんが、私はOpenGL ES 1.1を使用しています。OpenGL ES 2D - zオーダー、デプスバッファと描画の順番
現在、私はパフォーマンスの方が理にかなっていると読んだように、質感の順にスプライトを描画しています。しかし、今私はそれが適切なアプローチであるかどうか疑問に思っています。なぜなら、私は特定のスプライトがテクスチャに関係なく他のものの前にある必要があるからです。
私の知る限り、zオーダーのオプションは、デプスバッファを有効にしてそれを使用するか、スプライトがz値のオーダーで描画されるように描画順序を切り替えることです。
私は、深さバッファがパフォーマンスヒットになる可能性があることを読んだが、順番を変更することになります。私はどちらをすべきですか？
短い答えは、スプライトを並べ替えることです。
実際に2dベースのものを作成しているようですが、zバッファは非常に便利なツールですが、ハードウェアでサポートされていない場合は、実際には交差している可能性のある3Dオブジェクトを使用していないので、それは私にはあまり意味がありません。
さらに、部分的に透明なスプライト、つまりアルファ値が0または255（浮動小数点を使用する場合は0.0または1.0）のピクセルを持つ場合は、とにかくソートする必要があります。
「スプライト」を変更したときにパフォーマンスが低下するのは、サーフェスを切り替えるときにのみ発生し、まれにしか発生しないと考えています。この問題を軽減する1つの方法は、できるだけ多くの異なるスプライトを1つのイメージに配置し、グリッド上に配置し、スプライトとしてサーフェスの小さな部分を使用することです。
OpenGLは主に3D向けです（ES ）、ハードウェアデプスバッファをサポートしていないハードウェアは、ハードウェアアクセラレーションされたOpenGL ESをサポートしていないと思いますか？ –
私はiOSデバイスがそれをサポートしていないとは思わない（私は間違っていると思うかもしれない）。タイルベースのゲームなので、すべてのタイルは単一の画像タイルマップになります。これにより、順序問題のレンダリングは影響を与えません。 – Dan2552
正確には、作業中の画像をメモリ上で変更した場合にのみ、サーフェスの切り替え時に適用される速度の問題が適用されます。これは実際にビデオメモリを使い切ったときの問題です。本当の問題は、OpenGLがスペースを使い果たし、ビデオメモリからイメージをアンロードして、新しいイメージをロードしなければならないときです。 –
すべての合理的なOpenGLアプリケーションは深度バッファ（単なる「2Dテクスチャを描く」という例を除いて）を使用しているので、実際にはこの「パフォーマンスヒット」文を少し変更しなければならないと思います。 –
1つの選択肢は、問題全体をサイドステップし、Cocos2Dのようなフレームワークを使用することです。 OpenGLの負担がかかります。スプライトのzオーダリングをサポートし、CCSpriteBatchNodeを使用してスプライトでテクスチャを再利用することができます。 –
私は他の何よりも学習のためにゲームをもっとやっているので、最初から始めて決めました – Dan2552