Leírás

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Stuff

Anything related to game development.

Contact: darthasylum at gmail dot com

Nemlineáris cikkek

Mi ezeknek a célja?

Leginkább az, hogy magyarul is elérhető legyen programozási anyag, olvasmányos formában.

A cikkek kódja GitHub-ról is elérhető. (*)-al jelölöm azt a cikket ami nemrégiben frissült.

A színek a nehézséget próbálják jelezni, de az, hogy egy cikk piros nem azt jelenti, hogy csak a profiknak szól!

 

 

 

 

 

 

 

 

Hörcsög (Adobe Flash szükséges)

The Asylum

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Friss topikok

Címkék

HTML

Fixed time step refactoring

2013.04.19. 21:58 | darthasylum | 5 komment

Az mindenki számára evidens, hogy a játéklogikát függetleníteni kell a rendereléstől, és ehhez nem elég, hogy 1 / fps-el felszorzol, mert instabil (átugrálsz a falon). Az engine a kezdetektől fogva 10 ups-en updatelte az állapotokat, rendereléskor pedig lineárisan interpolált (ahogy azt kell).

A baj csak annyi, hogy 10 ups-re volt belőve, azaz ha gyorsabban akartam updatelni (pl. az új fizikai engine miatt), akkor minden annyiszor gyorsabb lett. A feladat, hogy legalább az engine által nyújtott animátor független legyen az update rátától is.

Ez egy jó alkalom volt arra, hogy a timert is kicsit átbuheráljam. Double-el számolni jó dolog, de a nagy pontosságú órák minden platformon 64 bites integert adnak vissza; márpedig azzal számolva sokkal pontosabb lehet a logika ütemezése (és remélem, hogy a némely gépeken előforduló periodikus megakadás is megszűnik ezáltal).

Amit meg kell jegyezni, hogy Mac-en az unsigned long 64 bites (ha arra fordítasz), míg windowson nem. Mac-en egyébként az engine most már csak 64 bitre fordul, ezt egy gyenge pillanatomban csináltam meg, mivel az automatic reference counting csak úgy működik (de a leakes problémáimat nem oldotta meg...).

A refactoring első része tehát az ütemezőt érintette, ahol is a double-öket uint64-re cseréltem le. Ez volt a könnyebbik rész... a második rész viszont egy kapitális szopás volt.

Az animátor ugyanis eddig úgy működött, hogy a [0, 1] intervallumot felosztotta N darab részre; azaz létrehozott egy N elemű tömböt és kiszámolta bele az adott polinom értékeit (ezzel diszkretizálva). Az első verzió az volt, hogy ez maradhat, csak akkor nagyobb N-et kell megadni. Alapvetően jó is, de egyrészt fölöslegesen több memória, másrészt az animációk sebessége szemmel láthatóan eltért ha nagyobb volt a ráta.

Ezt tehát full újraírtam úgy, hogy most már időtartamot vár és nem tárol tömböt. Akkor viszont tudnia kell az update rátát. Ami baromira szar, mert eddig mindig olyan helyen inicializáltam, ahol még nem is volt beállítva. Szóval végig kellett verni az egész enginen.

Amit viszont nem csináltam meg, az a konkrétan 10 ups-től függő dolgok. Lusta módon az 1.7-es demóban az időt nem a timerrel mérem, hanem számolom az update tick-eket. Tehát 60 ups-el 6-szor olyan gyorsan telik az idő. De ez alapvetően nem baj, gondoljunk a Prince of Persia-ban az időlassításra: a játék belassul, de az interfész nem! Ezzel kvázi ingyen megoldható (lenne...sajnos a fizika alapból független...).

A bejegyzés trackback címe:

http://darthasylum.blog.hu/api/trackback/id/tr395235700

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.

Gerilgfx 2013.04.27. 01:38:39

én a régi engineben erre frameskipet használtam, az új engineben a fizikai kód tudni fogja a testek régi és új helye közötti interpolálását, amit alapul véve több fázist tud ütköztetni, elkerülendő, hogy az objektum átessen a falon pl. ez még viszont nincs kész, tehát majd csak ha már megírtam, tudok beszámolni arról, hogy a gyakorlatban mennyire hatékony.

darthasylum 2013.04.27. 16:20:02

Amit te mondasz, az a fizikához kapcsolódó dolog; a fix idököz a stabilitás miatt kell, a render közbeni interpoláció pedig a temporal aliasing miatt.

A jelenlegi fizika algebrai úton számolja ki az ütközést, tehát sosem tud átmenni a falon (így nincs szükség ilyen közbenső lépésekre). Persze ez valószínűleg nem mindig lesz megoldható.

Gerilgfx 2013.04.30. 00:18:50

igen, a fizikához, de ez volt az alapfelvetésed. máshoz ilyesmi lényegében nem is igazán kell.

darthasylum 2013.05.01. 01:26:12

De aztán írtam, hogy az speciel független (bár az approximáció miatt más eredményt ad, de az nem érdekes). Eddig más dolgok gyorsabbak lettek (pl. GUI), most viszont azok is rendesen skálázódnak.

És de, kell az máshoz is, pl. a skeletal animation 24 fps-hez tartalmazza a frame infókat, ezek között viszont interpolálni kell (nem is feltétlenül lineárisan, hanem akár Hermite interpolációval).

Gerilgfx 2013.05.02. 16:53:34

én az animhoz nem használtam semmi ilyesmit, de nem volt belőle gond