A PC-s játékpiac nem szemétlerakó!

Az idei évben a PC-s játékipar egyáltalán nem azt mutatta, amit várnak tőle a játékosok. Már az elmúlt években is viszonylag sok optimalizálatlan PC-s port érkezett, de az idei évben az egyes játékok optimalizálatlansága új mélységeket állított fel. Emlékezhetünk itt a csúfosan megbukott Batman: Arkham Knight PC-s verziójára, de a Call of Duty: Black Ops 3 és az Assassin's Creed Syndicate sem volt mintapélda. Utóbbi persze jobb lett, mint az előző évben csúfosan megbukott Assassin's Creed Unity, de még így is nagyon messze van attól, ami elvárható lenne.

A probléma röviden összefoglalva az, hogy nagyon megszaporodtak a rendkívül rossz optimalizálást használó PC-s portok, de a probléma gyökeréről senki sem beszél, illetve senki nem tesz semmit annak érdekében, hogy a PC-s játékiparon belül ne erősödjön ez az irány.

Az AMD most előállt egy átfogó megoldási javaslattal, amely kihúzhatja ebből a gödörből az egész PC-s játékipart. A legfontosabb szempont, hogy ami megtörtént, az megtörtént, nem lehet rajta változtatni, de kielemezve az egyes játékok fejlesztését, rá lehet jönni, hogy hol került homokszem a gépezetbe. Az AMD elmúlt évben végzett kutatásai szerint több alapvető problémával néz szembe az ipar. Egyrészt a PC-s és a konzolos fejlesztés túlságosan szegmentált, ami nem kedvez a multiplatform címek esetében a PC-nek. Másrészt sok grafikus vezérlő működése abszolút titok bizonyos fejlesztők előtt, ami megnehezíti az optimalizálást, harmadrészt pedig egyre több az úgynevezett feketedoboz, amely gyakorlatilag ellehetetleníti az optimalizálást.

A feketedoboz jelző talán nem ismert, de valójában azokat a rendszereket és middleware-eket nevezik így, amelyek esetében a forráskód nem látható a fejlesztők számára, vagy ha látható is, akkor sem módosítható. Ez okozza a legnagyobb gondot manapság a PC-s portok esetében, mert ha az adott middleware nem módosítható, és nem működik jól az adott leképezővel vagy annak bizonyos optimalizálásaival, akkor a leképezőt át kell írni, vagy ki kell szedni belőle az optimalizálást. Ilyen formában a zárt middleware által beépített elem hiába kapcsolható ki, a leképezőt a kompatibilitási problémákat okozó optimalizálások nélkül szállítják, véglegesen elvéve a sebességet a PC-s porttól. Ilyen formában a fejlesztők keze különböző licencszerződések által meg van kötve, és még ha érzik is, hogy az adott játék PC-s portja nem megfelelő, a különböző jogi kötelezettségek miatt nem tudják a gyökerénél kezelni a problémát.

A komplex problémára az AMD egy viszonylag egyszerű megoldást javasol a GPUOpen koncepcióval. A vállalat szerint az elmúlt években világossá vált számukra, hogy akkor működik a PC-s piac a legjobban, ha a fejlesztők megosztják egymással az innovációt. Bár erre senkit sem lehet kötelezni, de többször is bebizonyosodott már, hogy az "adj, hogy kaphass" elvű konstrukciók megfelelően felépített rendszer keretében abszolút működőképesek. A GPUOpen tulajdonképpen nem lesz más, mint egy fejlesztői epicentrum a GitHub portálon, ahol az iparág vezető szakemberei önszántukból oszthatják meg tapasztalataikat vagy akár fejlesztéseiket.

A koncepció a fenti problémákra direkt megoldást kínál. Egyrészt az ide felkerült kódok és csomagok akármin hasznosíthatók lehetnek. Konzol vagy PC? Mindegy, a hangsúly az optimalizáláson van. Másrészt a fejlesztők nemcsak kódokat oszthatnak meg egymással, hanem olyan információkat is, amelyekhez a fejlesztéseik során jutottak. Természetesen ez nem helyettesíti az egyes grafikus architektúrák jó dokumentálását, de ha egy fejlesztőnek egy problémára van megoldása és az bevált, akkor talán más leképező esetében is működhet. Ezzel azok a fejlesztők járnak kifejezetten jól, akiket a publikus dokumentációkkal nem rendelkező gyártók kvázi semmibe vesznek, így képtelenek hozzájutni olyan információkhoz, amelyek az optimalizáláshoz szükségesek lehetnek.

Végül pedig a middleware-ekre a nyílt forráskódú eljárások jelentik a megoldást. Ha az adott eljárás nem kompatibilis a leképezővel vagy a beépített optimalizációval, akkor fontos, hogy ne a leképezőt kelljen átírni vagy az optimalizálást kiműteni, hanem sokkal célszerűbb az effektet módosítani és kvázi kompatibilissé tenni. Ilyen formában a leképező megőrizheti az eredeti, optimalizált kódbázist az adott eljárás aktiválása mellett vagy nélküle, ami végső soron minden esetben jobb teljesítményhez, és ezzel együtt jobb játékélményhez vezet.

A cikk még nem ért véget, kérlek, lapozz!