Android, OpenGL et extension de GLSurfaceView?

12

Cette question est en partie technique, en partie méta, en partie subjective et très spécifique:

Je suis un développeur de jeux indépendants travaillant sur Android, et au cours des 6 derniers mois, j'ai eu du mal et j'ai finalement réussi à créer ma propre application de jeu 3D pour Android. J'ai donc pensé sauter sur SO et aider les autres aux prises avec Android et openGL-ES

Cependant, la grande majorité des questions concernent l'extension GLSurfaceView. J'ai fait toute mon application sans étendre GLSurfaceView(et ça marche bien). Je ne vois aucune raison de m'étendre GLSurfaceViewà la majorité des questions que je rencontre.

Pire, la documentation Android implique que vous devriez le faire, mais ne donne aucune explication détaillée des raisons ou des avantages / inconvénients par rapport à ne pas étendre et tout faire en implémentant le vôtre GLSurfaceView.Renderercomme je l'ai fait

Pourtant, le volume de questions où le problème est purement lié à l'extension GLSurfaceViewme fait me demander s'il y a vraiment une très bonne raison de le faire de cette façon par rapport à la façon dont je l'ai fait (et de suggérer dans mes réponses aux autres faire).

Alors, y a-t-il quelque chose qui me manque? Dois-je cesser de répondre aux questions entre-temps?

Documentation OpenGL Android

android opengl Pouce cuillère
la source
belle question que je suis désireux de répondre ..
Tofeeq
Une raison pour laquelle étendre GLSurfaceView peut être trouvée ici: gamedev.stackexchange.com/questions/12629/… Sans le savoir, j'ai en fait déjoué les problèmes évoqués dans cette question dans ma propre application en rechargeant les textures, etc.onResume()
Spoon Thumb

Réponses:

2

J'ai une extension très minime pour moi GLSurfaceView, et la majeure partie de la sagesse appartient à mon implémentation de GLSurfaceView.Renderer. J'ai eu les trois raisons suivantes pour utiliser un wrapper pour GLSurfaceView:

  1. La base GLSurfaceViewne fournit aucun moyen de récupérer l' Rendererinstance. J'ai plusieurs surfaces et lorsque je reçois un événement d'interface utilisateur pour l'une d'entre elles, je souhaite passer la commande au rendu correspondant. Donc, je remplace setRendereret conserve la référence dans ma classe étendue.

  2. GLSurfaceView.Rendererne reçoit pas de notifications pour onDetachedFromWindow()ou surfaceDestroyed(). Cela a causé des problèmes à ma mise en œuvre. Mon extension de GLSurfaceViewremplace ces méthodes et informe le mRenderer . C'est possible grâce au §1 .

  3. Certaines méthodes ne sont encapsulées que pour ajouter try { super.quoi ; } catch() { log(que ce soit) } . Par exemple, queueEvent()lancera si Renderer n'est pas défini; mais pour moi, c'est OK d'ignorer simplement ces incohérences de chronologie.

Alex Cohn
la source
J'ai commencé à le faire également, bien que la question vise plus à savoir pourquoi vous pourriez mettre la logique réelle dans une extension GLSurfaceViewplutôt que GLSurfaceView.Renderer. Bien qu'au point 1, je garde le moteur de rendu comme variable dans mon activité. En théorie , je peux l' obtenir partout en jetant le contexte: ((MyActivity)view.getContext()).getRenderer(). Peut-être un peu plus dangereux car l'objet contextuel ne l'est pas nécessairementMyActivity
Spoon Thumb
C'est bien si vous avez un moteur de rendu. Mais comme je l'ai déjà dit, nous avons de nombreux rendus, et ils sont connectés à différents SurfaceViews - un gâchis!
Alex Cohn
0

Au moins une bonne raison d'étendre GLSurfaceView est de pouvoir l'instancier directement à partir d'un fichier XML de mise en page, comme tout autre 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
la source
1
Vous pouvez le faire de toute façon en utilisant<android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
Spoon Thumb
Bon point. La différence est que dans mon exemple, le framework Android se gonfle et configure tout sans avoir besoin de lignes de code supplémentaires. Votre méthode est plus de code, mais flexible pour remplacer l'implémentation. À part cela, les deux façons semblent similaires.
Amir Uval
-1

Eh bien ... GLSurfaceView est, comme je suis sûr que vous l'avez remarqué, juste un wrapper pour le bien commun. Il encapsule toutes les fonctionnalités dont on aurait besoin pour rendre avec opengl, ayant la possibilité de l'intégrer bien avec la hiérarchie de vue Android.

Vous n'avez pas fourni votre alternative, il est donc impossible de comparer, mais j'espère que vous avez généré un autre thread pour le rendu comme le fait GLSurfaceView, ou votre entrée utilisateur pourrait être en retard.

Encore une fois: GLSurfaceView fournit un nouveau thread pour le rendu, vous n'avez donc pas à vous soucier du décalage d'entrée utilisateur

Greg
la source
2
Oui, mais GLSurfaceViewfait cela (démarre un thread de rendu) même si vous ne le prolongez pas. J'utilise GLSurfaceView, mais je ne le prolonge pas. Je demande quels avantages y a-t-il à le prolonger et à remplacer les différentes méthodes qu'il contient plutôt que de tout avoir dansRenderer
Spoon Thumb
welp, j'ai essayé :) Je pourrais y jeter un œil plus tard, maintenant je suis aussi intéressé!
Greg