アンドロイドゲーム、キャンバス、またはOpenGL？

Question

私はアンドロイド用のゲームを書くことになっています。私はキャンバスまたは描画のためのOpenGLのどちらかを選択する必要があります。私はキャンバスが良いフレームレートを持っていないことを読んだが、何が良いですか？あなたは怒っている鳥のゲームを書くつもりだったと想像してください。キャンバスのフレームレートは十分でしょうか？

Answer 1

あなたは間違いなくAndEngineの使用を検討する必要があり、このようなビッグゲームやろうとしている場合：http://www.andengine.org/

右使用した場合、それは大きな助けだが。残念ながら、コードにはドキュメントがありません。しかし、このサイトのフォーラムは大丈夫です。 And And Ennginについてさらに多くの質問が現れます。幸運なことに、あなたが始めるための良い例がたくさんあります。

AndEngineはOpenGLを使用しているため、キャンバスに描画する際に低いフレームレートで混乱する必要はありません。

は例のアプリケーションをチェックアウト：https://market.android.com/details?id=org.anddev.andengine.examples

Answer 2

をそれはすべてあなたが実装する必要があるゲームの種類によって異なります。

あなたがキャンバスの実装を求めていることを考えれば、純粋な2Dスプライトゲームを指していると思います。

スプライトが多くなく、数が非常に少ない場合、実際には大きな違いが生じる可能性があります（基本的な2Dグラフィックスで多くのゲームがキャンバスを使用すると考えてください）。

パフォーマンスに問題がある場合やスプライト数が非常に多い場合は、OpenGLベースのシステムを実装する価値があります。

OpenGLを使用するとGPU専用ハードウェアのメリットが得られるため、CPUにグラフィックスレンダリングの負担が軽減されることを考慮してください。

さらに、ブレンディング、ライティング、ポスト処理のエフェクトを使用したキャンバスの実装よりもはるかに柔軟なメリットがあります。あなたができることには本当に限界がありません。

単純な例は、OpenGLなどの3Dエンジンを使用することは非常に安価で優れた結果をもたらす回転とスケーリングです。

簡単な実装では、キャンバスを実際に採用する必要があります。

P.S. OpenGL ES 2.0とプログラマブルなパイプラインを利用すれば、達成するものには何の制限もありません（輝き、ぼかし、数千種類のオプション）。そのような場合の限界は本当に私たちの幻想です。

:)

Answer 3

私が最初にキャンバスを使用して私のゲームを書いたが、その後、次の理由でのOpenGLに切り替えるために必要な：

キャンバスを使用して

• 、あなたのスプライトは、特にあなたがない限り（ヒープ上に格納されていますディスクにキャッシュします）これは、電話に応じてスプライト資産の合計サイズに制限を加えます。私はこれが私の電話で約42MBだったことを知っていました - これはビットマップの圧縮されていないサイズです。アニメーションが異なる複数のエンティティタイプがある場合、このサイズに非常に迅速に到達できます。

• OpenGLはヒープに別々にスプライトアセットを格納するため、使用可能なメモリが大幅に増加します。

• キャンバスの縮尺があまり良くありません。より多くの.draw（...）呼び出しを行うほど、実行速度は遅くなります。関係はかなり線形です。

• OpenGLを使用すると、パフォーマンスを向上させるために描画呼び出しをまとめてバッチすることができます。

Canvasを魅力的に見せるOpenGLから始めると脅威になることがあります。しかし、経験から私はOpenGLを使い始めたばかりです。ゲームを作っているなら、私は「弾を噛んで」OpenGLを使うことをお勧めします。

少し使いやすくするために、私はOpenGLのすべての面倒な作業を行う有用なユーティリティクラスを作成しました。 Canvasを使うときと同じように簡単な.draw（..）呼び出しを行うことができます。次のビデオチュートリアルでは、作業を開始する必要があります

http://www.youtube.com/watch?v=xc93rN2CGNw

EDIT：03/04/13

新しいAndroidデバイスやオペレーティングシステムが出てくると、Googleはキャンバスの性能が向上しているようです。上記で説明したユーティリティクラスのユーザーは、ベンチマークを行った後、次の電子メールで私に連絡しました。

各フレームでランダムな位置にスプライト500を描画します。 Huawei社の名誉（ジンジャーブレッド、シングルコア1.4ギガヘルツ）： SpriteBatcher：19-20 FPS、キャンバス：23-24 FPS

ネクサス7（JellyBean、4つのコア1.3ギガヘルツ）：SpriteBatcherここ

結果であります：29-30 FPS、 キャンバス：57-58 FPS

は今、このユーザーに私の返事に私は、これは私がユーティリティクラスのSpriteBatcherを書いたように、非効率で行うこともできることを説明しました。しかし、Froyo 2.2を実行しているHTC DesireのCanvasでの自分の経験から、スプライトのスプライトは間違いなく遅いと言えるでしょう。

以降のオペレーティングシステムおよびデバイスでは、効率が上回っている可能性がありますが、元の応答の一部の点は有効です。例えば、ディスクにテクスチャをキャッシュすることなく、OutOfMemoryExceptionを打つことで回避することができます。

詳細については、この回答を更新していきます。