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 pendant les 6 derniers mois, jai eu du mal et jai finalement réussi à créer ma propre application de jeu 3D pour Android. Jai donc pensé « sauter sur SO et aider dautres personnes aux prises avec Android et openGL-ES

Cependant, la grande majorité des questions concernent lextension de GLSurfaceView. Jai créé toute mon application sans étendre GLSurfaceView (et cela fonctionne correctement). Je ne vois aucune raison détendre GLSurfaceView pour la majorité des questions que je rencontre.

Pire encore, la documentation Android implique que vous devriez le faire, mais ne donne aucune explication détaillée sur pourquoi ou quels sont les avantages / inconvénients par rapport à ne pas étendre et à tout faire en implémentant votre propre GLSurfaceView.Renderer comme je lai fait

Pourtant, le grand nombre de questions où le problème est purement lié à lextension de GLSurfaceView me fait me demander sil y a vraiment une bonne raison de le faire de cette façon par rapport à la façon dont je le fais (et suggérant dans mes réponses aux autres de faire).

Alors, y a-t-il quelque chose Je suis absent? Dois-je arrêter de répondre aux questions entre-temps?

Documentation Android openGL

Commentaires

  • belle question à laquelle je tiens à répondre ..
  • Une raison pour laquelle étendre GLSurfaceView peut être trouvée ici: gamedev. stackexchange.com/questions/12629/… Sans men rendre compte, jai déjà contourné les problèmes évoqués dans cette question dans ma propre application en rechargeant des textures, etc. onResume()

Réponse

Jai une extension très minimale pour mon GLSurfaceView, et la plus grande partie de la sagesse appartient à mon implémentation de GLSurfaceView.Renderer. Jai eu les trois raisons suivantes dutiliser un wrapper pour GLSurfaceView:

  1. La base GLSurfaceView ne fournit aucun moyen de récupérer linstance Renderer. Jai plusieurs surfaces et lorsque je reçois un événement dinterface utilisateur pour lune dentre elles, je souhaite transmettre la commande au moteur de rendu correspondant. Donc, je remplace setRenderer et je garde la référence dans ma classe étendue.

  2. GLSurfaceView.Renderer ne reçoit pas de notifications pour onDetachedFromWindow() ou surfaceDestroyed(). Cela a causé quelques problèmes à mon implémentation. Mon extension de GLSurfaceView remplace ces méthodes et informe le mRenderer . Cest possible à cause de § 1 .

  3. Certaines méthodes ne sont encapsulées que pour ajouter try { super. peu importe ; } catch() { log( peu importe ) }. Par exemple, queueEvent() lancera si Renderer nest pas défini; mais pour moi, cest OK pour ignorez simplement ces incohérences dans la chronologie.

Commentaires

  • I ' Jai commencé à faire cela aussi, bien que la question vise davantage à savoir pourquoi vous pourriez placer la logique réelle dans un GLSurfaceView étendu plutôt que GLSurfaceView.Renderer . Bien que sur le point 1, je garde le moteur de rendu comme variable dans mon activité. En théorie, je peux lobtenir de nimporte où en transposant le contexte: ((MyActivity)view.getContext()).getRenderer(). Peut-être un peu plus dangereux car l’objet de contexte n’est pas forcément MyActivity
  • Cela ' est parfait si vous avez un moteur de rendu. Mais comme je lai déjà dit, nous avons de nombreux rendus, et ils sont connectés à différents SurfaceViews – un gâchis!

Réponse

Au moins une bonne raison détendre GLSurfaceView est de pouvoir linstancier directement à partir dun fichier xml de mise en page, comme nimporte quel 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>

Commentaires

  • 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" />
  • Bon point. La différence est que dans mon exemple, le framework Android gonfle et configure tout sans avoir besoin de lignes de code supplémentaires. Votre méthode est plus de code, mais flexible pour remplacer limplémentation. À part cela, les deux manières semblent similaires.

Réponse

Eh bien … GLSurfaceView est, comme je suis Bien sûr, vous 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 incorporer joliment avec la hiérarchie Android View.

Vous navez pas fourni votre alternative, il est donc impossible de comparer, mais jespère que vous avez engendré un autre thread pour le rendu comme le fait GLSurfaceView, ou votre entrée utilisateur pourrait être retardée.

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

Commentaires

  • Oui, mais GLSurfaceView fait cela (démarre un thread de rendu) même si vous ne létendez pas '. Jutilise GLSurfaceView, mais je ne ' que létendre. Je ' m demande quels sont les avantages de l’étendre et de remplacer les différentes méthodes qui y figurent plutôt que de tout avoir dans le Renderer
  • welp, jai essayé 🙂 Je vais peut-être y réfléchir plus tard, maintenant ça mintéresse aussi!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *