この質問は、部分的に技術的、部分的にメタ、部分的に主観的で、非常に具体的です。
私はインディーゲームの開発者ですアンドロイドに取り組んでいて、過去6か月間、私は苦労し、ついにアンドロイド用の独自の3Dゲームアプリを作成することに成功しました。だから私はSOに飛び乗って、AndroidとopenGL-ESで苦労している他の人を助けると思った
しかし、質問の大部分はGLSurfaceView
の拡張に関連しています。 GLSurfaceView
を拡張せずにアプリ全体を作成しました(正常に動作します)。GLSurfaceView
を拡張する理由がまったくわかりません。私が遭遇する質問の大部分。
さらに悪いことに、Androidのドキュメントでは、そうすべきであると示唆されていますが、長所/短所が拡張されていないことと、独自の実装を通じてすべてを実行していないことの詳細な説明はありません。 GLSurfaceView.Renderer
私が行ったように
それでも、問題が純粋にGLSurfaceView
の拡張に関係している質問の膨大な量私がこれまでやってきた方法と比べて、実際にその方法でそれを行うのに本当に正当な理由があるのだろうかと私に思わせています(そして他の人にそうするように私の答えで提案しています)。私は行方不明ですか?その間に質問への回答を停止する必要がありますか?
コメント
回答
であり、ほとんどの知恵は私のGLSurfaceView.Renderer
の実装に属しています。 GLSurfaceView
のラッパーを使用する理由は次の3つです。
-
ベース
GLSurfaceView
は、Renderer
インスタンスを元に戻す方法を提供しません。複数のサーフェスがあり、そのうちの1つでUIイベントを受け取ったら、対応するレンダラーにコマンドを渡します。そのため、setRenderer
をオーバーライドし、参照を拡張クラスに保持します。 -
GLSurfaceView.Renderer
はonDetachedFromWindow()
またはsurfaceDestroyed()
の通知を受け取りません。これは私の実装にいくつかの問題を引き起こしました。GLSurfaceView
の拡張機能はこれらのメソッドをオーバーライドし、 mRenderer に知らせます。 § 1 が原因で可能です。 -
一部のメソッドは、
try { super.
何でも; } catch() { log(
を追加するためにのみラップされます。何でも) }
。たとえば、レンダラーが設定されていない場合、queueEvent()
がスローされますが、私にとっては、このようなタイムラインの不一致は無視してください。
コメント
- I 'これも始めましたが、質問は、実際のロジックを
GLSurfaceView.Renderer
ではなく拡張されたGLSurfaceView
に配置する理由を目的としています。 。ポイント1ですが、レンダラーをアクティビティの変数として保持しています。理論的には、コンテキストをキャストすることでどこからでも取得できます:((MyActivity)view.getContext()).getRenderer()
。コンテキストオブジェクトが必ずしもMyActivity
- 'であるとは限らないため、おそらくもう少し危険です。 1つのレンダラー。しかし、前に言ったように、私たちには多くのレンドラーがあり、それらはさまざまなSurfaceViewに接続されています-混乱です!
回答
GLSurfaceViewを拡張する少なくとも1つの理由は、他のウィジェットと同様に、レイアウトxmlファイルから直接インスタンス化できることです。
<RelativeLayout ... > <com.example.MyGlSurfaceView android:id="@+id/my_view" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerInParent="true" /> </RelativeLayout>
コメント
-
<android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
- 良い点を使用してとにかくそれを行うことができます。違いは、私の例では、Androidフレームワークが、余分なコード行を必要とせずにすべてを膨らませてセットアップすることです。あなたの方法はより多くのコードですが、実装を置き換えるために柔軟です。それ以外は、どちらの方法も似ているようです。
回答
そうですね… GLSurfaceViewは私と同じですお気づきのことと思いますが、これは共通善のための単なるラッパーです。openglでレンダリングする必要のあるすべての機能をカプセル化し、Androidビュー階層にうまく組み込むオプションがあります。
提供していません代替手段なので比較することはできませんが、GLSurfaceViewのようにレンダリング用に別のスレッドを生成したことを願っています。そうしないと、ユーザー入力が遅れる可能性があります。
繰り返しになりますが、 GLSurfaceViewはレンダリング用の新しいスレッドを提供するため、ユーザー入力の遅れについて心配する必要はありません
コメント
- はい、ただし
GLSurfaceView
は(レンダリングスレッドを開始します) '拡張しないでください。GLSurfaceView
を使用していますが、'拡張していません。 'Renderer
にすべてを含めるのではなく、拡張してさまざまなメソッドをオーバーライドすることでどのようなメリットがあるのかを尋ねています。 li>
onResume()