Android, OpenGL dan memperluas GLSurfaceView?

12

Pertanyaan ini sebagian teknis, sebagian meta, sebagian subjektif dan sangat spesifik:

Saya seorang pengembang game indie yang bekerja di android, dan selama 6 bulan terakhir saya telah berjuang dan akhirnya berhasil membuat aplikasi game 3D saya sendiri untuk android. Jadi saya pikir saya akan melompat pada SO dan membantu orang lain yang berjuang dengan android dan openGL-ES

Namun, sebagian besar pertanyaan terkait dengan perluasan GLSurfaceView. Saya membuat seluruh aplikasi saya tanpa memperpanjang GLSurfaceView(dan itu berjalan dengan baik). Saya tidak dapat melihat alasan apa pun untuk memperluas GLSurfaceViewsebagian besar pertanyaan yang saya temui.

Lebih buruk lagi, dokumentasi android menyiratkan bahwa Anda seharusnya, tetapi tidak memberikan penjelasan rinci tentang mengapa atau apa pro / kontra vs tidak memperluas dan melakukan segala sesuatu melalui menerapkan milik Anda GLSurfaceView.Rendererseperti yang saya lakukan.

Namun, banyaknya pertanyaan di mana masalahnya murni berkaitan dengan perpanjangan GLSurfaceViewmembuat saya bertanya-tanya apakah sebenarnya ada beberapa alasan yang sangat baik untuk melakukannya seperti itu vs cara saya telah melakukannya (dan menyarankan jawaban saya kepada orang lain melakukan).

Jadi, apakah ada sesuatu yang saya lewatkan? Haruskah saya berhenti menjawab pertanyaan sementara?

Dokumentasi Android openGL

android opengl

— Sendok Jempol
sumber

pertanyaan yang bagus saya tertarik tentang jawaban ..

— Tofeeq

Salah satu alasan mengapa memperpanjang GLSurfaceView dapat ditemukan di sini: gamedev.stackexchange.com/questions/12629/... Tanpa disadari, saya sebenarnya sudah mengesampingkan masalah yang dibicarakan dalam pertanyaan ini di aplikasi saya sendiri dengan memuat ulang tekstur dllonResume()

— Spoon Thumb

2

Saya memiliki ekstensi yang sangat minimal untuk saya GLSurfaceView, dan sebagian besar kebijaksanaan milik implementasi saya GLSurfaceView.Renderer. Saya memiliki tiga alasan berikut untuk menggunakan pembungkus untuk GLSurfaceView:

Pangkalan GLSurfaceViewtidak memberikan cara untuk mendapatkan Rendererinstance kembali. Saya memiliki beberapa permukaan, dan ketika saya menerima acara UI untuk salah satunya, saya ingin meneruskan perintah ke renderer yang sesuai. Jadi, saya mengganti setRendererdan menyimpan referensi di kelas saya.
GLSurfaceView.Renderertidak menerima pemberitahuan untuk onDetachedFromWindow()atau surfaceDestroyed(). Ini menyebabkan beberapa masalah pada implementasi saya. Ekstensi saya GLSurfaceViewmenimpa metode ini dan memberi tahu mRenderer . Itu mungkin karena §1 .
Beberapa metode hanya dibungkus untuk menambahkan try { super.apa ; } catch() { log(pun apa pun) } . Misalnya, queueEvent()akan melempar jika Renderer tidak disetel; tetapi bagi saya, tidak apa-apa untuk mengabaikan inkonsistensi garis waktu seperti itu.

— Alex Cohn
sumber

Saya sudah mulai melakukan ini juga, meskipun pertanyaannya lebih ditujukan pada mengapa Anda mungkin menempatkan logika yang sebenarnya dalam sebuah ekstensi GLSurfaceViewdaripada GLSurfaceView.Renderer. Meskipun pada poin 1, saya menjadikan renderer sebagai variabel dalam aktivitas saya. Secara teori saya bisa mendapatkannya dari mana saja dengan casting konteks: ((MyActivity)view.getContext()).getRenderer(). Mungkin sedikit lebih berbahaya karena objek konteks mungkin tidak selaluMyActivity

— Spoon Thumb

Tidak masalah jika Anda memiliki satu renderer. Tetapi seperti yang saya katakan sebelumnya, kami memiliki banyak perender, dan mereka terhubung ke SurfaceViews yang berbeda - berantakan!

— Alex Cohn

0

Setidaknya satu alasan bagus untuk memperluas GLSurfaceView adalah untuk dapat membuat instantiate langsung dari file layout xml, sama seperti widget lainnya:

    <RelativeLayout ... >
      <com.example.MyGlSurfaceView
        android:id="@+id/my_view"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
      />
     </RelativeLayout>

— Amir Uval
sumber

1

Anda dapat melakukannya dengan menggunakan

<android.opengl.GLSurfaceView  		android:id="@+id/graphics_glsurfaceview1"  		android:layout_width="fill_parent"  		android:layout_height="fill_parent" 	/>

— Spoon Thumb

Poin yang bagus. Perbedaannya adalah bahwa dalam contoh saya kerangka Android mengembang dan mengatur semuanya tanpa perlu baris kode tambahan. Metode Anda lebih banyak kode, tetapi fleksibel untuk menggantikan implementasi. Selain itu, kedua cara tersebut tampak serupa.

— Amir Uval

-1

Yah ... GLSurfaceView adalah, seperti yang saya yakin Anda perhatikan, hanya pembungkus untuk kebaikan bersama. Ini merangkum semua fungsi yang perlu di-render dengan opengl, memiliki opsi untuk menggabungkannya dengan baik dengan hierarki tampilan android.

Anda tidak memberikan alternatif Anda sehingga tidak mungkin untuk membandingkan, tapi saya harap Anda menelurkan utas lain untuk rendering seperti yang dilakukan GLSurfaceView, atau input pengguna Anda mungkin tertinggal.

Jadi sekali lagi: GLSurfaceView menyediakan utas baru untuk rendering, jadi Anda tidak perlu khawatir tentang lag input pengguna

— Greg
sumber

2

Ya, tetapi GLSurfaceViewapakah itu (memulai utas render) meskipun Anda tidak memperpanjangnya. Saya menggunakan GLSurfaceView, tapi saya tidak memperpanjangnya. Saya bertanya manfaat apa yang didapat dari memperpanjangnya dan mengesampingkan metode yang berbeda di dalamnya sebagai lawan dari hanya memiliki semua yang ada diRenderer

— Spoon Thumb

welp, saya sudah mencoba :) Saya mungkin memeriksanya nanti, sekarang saya juga tertarik!

— Greg