Dette spørgsmål er delteknisk, del-meta, del-subjektivt og meget specifikt:

Jeg er en indie-spiludvikler arbejder på android, og i de sidste 6 måneder har jeg kæmpet og endelig lykkedes at lave min egen 3D-spil-app til Android. Så jeg troede, jeg ville hoppe på SO og hjælpe andre, der kæmper med android og openGL-ES

Men langt de fleste spørgsmål vedrører udvidelse af GLSurfaceView. Jeg lavede hele min app uden at udvide GLSurfaceView (og den kører fint). Jeg kan slet ikke se nogen grund til at udvide GLSurfaceView til de fleste af de spørgsmål, jeg støder på.

Værre, android-dokumentationen antyder, at du burde, men giver ingen detaljeret forklaring på, hvorfor eller hvad fordele / ulemper er vs ikke at udvide og gøre alt ved at implementere dine egne GLSurfaceView.Renderer som jeg gjorde

Stadig den store mængde spørgsmål, hvor problemet rent ude har at gøre med at udvide GLSurfaceView får mig til at spekulere på, om der faktisk er en rigtig god grund til at gøre det på den måde i forhold til den måde, jeg har gjort det (og foreslår i mine svar til andre at gøre).

Så er der noget Jeg mangler? Skal jeg stoppe med at besvare spørgsmål i mellemtiden?

Android openGL-dokumentation

Kommentarer

  • dejligt spørgsmål, jeg er meget glad for at svare på ..
  • En af grundene til, hvorfor GLSurfaceView udvides, kan findes her: gamedev. stackexchange.com/questions/12629/… Uden at være klar over det, har jeg faktisk allerede overgået de spørgsmål, der er omtalt i dette spørgsmål i min egen app ved at genindlæse teksturer osv. = “f1a1db7d86″>

Svar

Jeg har en meget minimal udvidelse til min GLSurfaceView, og det meste af visdommen hører til min implementering af GLSurfaceView.Renderer. Jeg havde følgende tre grunde til at bruge en indpakning til GLSurfaceView:

  1. Basen GLSurfaceView giver ingen måde at få Renderer -forekomsten tilbage. Jeg har flere overflader, og når jeg modtager en UI-begivenhed for en af dem, vil jeg overføre kommandoen til den tilsvarende gengiver. Så jeg tilsidesætter setRenderer og holder referencen i min udvidede klasse.

  2. GLSurfaceView.Renderer modtager ikke underretninger for onDetachedFromWindow() eller surfaceDestroyed(). Dette medførte nogle problemer med min implementering. Min udvidelse af GLSurfaceView tilsidesætter disse metoder og lader mRenderer vide. Det er muligt på grund af § 1 .

  3. Nogle metoder er kun pakket for at tilføje try { super. uanset ; } catch() { log( uanset hvad ) }. For eksempel vil queueEvent() kaste, hvis gengiveren ikke er indstillet; men for mig er det OK at ignorere simpelthen sådanne uoverensstemmelser i tidslinjen.

Kommentarer

  • I ' Vi er også begyndt at gøre dette, selvom spørgsmålet mere er rettet mod, hvorfor du måske lægger den aktuelle logik i en udvidet GLSurfaceView i stedet for GLSurfaceView.Renderer . Selvom jeg på punkt 1 holder rendereren som en variabel i min aktivitet. I teorien kan jeg få det overalt ved at kaste konteksten: ((MyActivity)view.getContext()).getRenderer(). Måske lidt farligere, da kontekstobjektet muligvis ikke nødvendigvis er MyActivity
  • Det ' er fint, hvis du har en renderer. Men som jeg sagde før, har vi mange gengivere, og de får forbindelse til forskellige SurfaceViews – et rod!

Svar

Mindst en god grund til at udvide GLSurfaceView er at være i stand til at instantiere det direkte fra en layout xml-fil, som enhver anden 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

  • Det kan du alligevel gøre ved hjælp af <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • Godt punkt. Forskellen er, at i mit eksempel puster Android-rammen op og opsætter alt uden behov for ekstra linjer med kode. Din metode er mere kode, men fleksibel til at erstatte implementeringen. Bortset fra det virker begge måder ens.

Svar

Nå … GLSurfaceView er, som jeg er sikker på, at du har bemærket, bare en indpakning til fælles bedste. Den indkapsler al den funktionalitet, som man har brug for at gengive med opengl, og har mulighed for at indarbejde det pænt i Android-visningshierarkiet.

Du har ikke givet dit alternativ, så det er umuligt at sammenligne, men jeg håber, du har skabt en anden tråd til gengivelse, som GLSurfaceView gør, ellers kan din brugerindgang forsinke.

Så igen: GLSurfaceView giver en ny tråd til gengivelse, så du behøver ikke bekymre dig om brugerinputforsinkelse

Kommentarer

  • Ja, men GLSurfaceView gør det (starter en gengivelsestråd), selvom du ' t udvider det. Jeg bruger GLSurfaceView, men jeg udvider det ikke '. Jeg ' spørger, hvilke fordele der er ved at udvide det og tilsidesætte de forskellige metoder deri i modsætning til bare at have alt i Renderer
  • welp, jeg prøvede 🙂 Jeg kan se på det senere, nu er jeg også interesseret!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *