Dette spørsmålet er delteknisk, del-meta, del-subjektivt og veldig spesifikt:

Jeg er en indiespillutvikler jobbet med android, og de siste 6 månedene har jeg slitt og til slutt lyktes i å lage min egen 3D-spillapp for android. Så jeg trodde jeg skulle hoppe på SO og hjelpe andre som sliter med android og openGL-ES

De aller fleste spørsmålene er imidlertid knyttet til å utvide GLSurfaceView. Jeg lagde hele appen min uten å utvide GLSurfaceView (og den går bra). Jeg kan ikke se noen grunn til å utvide GLSurfaceView til de fleste spørsmålene jeg kommer over.

Verre, android-dokumentasjonen innebærer at du burde, men gir ingen detaljert forklaring på hvorfor eller hva fordeler / ulemper er mot å ikke utvide og gjøre alt gjennom å implementere dine egne GLSurfaceView.Renderer som jeg gjorde

Likevel, det store volumet av spørsmål der problemet bare har å gjøre med å utvide GLSurfaceView får meg til å lure på om det faktisk er noen veldig god grunn til å gjøre det på den måten mot slik jeg har gjort det (og foreslår i mine svar til andre å gjøre).

Så, er det noe Jeg savner? Skal jeg slutte å svare på spørsmål i mellomtiden?

Android openGL-dokumentasjon

Kommentarer

  • hyggelig spørsmål jeg er opptatt av å svare på ..
  • En grunn til hvorfor utvide GLSurfaceView finner du her: gamedev. stackexchange.com/questions/12629/… Uten å innse det, har jeg faktisk allerede gått bort fra problemene som er snakket om i dette spørsmålet i min egen app ved å laste opp teksturer osv = «f1a1db7d86″>

Svar

Jeg har en veldig minimal utvidelse for GLSurfaceView, og det meste av visdommen hører til implementeringen min av GLSurfaceView.Renderer. Jeg hadde følgende tre grunner til å bruke en innpakning til GLSurfaceView:

  1. Basen GLSurfaceView gir ingen måte å få Renderer forekomsten tilbake. Jeg har flere overflater, og når jeg mottar en UI-hendelse for en av dem, vil jeg overføre kommandoen til den tilsvarende gjengiveren. Så jeg overstyrer setRenderer og beholder referansen i min utvidede klasse.

  2. GLSurfaceView.Renderer mottar ikke varsler for onDetachedFromWindow() eller surfaceDestroyed(). Dette forårsaket noen problemer med implementeringen min. Min utvidelse av GLSurfaceView overstyrer disse metodene og lar mRenderer vite. Det er mulig på grunn av § 1 .

  3. Noen metoder er bare pakket inn for å legge til try { super. uansett ; } catch() { log( hva som helst ) }. For eksempel vil queueEvent() kaste hvis gjengiveren ikke er satt, men for meg er det OK å bare ignorere slike uoverensstemmelser i tidslinjen.

Kommentarer

  • I ' Vi har begynt å gjøre dette også, selv om spørsmålet er mer rettet mot hvorfor du kan legge den faktiske logikken i en utvidet GLSurfaceView i stedet for GLSurfaceView.Renderer . Selv om jeg er på punkt 1, holder jeg gjengiveren som en variabel i aktiviteten min. I teorien kan jeg få det fra hvor som helst ved å kaste sammenhengen: ((MyActivity)view.getContext()).getRenderer(). Kanskje litt farligere da kontekstobjektet ikke nødvendigvis er MyActivity
  • Det ' er greit hvis du har en gjengir. Men som jeg sa tidligere, vi har mange gjengivere, og de blir koblet til forskjellige SurfaceViews – et rot!

Svar

Minst en god grunn til å utvide GLSurfaceView er å være i stand til å instantiere den direkte fra en layout-xml-fil, akkurat som enhver annen 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>

Kommentarer

  • Du kan gjøre det uansett ved å bruke <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • Bra poeng. Forskjellen er at Android-rammeverket i mitt eksempel blåser opp og setter opp alt uten å trenge ekstra linjer med kode. Metoden din er mer kode, men fleksibel for å erstatte implementering. Bortsett fra det, virker begge veier like.

Svar

Vel … GLSurfaceView er, som jeg er at du har lagt merke til, bare en innpakning til felles beste. Den innkapsler all funksjonaliteten man trenger å gjengi med opengl, og har muligheten til å innlemme den pent i Android View-hierarkiet.

Du oppga ikke alternativet ditt, så det er umulig å sammenligne, men jeg håper du skapte en annen tråd for gjengivelse slik GLSurfaceView gjør, ellers kan brukerinndataene dine forsinke.

Så igjen: GLSurfaceView gir en ny tråd for gjengivelse, så du trenger ikke å bekymre deg for brukerinngangssperre

Kommentarer

  • Ja, men GLSurfaceView gjør det (starter en gjengetråd) selv om du ikke ' t utvider den. Jeg bruker GLSurfaceView, men jeg utvider ikke '. Jeg ' spør hva fordelene er med å utvide det og overstyre de forskjellige metodene der, i motsetning til bare å ha alt i Renderer
  • welp, jeg prøvde 🙂 Jeg kan se nærmere på det senere, nå er jeg også interessert!

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *