A Nitrous videojáték-motor sokak figyelmét felkeltette, mivel ez az első olyan rendszer, amely alapjaiban is az alacsony szintű hardverelérést biztosító grafikus API-khoz lett tervezve. Lesznek azonban egyéb lényeges újításai is, melyekről eddig nem lehetett tudni, sőt, ma is csak információfoszlányok érhetők el, de az idei GDC-n sok dolog kiderülhet.
Mivel a Nitroust elsődlegesen a stratégiai játékokhoz tervezték, így szinte sorra kerülnek elő azok a technikai problémák, amelyek ezt a műfajt kvázi parkolópályára küldték. Nyilván a legnagyobb gondot, vagyis a hagyományos grafikus API-k többletterhelését láthatóan megoldották az érintettek, de közel sem ez az egyetlen probléma. Rengeteg stratégiai játék tartalmaz olyan módot, amely szimplán csak az általános szórakozást szolgálja, így a játékos egy véletlenszerűen generált terepen, véletlenszerű környezetben lejátszhat egy-egy meccset például gépi ellenfelek ellen. Részben ez adja a műfaj báját, de ami a felhasználó számára természetes funkciónak tűnik, az valójában a fejlesztés oldalán esetlegesen kínzóan nehezen kivitelezhető.
Az előbbi példánál maradva nyilván a programnak véletlenszerűen generálnia kell egy terepet. Maga a probléma önmagában nem jelentős, de ha hozzávesszük, hogy annak a terepnek minőséginek kell lennie, akkor az már bonyolítja a helyzetet, és ha ehhez még feltételként hozzájön, hogy ezt a feladatot relatíve gyorsan kell megcsinálni, akkor a jó minőségű és sebességű terepgenerálás az egyik legnagyobb problémává lép elő.
A jelenlegi játékok között is találunk példákat a problémára. A Sid Meier’s Civilization: Beyond Earth esetében egy komplexebb terep generálása egy átlagos processzoron akár két percig is eltarthat, ami igazából kibírható, addig fel lehet készülni a meccsre, illetve ehhez a jelenséghez a stratégiával játszó réteg hozzászokott (persze választható előre elkészített pálya, de ilyenkor a terepgenerálás lépcsője kimarad, így ez most nem lényeges). A probléma viszont valós, és a Firaxis programozói már kísérleteznek a terepgenerálás OpenCL-re való átültetésével, ami persze korai állapotban van, így nem kerülhetett bele a fentebb említett játékba.
Viszont a gondok az idő előrehaladtával fokozódnak, főleg egy olyan éles ugrásnál, mint amit a Nitrous képvisel. Ez a rendszer grafikailag jóval többre képes, mint bármelyik hasonló videojáték-motor, tehát a jó minőségű terepgenerálás időigénye sajnos megnő. Bár utóbbi nagyon függ a terep komplexitásától, illetve a méretétől is, de a jelenlegi adatok szerint visszasírjuk majd a régen soknak tartott terepgenerálási időket. Legrosszabb esetben egy négymagos processzoron a komplex terepek generálása akár 10 perces munka is lehet, vagy még több. Persze ezen lehet kozmetikázni a maximálisan kiválasztható terep méretének limitálásával, ami csökkenti a szükséges időigényt, de van radikálisabb megoldás is a problémára.
A Nitrous a terepgenerálásra opcionálisan felhasználhatja a GPGPU erejét. Ez a jelenlegi adatok szerint, a csúcskategóriás GPU-kon akár százszor gyorsabb lehet a hagyományos opcióhoz viszonyítva, vagyis újra elérhető a relatíve komfortosnak mondható egy perc alatti időigény. Szintén kedvező, hogy még az aktuális IGP-k is jóval gyorsabban megoldják a terepgenerálást, mint a mellettük lévő processzormagok, tehát dedikált GPU nélkül is előnyös a rendszer. Bár itt már nem lehet majd százszoros gyorsulásról beszélni, de tízszeresen vagy hússzorosan így is gyorsabb lesz, ami megmenti a játékosokat a töltőképernyő percekig történő bámulásától.
Úgy tudtuk, hogy a Nitrous a GPGPU-s terepgenerálást többféle platformon fogja támogatni. A prototípus kód a Mantle API-n működik, és ha ez elkészül, akkor ebből lesz portolva egy DirectX 12-es DirectCompute-ra épülő, illetve egy OpenCL-es verzió (később opciós lehetőség az újraírt OpenGL támogatása is). Amelyik PC egyiket sem támogatja (nem sok ilyen lesz, de elképzelhető), ott a processzor továbbra is megoldhatja a terepgenerálás problémáját.
