HTML

Survive Developement

Itt olvashatod a Survive! nevű játék fejlesztésének állapotát, lépéseit. És mi is lesz a játék? Egy zombis-túlélős játék, ahol elsősorban a csapatmunkára építkezve kell megpróbálni életben maradni egy kihalt városban. A terep teljesen a tietek, nincsenek szabályok: éljetek túl, ahogy tudtok!


Küldj e-mailt nekünk:
gilgamesco@gmail.com

Sikolyok

Ettől tépjük a hajunkat:

Friss topikok

  • Sir Butcher: A gyors mozgású ütközés-érzékelés majd a lövésnél lesz topic :D A második esetben teljesen igaza... (2012.04.05. 16:38) Ütközésérzékelés
  • _fpeti_: Halad ez. (2012.04.04. 22:01) Gravitáció
  • Sir Butcher: Az sem rossz, az tény :D Szerencsére egyelőre annyi különbözőt kell csinálnom, hogy esélyem sincs ... (2012.02.20. 21:48) Scenery - Még több látvány
  • Sir Butcher: Na, ideírom: obj-nél megoldottam a csontokat. Melléktermékként összejöttek, extra számítás nélkül ... (2011.12.02. 11:48) Model Animálás - a probléma, és a (vélt) megoldás
  • Burwor: "A tesztvárosban sétálgatva belefutsz egy házba, aminek hiányzik egy fala. Mit csinálsz?" Zárva a... (2011.11.10. 15:00) Sziduri - a grafmotor bemutatkozik

Quadtree-k, sokadszorra

2012.03.13. 10:48 :: Sir Butcher

Egy kis állapotjelentés csak:

Ugyan nem olyan régen letettem a Quadtree-kről, mert egyszerűen túl sok processzoridőt raboltak el, hiába próbáltam a lehetőségekhez mérten lecsökkenteni az időt, amikor futottak. Az egyetlen megoldás az volt, hogy a quad-ok méretét eléggé nagyra növeltem - itt viszont elveszett az előny, amit adtak. Úgyhogy, nehéz szívvel töröltem majd négy napos munkámat, és ennek örömére a framerate kapásból megugrott, jó 40 FPS-el. Ennek örültem, nagyon.

Egészen az elmúlt napokig, amikor belekezdtem az optimalizálásba. És észrevettem, hogy igaz, hogy a Quadtree nem számol, de rengeteg fölösleges adat kezdi elvenni az előnyt, amit kicsikartam a grafmotorból. Úgyhogy, visszatértem az alapokhoz, és írtam egy újfajta quadtree-t. Az újfajtasága abból ered, hogy rendkívül mértékben lecsökkentettem a komplexitását, és összetettségét. Immáron nem foglalkozik azzal, mit lát a kamera, csupán annyi az összes dolga, hogy megmutatja, a pálya mely négyzetében tartózkodok - és eltárolja az ehhez a négyzethez szükséges adatokat, illetve azt, hogy melyek az ő szomszédai.

Így kapásból kapok kétfajta területet: elsőnek van a "fő" négyzet, ahol a játékos aktuálisan tartózkodik. Ez megjelenik teljes felbontásban: modelekkel, zombikkal, házakkal, fákkal, mindennel.

A második, szomszéd quad pedig rendkívül csökkentett felbontásban: a házak ugyan megjelennek, de a belsejük nem töltődik ki, a fák helyett billboardot jelenítek meg, és természetesen nincsenek látható ellenfelek sem. Persze ez a felbontási ráta tetszőlegesen növelhető - csökkenthető az adott gép igényeinek megfelelően.

Szóval, igazából egy LOD-QuadTree jött létre, némileg egyszerűsített megoldásban, és úgy néz ki, hogy ez abszolút megéri. Rendkívül alacsony a számításigénye - az esetek 99%-ában mindössze egyetlen egy IF fut le. Betöltéskor megugrik kicsit a számításigénye, de ezt egy külön szálon végzem, és csupán annyi a feladata, hogy összeállítsa az indexbuffereket, amiket kirajzolnék, és lecserélje a szükséges adatokat.

Illetve, hogy az átmenetel ne legyen nagyon ugrásszerű (és észrevehető) átfedés van a területekben, így míg a fő quad szélét megközelíted, elkezdődik betöltődni az új quad is teljes felbontásban.

Cserébe egy hátrány van: kb 10 másodperccel megdobja a töltési időt, de szerintem ez elfogadható kompromisszum.

Szólj hozzá!

Címkék: optimalizálás lod quadtree

A bejegyzés trackback címe:

https://survivedev.blog.hu/api/trackback/id/tr144313766

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása