Ez a kérdés részben technikai, részben meta, részben szubjektív és nagyon specifikus:

Indie game dev vagyok az androidon dolgoztam, és az elmúlt 6 hónapban küzdöttem, és végül sikerült elkészítenem saját 3D-s játékalkalmazásomat androidra. Tehát azt hittem, hogy beugrom az SO-ba, és segítek másoknak, akik androidos és openGL-ES-vel küzdenek.

A kérdések túlnyomó többsége azonban a GLSurfaceView kiterjesztésével kapcsolatos. Az egész alkalmazást úgy készítettem el, hogy nem terjesztettem ki a (z) GLSurfaceView kiterjesztést (és ez jól működik). Egyáltalán nem látok okot a GLSurfaceView a legtöbb kérdés, amellyel találkozom.

Rosszabb esetben az androidos dokumentáció azt sugallja, hogy neked kellene, de nem ad részletes magyarázatot arra, hogy miért vagy miért vannak az előnyök / hátrányok, és nem terjesztesz ki mindent, és mindent megteszel a sajátod megvalósításával. GLSurfaceView.Renderer ahogy én tettem

Mégis, az a rengeteg kérdés, ahol a probléma pusztán a GLSurfaceView kiterjesztésével függ össze arra késztet, hogy elgondolkodjak azon, hogy valóban van-e valami igazán jó ok arra, hogy ezt így csináljam, és nem úgy, ahogy én ezt csináltam (és másoknak javaslom a válaszaimban).

Tehát van valami Hiányzik? Addig is hagyjam abba a kérdések megválaszolását?

Android openGL dokumentáció

Megjegyzések

  • kedves kérdés, amelyre szívesen válaszolok.
  • A GLSurfaceView kiterjesztésének egyik oka itt található: gamedev. stackexchange.com/questions/12629/… anélkül, hogy észrevenném, valójában már a saját alkalmazásomban is elhagytam a kérdésben tárgyalt kérdéseket a textúrák stb. újratöltésével. onResume()

Válasz

Nagyon minimális kiterjesztéssel rendelkezem a GLSurfaceView, és a legtöbb bölcsesség az GLSurfaceView.Renderer megvalósításához tartozik. A következő három okom volt arra, hogy csomagolót használjak a GLSurfaceView fájlhoz:

  1. Az alap GLSurfaceView nem nyújt módot a Renderer példány visszaszerzésére. Több felületem van, és amikor az egyikhez felhasználói felület eseményt kapok, át akarom adni a parancsot a megfelelő renderelőnek. Tehát felülbírálom a setRenderer fájlt, és a referenciát a kibővített osztályomban tartom.

  2. GLSurfaceView.Renderer nem kap értesítést a onDetachedFromWindow() vagy a surfaceDestroyed() címről. Ez problémákat okozott a megvalósításomban. A (z) GLSurfaceView kiterjesztésem felülbírálja ezeket a módszereket, és tudatja a mRenderer -vel. § 1 miatt lehetséges.

  3. Egyes módszerek csak try { super. bármi ; } catch() { log( hozzáadására szolgálnak bármi ) }. Például a queueEvent() dob, ha a Renderer nincs beállítva; de nekem OK, hogy egyszerűen figyelmen kívül hagyja az idővonal következetlenségeit.

Megjegyzések

  • I ' Ezt is elkezdtem csinálni, bár a kérdés inkább arra irányul, hogy miért lehet a tényleges logikát kiterjesztett GLSurfaceView -be tenni, nem pedig GLSurfaceView.Renderer . Bár az 1. pontban a tevékenységemet változóként tartom meg. Elméletileg bárhonnan megszerezhetem a kontextus átvetésével: ((MyActivity)view.getContext()).getRenderer(). Talán egy kicsit veszélyesebb, mivel a kontextusobjektum nem feltétlenül MyActivity
  • ' megfelelő, ha van egy renderelő. De mint korábban mondtam, sok renderünk van, és összekapcsolódnak a különböző SurfaceView-kkal – rendetlenség!

Answer

Legalább egy jó ok a GLSurfaceView kiterjesztésére az, hogy közvetlenül az elrendezés xml fájljából képes példányosítani, akárcsak bármely más 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>

Megjegyzések

  • Ezt úgyis megteheti a <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
  • jó pont használatával. A különbség az, hogy az én példámban az Android keretrendszer mindent felfúj és beállít anélkül, hogy további kódsorokra lenne szükség. A módszer kódosabb, de rugalmas a megvalósítás helyettesítésére. Ettől eltekintve mindkét út hasonlónak tűnik.

Válasz

Nos … A GLSurfaceView olyan, mint én biztos, hogy észrevetted, csak egy burkoló a közjó érdekében. Összefoglalja az összes olyan funkciót, amelyet az opengl-rel meg kellene adni, lehetőséget adva arra, hogy szépen beépítse az androidos nézet hierarchiájába.

Nem adtad meg az alternatívája, így lehetetlen összehasonlítani, de remélem, hogy egy újabb szálat hoztál létre a rendereléshez, ahogyan azt a GLSurfaceView teszi, vagy a felhasználói bevitel elmaradhat.

Tehát még egyszer: A GLSurfaceView új szálat nyújt a rendereléshez, így nem kell aggódnia a felhasználói beviteli késés miatt div>

Megjegyzések

  • Igen, de GLSurfaceView akkor is ezt teszi (renderelő szálat indít), ha nem terjeszti ki '. A GLSurfaceView -et használom, de nem terjesztem ki '. ' azt kérdezem, milyen előnyök származnak a kiterjesztéséből és a benne lévő különböző módszerek felülbírálásából, szemben azzal, hogy csak a Renderer
  • welp, megpróbáltam 🙂 Lehet, hogy később utánanézek, most engem is érdekel!

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük