Denna fråga är delteknisk, delmeta, del-subjektiv och väldigt specifik:

Jag är en indiespelutvecklare jobbar med android, och de senaste 6 månaderna har jag kämpat och lyckats äntligen skapa min egen 3D-spelapp för Android. Så jag trodde att jag skulle hoppa på SO och hjälpa andra som kämpar med android och openGL-ES

Men de allra flesta frågorna gäller att utöka GLSurfaceView. Jag skapade hela min app utan att förlänga GLSurfaceView (och den går bra). Jag kan inte se någon anledning alls att förlänga GLSurfaceView de flesta frågor jag stöter på.

Ännu värre, Android-dokumentationen antyder att du borde, men ger ingen detaljerad förklaring av varför eller vad fördelarna / nackdelarna är mot att inte utöka och göra allt genom att implementera dina egna GLSurfaceView.Renderer som jag gjorde

Fortfarande, den stora volymen frågor där problemet bara är att utöka GLSurfaceView får mig att undra om det faktiskt finns någon riktigt bra anledning att göra det på det sättet jämfört med hur jag har gjort det (och i mitt svar föreslår att andra ska göra).

Så, finns det något Jag saknar? Ska jag sluta svara på frågor under tiden?

Android openGL-dokumentation

Kommentarer

  • trevlig fråga jag är intresserad av att svara på.
  • En anledning till varför utvidga GLSurfaceView finns här: gamedev. stackexchange.com/questions/12629/… Utan att ha insett det har jag faktiskt redan kringgått de frågor som talas om i denna fråga i min egen app genom att ladda om texturer etc onResume()

Svar

Jag har ett mycket minimalt tillägg för min GLSurfaceView, och det mesta av visdom tillhör min implementering av GLSurfaceView.Renderer. Jag hade följande tre skäl att använda ett omslag för GLSurfaceView:

  1. Basen GLSurfaceView ger inget sätt att få tillbaka Renderer -instansen. Jag har flera ytor och när jag får en UI-händelse för en av dem vill jag skicka kommandot till motsvarande renderare. Så jag åsidosätter setRenderer och behåller referensen i min utökade klass.

  2. GLSurfaceView.Renderer får inte aviseringar för onDetachedFromWindow() eller surfaceDestroyed(). Detta orsakade vissa problem med min implementering. Min förlängning av GLSurfaceView åsidosätter dessa metoder och låter mRenderer veta. Det är möjligt på grund av § 1 .

  3. Vissa metoder läggs endast in för att lägga till try { super. vad som helst ; } catch() { log( vad som helst ) }. Till exempel kommer queueEvent() att kasta om renderaren inte är inställd, men för mig är det OK att ignorera helt enkelt sådana tidslinjeinkonsekvenser.

Kommentarer

  • I ' har börjat göra det också, även om frågan är mer inriktad på varför du kanske lägger den faktiska logiken i en utökad GLSurfaceView snarare än GLSurfaceView.Renderer . Men på punkt 1 behåller jag renderaren som en variabel i min aktivitet. I teorin kan jag få det var som helst genom att kasta sammanhanget: ((MyActivity)view.getContext()).getRenderer(). Kanske lite farligare eftersom kontextobjektet inte nödvändigtvis är MyActivity
  • Det ' är bra om du har en renderare. Men som jag sa tidigare har vi många återgivare, och de ansluter sig till olika SurfaceViews – en röra!

Svar

Åtminstone en god anledning att förlänga GLSurfaceView är att kunna instantiera den direkt från en layout xml-fil, precis som alla andra widgetar: 

 <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 göra det ändå med <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • Bra poäng. Skillnaden är att Android-ramverket i mitt exempel blåser upp och ställer in allt utan att behöva extra kodrader. Din metod är mer kod, men flexibel för att ersätta implementeringen. Bortsett från det verkar båda sätten likna.

Svar

Tja … GLSurfaceView är, som jag är säker på att du har lagt märke till, bara ett omslag för allmänhetens bästa. Det inkapslar all funktionalitet man skulle behöva återge med opengl, med möjlighet att integrera det snyggt i Android View-hierarkin. ditt alternativ så det är omöjligt att jämföra, men jag hoppas att du skapade en annan tråd för rendering som GLSurfaceView gör, annars kan din användarinmatning fördröjas.

Så igen: GLSurfaceView ger en ny tråd för rendering, så du behöver inte oroa dig för användarens ingångsfördröjning

Kommentarer

  • Ja, men GLSurfaceView gör det (startar en renderingstråd) även om du ' t förlänger det. Jag använder GLSurfaceView, men jag förlänger inte '. Jag ' frågar vilka fördelar det är att utvidga det och åsidosätta de olika metoderna där, i motsats till att bara ha allt i Renderer
  • welp, jag försökte 🙂 Jag kan titta på det senare, nu är jag också intresserad!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *