Deze vraag is deels technisch, deels meta, deels subjectief en heel specifiek:

Ik ben een indie game-ontwikkelaar werkend op Android, en de afgelopen 6 maanden heb ik geworsteld en ben er eindelijk in geslaagd mijn eigen 3D-game-app voor Android te maken. Dus ik dacht dat ik “op SO zou springen en anderen zou helpen die worstelen met android en openGL-ES

De overgrote meerderheid van de vragen heeft echter betrekking op uitbreiding van GLSurfaceView. Ik heb mijn hele app gemaakt zonder GLSurfaceView uit te breiden (en het werkt prima). Ik zie helemaal geen reden om GLSurfaceView uit te breiden voor de meeste vragen die ik tegenkom.

Erger nog, de Android-documentatie impliceert dat je dat zou moeten doen, maar geeft geen gedetailleerde uitleg van waarom of wat de voor- / nadelen zijn versus niet uitbreiden en alles doen door je eigen te implementeren GLSurfaceView.Renderer zoals ik deed

Toch is het enorme aantal vragen waarbij het probleem puur te maken heeft met het uitbreiden van GLSurfaceView doet me afvragen of er eigenlijk een echt goede reden is om het op die manier te doen versus de manier waarop ik het “heb gedaan (en in mijn antwoorden aan anderen suggereerde om te doen).

Dus, is er iets Ik mis? Moet ik in de tussentijd stoppen met het beantwoorden van vragen?

Android openGL-documentatie

Opmerkingen

  • leuke vraag die ik graag wil beantwoorden.
  • Een reden waarom GLSurfaceView uitbreiden is hier te vinden: gamedev. stackexchange.com/questions/12629/… Zonder het te beseffen, heb ik de problemen waarover in deze vraag gesproken wordt al omzeild in mijn eigen app door texturen enz. opnieuw te laden onResume()

Antwoord

Ik heb een zeer minimale extensie voor mijn GLSurfaceView, en de meeste wijsheid behoort toe aan mijn implementatie van GLSurfaceView.Renderer. Ik had de volgende drie redenen om een wrapper te gebruiken voor GLSurfaceView:

  1. De basis GLSurfaceView biedt geen manier om de Renderer instantie terug te krijgen. Ik heb meerdere oppervlakken en wanneer ik een UI-gebeurtenis voor een van deze ontvang, wil ik de opdracht doorgeven aan de overeenkomstige renderer. Dus ik negeer setRenderer en bewaar de referentie in mijn uitgebreide klas.

  2. GLSurfaceView.Renderer ontvangt geen meldingen voor onDetachedFromWindow() of surfaceDestroyed(). Dit veroorzaakte wat problemen bij mijn implementatie. Mijn extensie van GLSurfaceView overschrijft deze methoden en laat de mRenderer weten. Het is mogelijk vanwege § 1 .

  3. Sommige methoden zijn alleen verpakt om try { super. wat dan ook ; } catch() { log( toe te voegen wat dan ook ) }. queueEvent() zal bijvoorbeeld gooien als Renderer niet is ingesteld; maar voor mij is het oké om negeer dergelijke inconsistenties in de tijdlijn gewoon.

Reacties

  • I ' we zijn hiermee ook begonnen, hoewel de vraag meer gericht is op waarom u de feitelijke logica in een uitgebreide GLSurfaceView zou kunnen plaatsen in plaats van in GLSurfaceView.Renderer . Hoewel op punt 1, houd ik de renderer als een variabele in mijn activiteit. In theorie kan ik het overal vandaan halen door de context te casten: ((MyActivity)view.getContext()).getRenderer(). Misschien iets gevaarlijker omdat het contextobject niet noodzakelijk MyActivity
  • hoeft te zijn ' als je één renderer. Maar zoals ik al eerder zei, we hebben veel renderers, en ze worden verbonden met verschillende SurfaceViews – een puinhoop!

Answer

Minstens één goede reden om GLSurfaceView uit te breiden, is om het direct te kunnen instantiëren vanuit een XML-layoutbestand, net als elke andere 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>

Opmerkingen

  • Je kunt dat hoe dan ook doen met <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • Goed punt. Het verschil is dat in mijn voorbeeld het Android-framework alles opblaast en instelt zonder dat er extra regels code nodig zijn. Uw methode is meer code, maar flexibel om implementatie te vervangen. Behalve dat lijken beide manieren op elkaar.

Antwoord

Nou … GLSurfaceView is, zoals ik je hebt het zeker gemerkt, gewoon een omhulsel voor het algemeen belang. Het bevat alle functionaliteit die je nodig hebt om te renderen met opengl, met de optie om het mooi op te nemen in de hiërarchie van android View.

Je hebt niet voorzien je alternatief, dus het is onmogelijk om te vergelijken, maar ik hoop dat je nog een thread hebt voortgebracht voor weergave zoals GLSurfaceView doet, anders kan je gebruikersinvoer achterblijven.

Dus nogmaals: GLSurfaceView biedt een nieuwe thread voor weergave, zodat u zich geen zorgen hoeft te maken over vertraging van gebruikersinvoer

Reacties

  • Ja, maar GLSurfaceView doet dat (start een rendering thread) zelfs als je ' niet uitbreiden. Ik gebruik GLSurfaceView, maar ik ' niet uitbreiden. Ik ' m vraag welke voordelen het heeft om het uit te breiden en de verschillende methoden daarin te negeren, in plaats van gewoon alles in de Renderer
  • welp, ik heb het geprobeerd 🙂 Ik zou er later naar kunnen kijken, nu ben ik ook geïnteresseerd!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *