Android, OpenGL ed estensione GLSurfaceView?

12

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

Sono uno sviluppatore di giochi indie che lavora 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 riguarda l'estensione GLSurfaceView. Ho realizzato tutta la mia app senza estenderla GLSurfaceView(e funziona bene). Non riesco a vedere alcun motivo per estendere GLSurfaceViewla maggior parte delle domande che incontro.

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

Tuttavia, il mero volume di domande in cui il problema ha solo a che fare con l'estensione si GLSurfaceViewsta facendo mi chiedo se in realtà ci siano davvero delle buone ragioni per farlo in quel modo rispetto al modo in cui l'ho fatto (e suggerendo nelle mie risposte agli altri fare).

Quindi, c'è qualcosa che mi manca? Nel frattempo dovrei smettere di rispondere alle domande?

Documentazione Android OpenGL

android opengl

— Spoon Thumb
fonte

bella domanda, sono entusiasta della risposta ..

— Tofeeq,

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

— Spoon Thumb

2

Ho un'estensione molto minima per la mia GLSurfaceViewe la maggior parte della saggezza appartiene alla mia implementazione di GLSurfaceView.Renderer. Ho avuto i seguenti tre motivi per utilizzare un wrapper per GLSurfaceView:

La base GLSurfaceViewnon fornisce alcun modo per Rendererripristinare l' istanza. Ho più superfici e quando ricevo un evento UI per una di esse, voglio passare il comando al renderer corrispondente. Quindi, ho la precedenza setRenderere mantengo il riferimento nella mia classe estesa.
GLSurfaceView.Renderernon riceve notifiche per onDetachedFromWindow()o surfaceDestroyed(). Ciò ha causato alcuni problemi alla mia implementazione. La mia estensione di GLSurfaceViewsovrascrive questi metodi e informa mRenderer . È possibile a causa del §1 .
Alcuni metodi sono inclusi solo per aggiungere try { super.qualunque ; } catch() { log(cosa) } . Ad esempio, queueEvent()verrà lanciato se Renderer non è impostato; ma per me è OK semplicemente ignorare tali incongruenze nella sequenza temporale.

— Alex Cohn
fonte

Ho anche iniziato a fare questo, anche se la domanda è più mirata al motivo per cui potresti mettere la logica attuale in un esteso GLSurfaceViewpiuttosto che GLSurfaceView.Renderer. Sebbene al punto 1, mantengo il renderer come variabile nella mia attività. In teoria posso ottenere da qualsiasi lanciando contesto: ((MyActivity)view.getContext()).getRenderer(). Forse un po 'più pericoloso poiché l'oggetto di contesto potrebbe non essere necessariamenteMyActivity

— Spoon Thumb

Va bene se hai un renderer. Ma come ho detto prima, abbiamo molti renderer e si collegano a diversi SurfaceView: un casino!

— Alex Cohn,

0

Almeno un buon motivo per estendere GLSurfaceView è poter 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>

— Amir Uval
fonte

1

Puoi farlo comunque usando

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

— Spoon Thumb

Buon punto. La differenza è che nel mio esempio il framework Android gonfia e configura tutto senza bisogno di righe di codice aggiuntive. Il tuo metodo è più codice, ma flessibile per sostituire l'implementazione. A parte questo, entrambi i modi sembrano simili.

— Amir Uval,

-1

Bene ... GLSurfaceView è, come sono certo che hai notato, solo un involucro per il bene comune. Incapsula tutte le funzionalità di cui avresti bisogno per renderizzare con opengl, avendo la possibilità di incorporarlo bene 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 che l'input dell'utente potrebbe essere in ritardo.

Ancora una volta: GLSurfaceView fornisce un nuovo thread per il rendering, quindi non devi preoccuparti del ritardo di input dell'utente

— Greg
fonte

2

Sì, ma lo GLSurfaceViewfa (avvia un thread di rendering) anche se non lo estendi. Lo uso GLSurfaceView, ma non lo estendo. Sto chiedendo quali sono i vantaggi dell'estensione e dell'override dei diversi metodi in esso contenuti, invece di avere tutto nelRenderer

— Spoon Thumb

welp, ho provato :) Potrei esaminarlo più tardi, ora sono anche interessato!

— Greg