Van piaca a Metal API-nak
Az új Metal API bejelentése után felerősödtek a pletykák az amúgy is sokat emlegetett Apple konzollal kapcsolatban. Ezekben van némi igazságtartalom, de nem a szó legszorosabb értelmében, az almás cég ugyanis nem igazán érdekelt saját játékkonzol fejlesztésében. Ennek megfelelően érdemes elemezni, hogy mégis mit szeretne az Apple, vagy jobban mondva miben van üzleti realitás? A cupertinói óriáscég esetében fontos kiemelni, hogy számukra egy olyan platform, ami csak hosszú távon termel nyereséget, nem igazán kecsegtető. A vezetőség az azonnali és masszív nyereségre törekszik, azaz leginkább olyan üzleti konstrukciókban érdekeltek, amelyek relatíve kis befektetést igényelnek, és kiterjeszthetik az aktuális termékek képességeit, így azok nagyobb piacot fedhetnek le.
A cikk témájára korlátozva az elemzést, rögtön az elején leszögezhetjük, hogy egy saját grafikus API kifejlesztése igazából nem költséges feladat (pláne az Apple pénztárcájához mérve), és házon belül akár két éven belül megoldható. A platform továbbfejlesztése is aprópénz, tehát a Metal ellen túl sok érvet nem lehet felhozni. Természetesen az Apple számára fontos volt, hogy a rendszert támogassák a fejlesztők, hiszen az API-ra épülő játékok nélkül még annak a kevés beleölt pénznek is lehetne jobb helyet találni, de igen valószínű, hogy két-három évvel korábban már nagyon sok fejlesztő könyörgött a gyártóknak, hogy tegyenek le az asztalra modern elvek szerint épített rendszereket, amelyekre lehet hatékonyan dolgozni. Ez helyből támogatást jelent a megjelenéskor, főleg az Apple piaci részesedésével számolva.
A Metal megszületését nem befolyásolhatta, de az Apple számára nagyon érdekes lehetett az utóbbi háromnegyed év, hiszen megfigyelhették a fejlesztői reakciókat az AMD Mantle API-jára. Utóbbit ma már biztosan támogatják a CryEngine, Frostbite, Nitrous, LORE és Asura videojáték-motorok új verziói, ami már önmagában egy jelzés az Apple számára, hogy van piaca az új generációs grafikus API-k koncepciójának. A Metal esetében szintén kiderült már, hogy a CryEngine, a Frostbite, a Unity és az Unreal Engine videojáték-motorok érkező új változatai kezelik a rendszert, tehát az API jövője biztosnak tűnik.
Természetesen az Apple számára a partnerek egyenlő súlyúak, így nem fognak kiemelni egy-egy céget. A Unity és az Unreal Engine 4 eleve az ultramobil piacot célozza meg, tehát ezeknél a Metal támogatása annyira nem kritikus fontosságú. Nyilván örül neki minden érintett, viszont multiplatform, azaz Androidra is érkező címeknél úgyis OpenGL ES 3.0-ra kell szabni a dizájnt, ami csak limitált előnyt jelent a Metal használata során. A CryEngine és a Frostbite 3 támogatása sokkal fontosabb. Az utóbbi két motort a PC-kre és az új generációs konzolokra szabták, tehát OpenGL ES 3.0-n rendkívül komoly limitációkkal használhatók, de csak elméletben, mivel a gyakorlatot tekintve egyik motornak sincs portja Androidra.
A CryEngine esetében a Crytek valószínűleg megoldja ezt a gondot, bár egyelőre nincs szó róla. Eközben az Electronic Arts korábban úgy gondolta, hogy hátrányos lenne a Frostbite 3 fejlesztésének, ha az ultramobil termékeket is figyelembe vennék, így ennek a motornak jó ideig nem is lesz OpenGL, illetve OpenGL ES API-t támogató leképzője. Helyette készül egy Frostbite Go nevű videojáték-motor, ami technikai értelemben külön fejlesztés, de elsődleges célja a Frostbite 3 úgymond kiegészítése, hiszen utóbbival képtelenség megcélozni az ultramobil piacot, míg a Frostbite Go olyan alapvető butításokat vezet be, amivel ez egy kihasználható lehetőséggé válik. Ha nagyon le akarjuk egyszerűsíteni, akkor az Electronic Arts a DirectX 11 és 12, a Mantle, illetve a Metal API-ra, valamint az új generációs konzolokra használja majd a Frostbite 3-at, míg az OpenGL, illetve OpenGL ES API-val rendelkező platformokra a Frostbite Go lesz bevethető.
Látható, hogy az Apple számára rögtön ad egy olyan előnyt a Metal API, ami tulajdonképpen lehetővé teszi, hogy a CryEngine és a Frostbite 3 motort használó játékok portolhatók legyenek iOS 8-ra. Érdemes kiemelni, hogy sokan az ultramobil piac problémájának még mindig a hardvert tartják, de valójában nem ez a gond. Többek között az Apple A7-es SoC által használt, A7 GPU-ként aposztrofált IGP tulajdonképpen egy Imagination PowerVR G6430-as fejlesztés, csak az almás cég írja hozzá a grafikus drivert. Ettől azonban a hardver nem változik, és utóbbi a compute képességek szempontjából legalább annyira fejlett, mint egy DirectX 11-et támogató asztali grafikus vezérlő. A probléma forrása tehát nem a hardver tudásának a hiánya, hanem az alkalmazott grafikus API-k elavultsága, de ezt a helyzetet a Metal orvosolja. Innentől kezdve már csak paraméterezés kérdése az adott port futtathatósága, mivel a compute shader kihasználására tervezett motorok által alkalmazott eljárásokat a hardver az új API-val képes támogatni.
Példaként felhozható, hogy a Frostbite 3 alapvető működésének része a mozaikos deferred leképző. Ez adja a motorhoz a hatékonyságot, és nem lehet csak úgy kiműteni belőle. Persze nyilván lecserélhető a rendszer egyszerűbb leképzőre, de olyan mértékben romlana a sebesség, hogy értelmetlen gondolkodni ilyen változtatáson. A mozaikos deferred leképzővel azonban az Apple A7 SoC nagyon jól működne, hiszen minden megvan a hardverben, hogy üzemképes és gyors legyen az eljárás, de az OpenGL-lel és OpenGL ES-sel, ezen belül is az API-k compute shader részével a Frostbite Team egyszerűen nem tud mit kezdeni. Itt az OpenGL egy általános problémája merül fel, miszerint elméletben hiába tud valamit az API, ha a gyakorlatban valamilyen – feltételezhetően ideiglenes – probléma miatt az kihasználhatatlan. A CryEngine esetében szintén a mozaikos leképzők felé menetel a Crytek, így ugyanabba a problémába ütköznének, mint a Frostbite 3.
A cikk még nem ért véget, kérlek, lapozz!
