2017. november 24., péntek

OpenGL ES

  • (p)
Írta: Abu85 | Utoljára frissítve: 2013-02-26 16:52

Az OpenGL ES néven ismert grafikus API-t a Khronos Group vezetésével fejlesztik a cégek. A nyílt ipari szabványnak tekinthető felület a beágyazott rendszerekbe szánt grafikus vezérlők egységes programozása céljából hozták létre, így a legtöbb okostelefonra, tabletre, vagy más ultramobil eszközre szánt grafikus alkalmazás az OpenGL ES-en keresztül működik.

Az OpenGL ES 1.0 specifikációi 2003-ban láttak napvilágot és az asztali grafikus vezérlőkhöz szánt OpenGL 1.3-ra épültek, azaz a fixfunkciós hardverekhez igazodtak. Az OpenGL ES 1.0 és az OpenGL 1.3 között a legfőbb különbség, hogy előbbi specifikációjából kikerült a glBegin és glEnd parancspár, amivel az asztali verzió a legtöbb geometriai objektumot specifikálja. Szintén eltérőek a primitív leképző funkciók, ami főleg a hardverek tudásának tudható be, mivel a legtöbb beágyazott grafikus vezérlő akkoriban még nem volt képes lebegőpontos adattípusokat kezelni, így az OpenGL ES fixpontos koordinátákat használt a vertexekhez.

Az OpenGL ES egyszerűsítése érdekében még számos OpenGL funkció került ki az API-ból, ami egyszerűsítette a felület működését.

Az első komolyabb újítása az OpenGL ES-nek az 1.1-es verzió volt, ami már az OpenGL 1.5-re épült, és a legnagyobb előnye az előddel szemben, hogy kötelezően bevezette a multitextúrázás támogatását, illetve a VBO-t (Vertex Buffer Objects).

Az OpenGL ES 1.0 és 1.1 nem lett túl sikeres API, így a Khronos Group könnyedén döntött amellett, hogy a 2007-ben publikált OpenGL ES 2.0 visszafelé kompatibilitását elvágja. Utóbbi azért történt, mert az API-ból kivágták az elődökben használt fixfunkciós fotószalagot, így a programozható futószalag került a középpontba.

Az OpenGL ES 2.0 az asztali OpenGL 2.0-ra épült, de a beágyazott verziója az API-nak ettől a ponttól kezdett el külön utat járni, és az alapvető kompatibilitás az OpenGL 4.1-ig nem is volt biztosított.

Az OpenGL ES 2.0 már komoly sikereket ért el a piacon, hiszen majdnem minden okostelefonra és tabletre készített játék ezt az API-t használja, a fejlesztők között azonban nem számított kiemelkedően kedvelt megoldásnak. Sikerét jórészt annak köszönheti, hogy nem volt alternatívája. Legnagyobb hibája az volt, hogy a Khronos Group szakszerűtlenül definiálta a pufferformátum specifikációját, ami ahhoz a gondhoz vezetett, hogy a gyártók esetenként eltérő pufferformátumot implementáltak a hardverbe, és a fejlesztőknek ezeket a különbségeket direkten le kellett kezelni az adott alkalmazáson belül. Ez azt jelentette, hogy még akkor sem volt garantálva az OpenGL ES 2.0-s alkalmazás futtathatósága, ha a hardver tökéletesen kompatibilis volt a felülettel. Ez egy API esetében a legnagyobb probléma, ami fennállhat.

A 2012-ben bemutatott OpenGL ES 3.0 az API legújabb verziója, és számottevő előrelépés az elődhöz képest, hiszen az előbbi bekezdésben említett problémát a Khronos Group felszámolta. Ráadásul az új API kompatibilis a 2.0-s specifikációkkal, így a pedig igen gyors átállásra van kilátás, hiszen jelentősen leegyszerűsödik a fejlesztők dolga.

A technikai oldalról az OpenGL ES 3.0 bevezeti az occlusion query-t és a geometry instancinget. Előbbi a rajzolás előtt a komplex objektumok helyett először olyan téglatestalakú dobozokat helyez el, amelyek az objektum adatait hordozzák. A Z tesztek lefuttatása után azok az objektumok nem lesznek megrajzolva, amelyekről az ellenőrzés során kiderült, hogy nem fognak látszani a végső képkockán. A geometry instancing technika is hasznos, hiszen segítségével a futószalag bármely pontján képes a rendszer bármilyen eddig betöltött objektumot lemásolni és ismét kirajzolni egyetlen utasítással. További újítás, hogy bekerült a több render target támogatása is, mely a deferred render motorok esetében hasznos lehet. Számottevő változás még, hogy az új API rengeteg új textrúraformátumot támogat.

Jelentős előrelépés, hogy a Khronos Group a textúratömörítés szabványosítására törekedett, így kötelezővé vált az immáron szabványos ETC textúratömörítési formátum támogatása az ETC2 és az EAC kiegészítések mellett. Ezenkívül megjelent a 32 bites lebegőpontos operációk kötelező támogatása.

Ha pontatlanságot találsz a cikkben, kérjük, írd meg a szerzőnek!
A bejegyzés utolsó frissítésének időpontja: 2013-02-26 16:52

H​ir​d​e​tés

H​irdeté​s

Copyright © 2000-2017 PROHARDVER Informatikai Kft.