Questa domanda è in parte tecnica, in parte meta, in parte soggettiva e molto specifica:

Sono uno sviluppatore di giochi indie lavorando su Android, e negli ultimi 6 mesi ho lottato e finalmente sono riuscito a creare la mia app di gioco 3D per Android. Quindi ho pensato di “saltare su SO e aiutare gli altri alle prese con Android e openGL-ES

Tuttavia, la stragrande maggioranza delle domande si riferisce allestensione di GLSurfaceView. Ho creato la mia intera app senza estendere GLSurfaceView (e funziona correttamente). Non vedo alcun motivo per estendere GLSurfaceView per la maggior parte delle domande che incontro.

Peggio ancora, la documentazione di Android implica che dovresti farlo, ma non fornisce spiegazioni dettagliate sul perché o quali sono i pro / contro rispetto al non estendere e fare tutto implementando il tuo GLSurfaceView.Renderer come ho fatto io

Tuttavia, lenorme volume di domande in cui il problema ha esclusivamente a che fare con lestensione di GLSurfaceView mi sta facendo chiedere se effettivamente ci sia qualche buona ragione per farlo in quel modo rispetto a come lho fatto io (e suggerendo nelle mie risposte agli altri di farlo).

Quindi, cè qualcosa Mi manca? Devo smettere di rispondere alle domande nel frattempo?

Documentazione di Android openGL

Commenti

  • bella domanda che mi interessa rispondere ..
  • Un motivo per estendere GLSurfaceView può essere trovato qui: gamedev. stackexchange.com/questions/12629/… Senza rendermene conto, in realtà ho già eluso i problemi di cui si parla in questa domanda nella mia app ricaricando le trame, ecc onResume()

Risposta

Ho unestensione minima per il mio GLSurfaceView e la maggior parte della saggezza appartiene alla mia implementazione di GLSurfaceView.Renderer. Avevo i seguenti tre motivi per utilizzare un wrapper per GLSurfaceView:

  1. Il GLSurfaceView non fornisce alcun modo per recuperare listanza Renderer. Ho più superfici e quando ricevo un evento dellinterfaccia utente per una di esse, voglio passare il comando al renderer corrispondente. Quindi, sovrascrivo setRenderer e mantengo il riferimento nella mia classe estesa.

  2. GLSurfaceView.Renderer non riceve notifiche per onDetachedFromWindow() o surfaceDestroyed(). Ciò ha causato alcuni problemi alla mia implementazione. La mia estensione di GLSurfaceView sostituisce questi metodi e comunica a mRenderer . È possibile grazie a § 1 .

  3. Alcuni metodi vengono inseriti solo per aggiungere try { super. qualunque ; } catch() { log( qualunque cosa ) }. Ad esempio, queueEvent() lancerà se Renderer non è impostato; ma per me va bene ignora semplicemente tali incongruenze nella sequenza temporale.

Commenti

  • I ' ho iniziato a fare anche questo, sebbene la domanda sia più mirata al motivo per cui potresti inserire la logica effettiva in un GLSurfaceView esteso piuttosto che in GLSurfaceView.Renderer . Anche se al punto 1, mantengo il renderer come variabile nella mia attività. In teoria posso ottenerlo da qualsiasi luogo trasmettendo il contesto: ((MyActivity)view.getContext()).getRenderer(). Forse un po più pericoloso in quanto loggetto contesto potrebbe non essere necessariamente MyActivity
  • ' va bene se hai un renderer. Ma come ho detto prima, abbiamo molti rendering e si connettono a diversi SurfaceView: un casino!

Answer

Almeno un buon motivo per estendere GLSurfaceView è essere in grado di istanziarlo direttamente da un file xml di layout, proprio come qualsiasi altro widget: 

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

Commenti

  • Puoi farlo comunque usando <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • Buona osservazione. La differenza è che nel mio esempio il framework Android gonfia e imposta tutto senza bisogno di righe di codice aggiuntive. Il tuo metodo è più codice, ma flessibile per sostituire limplementazione. A parte questo, entrambi i modi sembrano simili.

Risposta

Bene … GLSurfaceView è, come me certo che hai notato, è solo un wrapper per il bene comune. Incapsula tutte le funzionalità necessarie per il rendering con opengl, avendo la possibilità di incorporarlo perfettamente con la gerarchia di Android View.

Non hai fornito la tua alternativa quindi è impossibile confrontare, ma spero che tu abbia generato un altro thread per il rendering come fa GLSurfaceView, o linput dellutente potrebbe essere in ritardo.

Quindi ancora: GLSurfaceView fornisce un nuovo thread per il rendering, quindi non devi preoccuparti del ritardo di input dellutente

Commenti

  • Sì, ma GLSurfaceView lo fa (avvia un thread di rendering) anche se non ' estenderlo. Uso GLSurfaceView, ma non ' per estenderlo. ' sto chiedendo quali vantaggi ci sono dallestenderlo e ignorare i diversi metodi in esso contenuti invece di avere tutto nel Renderer
  • welp, ho provato 🙂 Potrei esaminarlo più tardi, ora mi interessa anche!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *