Tämä kysymys on osittain tekninen, osittain meta, osittain subjektiivinen ja hyvin spesifinen:

Olen indie-pelin kehittäjä työskentelen androidilla, ja viimeisten kuuden kuukauden aikana olen taistellut ja onnistunut vihdoin tekemään oman 3D-pelisovellukseni Androidille. Joten ajattelin hypätä SO: hen ja auttaa muita androidin ja openGL-ES: n kanssa kamppailevia

Suurin osa kysymyksistä liittyy kuitenkin GLSurfaceView laajentamiseen. Tein koko sovellukseni laajentamatta GLSurfaceView (ja se toimii hyvin). En näe mitään syytä laajentaa GLSurfaceView Suurin osa kohtaamistani kysymyksistä.

Mikä pahempaa, android-dokumentaatio viittaa siihen, että sinun pitäisi, mutta ei anna yksityiskohtaista selitystä sille tai miksi hyvät / huonot puolet eivätkä laajenna ja tee kaikkea toteuttamalla omat GLSurfaceView.Renderer kuten minäkin

Silti, valtava määrä kysymyksiä, joissa ongelma liittyy puhtaasti GLSurfaceView saa minut miettimään, onko oikeastaan todella hyviä syitä tehdä niin tällä tavoin kuin tapalla, jolla olen tehnyt sen (ja ehdotan vastauksissani muille tekemistä).

Onko siis jotain Minulta puuttuu? Pitäisikö minun lopettaa vastaaminen kysymyksiin tällä välin?

Android openGL -dokumentaatio

Kommentit

  • mukava kysymys, josta olen kiinnostunut vastauksesta ..
  • Yksi syy miksi laajentaa GLSurfaceView-ohjelmaa löytyy täältä: gamedev. stackexchange.com/questions/12629/… Ymmärtämättä sitä, olen jo ohittanut tässä kysymyksessä puhutut kysymykset omassa sovelluksessani lataamalla tekstuurit uudelleen jne. onResume()

vastaus

Minulla on hyvin vähän laajennuksia GLSurfaceView, ja suurin osa viisaudesta kuuluu GLSurfaceView.Renderer -sovellukseni toteuttamiseen. Minulla oli seuraavat kolme syytä käyttää kääriä GLSurfaceView:

  1. Perusta GLSurfaceView ei tarjoa tapaa palauttaa Renderer -instanssia. Minulla on useita pintoja, ja kun saan käyttöliittymän tapahtuman yhdelle niistä, haluan välittää komennon vastaavalle renderöijälle. Joten ohitan setRenderer ja pidän viitteen laajennetussa luokassa.

  2. GLSurfaceView.Renderer ei vastaanota ilmoituksia onDetachedFromWindow() tai surfaceDestroyed(). Tämä aiheutti joitain ongelmia toteutuksessani. Laajennukseni GLSurfaceView ohittaa nämä menetelmät ja antaa mRenderer tietää. Se on mahdollista § 1 .

  3. Jotkut menetelmät ovat kääritty vain lisäämään try { super. mikä tahansa ; } catch() { log( mitä tahansa ) }. Esimerkiksi queueEvent() heittää, jos Rendereriä ei ole asetettu; mutta minulle se on OK yksinkertaisesti ohita tällaiset aikajanan epäjohdonmukaisuudet.

Kommentit

  • I ' Olemme aloittaneet myös tämän tekemisen, vaikka kysymys onkin suunnattu tarkemmin siihen, miksi todellisen logiikan voi laittaa laajennettuun GLSurfaceView kuin GLSurfaceView.Renderer . Vaikka kohdassa 1 pidän renderöijää muuttujana toiminnassani. Teoriassa saan sen mistä tahansa heittämällä kontekstin: ((MyActivity)view.getContext()).getRenderer(). Ehkä hieman vaarallisempi, koska asiayhteysobjekti ei välttämättä ole välttämättä MyActivity
  • se ' on hyvä, jos sinulla on yksi renderöijä. Mutta kuten sanoin aiemmin, meillä on paljon renderöijiä, ja ne yhdistyvät eri SurfaceView-näkymiin – sotku!

Vastaa

Ainakin yksi hyvä syy GLSurfaceView: n laajentamiseen on pystyä luomaan se suoraan xml-asettelutiedostosta, kuten kaikki muutkin widgetit: 

 <RelativeLayout ... > <com.example.MyGlSurfaceView android:id="@+id/my_view" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerInParent="true" /> </RelativeLayout>

Kommentit

  • Voit tehdä sen joka tapauksessa käyttämällä <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • hyvää. Erona on, että esimerkissäni Android-kehys täyttää ja asentaa kaiken tarvitsematta ylimääräisiä koodirivejä. Menetelmäsi on enemmän koodia, mutta joustava korvaamaan toteutuksen. Sen lisäksi molemmat tavat näyttävät samanlaisilta.

Vastaa

No … GLSurfaceView on, kuten minä varmista, että olet huomannut, vain kääre yleisen edun hyväksi. Se sisältää kaikki toiminnot, jotka sinun on tehtävä renderöitäväksi opengl: llä, ja mahdollisuus sisällyttää se hienosti android View -hierarkiaan.

Et antanut vaihtoehtosi, joten sitä on mahdotonta verrata, mutta toivon, että synnyit toisen säikeen renderöintiin, kuten GLSurfaceView tekee, tai käyttäjän syötteet saattavat viivästyä.

Joten vielä kerran: GLSurfaceView tarjoaa uuden ketjun renderointia varten, joten sinun ei tarvitse huolehtia käyttäjän syöttöviiveestä

kommentit

  • kyllä, mutta GLSurfaceView tekee sen (aloittaa renderöintiketjun), vaikka et laajenna sitä '. Käytän GLSurfaceView, mutta en jatka sitä '. <

kysyn, mitä hyötyä on sen laajentamisesta ja siinä olevien eri menetelmien ohittamisesta sen sijaan, että kaikki olisi vain Renderer

  • welp, yritin 🙂 Voisin tutkia sitä myöhemmin, nyt olen myös kiinnostunut!

    • Vastaa

    Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *