OctaForge - první 2013 update (diskuse)

[pesspi]

Jak to funguje na Atome? Ja hram OpenArena na nejakych 25FPS a da sa to. Isiel by tento engine na atome?

[----]

No, pokud OpenArena jde na 25FPS, tak na OF zapomeň... oproti quake 3 enginu je OF moderní dynamický engine, který potřebuje relativně slušnou grafiku (aspoň nvidia 8600GT nebo lepší, funguje i na Intel HD4000 celkem slušně (ale ne na HD3000/HD2500/HD2000) a bude fungovat na nových grafikách Haswellu, a funguje i na slušnějších ATInách) a procesor... nutností je OpenGL 2.1 (grafika třídy DX9 se shader modelem 3) a nejlíp OpenGL 3.x (DX10)

[nikt0]

kde si mozem nieco funkcne pre win aj pre linux z tvojej tvorby stiahnut?

[----]

na githubu, ale záleží na tom, co považuješ za funkční :P

[David Watzke]

Respekt, fakt hustý!

[Heron]

Wau

[Ivorne]

No to vypadá tak hezky, že dostávám chuť si s tím pohrát a něco jednoduchého pomocí toho udělat. Jestli tomu dobře rozumím, mělo by to jít normálně použít jako jakýkoliv grafický engine - tedy že ho přilinkuji jako knihovnu a pak pomocí API engine ovládám? Zdáo se mi z předchozích diskusí, že s tím plánuješ poskytovat nějakou službu pro vývojáře her, takže by mě hlavně zajímalo, jestli je to designované i na naprosto stand-alone použití. Prostě jen si to přilinkovat k binárce a nějakým internetem se už nezabývat. Případně se internetem zabývat, ale jenom na svých serverech - tedy jak si to nakonfiguruji/naprogramuji.

Díky

[----]

Nejedná se o knihovnu, ale samostatnou aplikaci. Ovládá se pomocí skriptů psaných v Lua, které engine čte a poskytuje jim API; a standalone použití samozřejmě možné je (resp. v tento moment je jenom standalone).

[Ivorne]

A kdybych měl řekněme nějaký model/simulaci napsanou v C++, který bych chtěl vyobrazit v nějakém enginu - dá se to nějakým podporovaným způsobem zařídit?

[----]

Asi jo, ale záleží na tom, jak je to psaný.. nicméně modely se většinou v C++ nedělají :)

[Ivorne]

No třeba matematické modely, fyzikální modely a další modely chování se podle mě v C++ docela dělají, protože např Lua na to nebude mít tolik výkonu.

[----]

Ajo, ty myslíš tyto modely.. nicméně v OF na to Lua dost výkonu mít bude, protože používám LuaJIT. LuaJIT je asi nejrychlejší dnes používaný JIT, rychlejší než JVM/CLR, rychlejší než V8, v numerických výpočtech rychlejší než gcc, a ve většině reálných věcí stejně rychlý jak gcc.

[----]

gcc -O2 bez věcí jako PGO a LTO, ale to většina lidí nepoužívá...

[Ivorne]

No to mě trochu překvapuje, osobně bych měl za to, že gcc je hodně dobře zoptimalizovaný.

No ale to není tak zásadní. Lua je samozřejmě super jazyk, pro scriptování v enginech je to pro mě osobně číslo jedna. Ale jde o to, že například mám tu simulaci již napsanou v C++ a navíc ji používám i s dalšími nástroji. Holt by se mi zrovna víc hodilo to tam hodit jako c++.

[----]

Tak v tom případě si budeš muset najít nějakou 3D knihovnu a udělat to v tom - pokud už ta simulace je napsaná, tak to stejně potřebuješ jen vyrenderovat, bez těch věcí kolem toho (zvuk, fyzika apod.)

OF je spíš určený k psaní her a simulací až potom (a když už, tak přímo v Lua). Samotný engine je psaný v C++, ale C++ API nemá.

A ano, gcc je slušně zoptimalizované, ale to LuaJIT taky a už dávno neplatí, že JIT kompilátory by měly být pomalejší, než AOT (LuaJIT je trasující JIT a díky tomu si umí "vydolovat" dost informací z toho, co má a výsledek dobře zoptimalizovat, včetně věcí jako odstranění heap alokací apod. - viz. http://wiki.luajit.org/Optimizations)

[deda.jabko]

OF je spíš určený k psaní her a simulací až potom (a když už, tak přímo v Lua). Samotný engine je psaný v C++, ale C++ API nemá.

A nebylo by reseni pouzit FFI, ktere pouziva Lua?

[----]

FFI můžeš použít k zařazení cizích knihoven, ale nelze udělat z OF přímo tu knihovnu.

[deda.jabko]

Pokud muzes prilinkovat knihovnu, tak by v tom nemel byt problem. V podstate jde jen o to, ze ,,main()'' nebude v jeho programu, ale bude v OF a bude nejakym zpusobem komunikovat s pripojenou knihovnou.

[----]

Jistě - přes FFI se dá v OF volat jakákoliv C knihovna z Lua. Časem toto bude nicméně pro většinu skriptů zakázané a bude se dát použít jen u "standalone" her a v "trusted" skriptech.

[dumblob]

Nemam slov - v oboru grafiky se moc veci promakanych ve vsech smerech nevidi (a to ani komercnich). Vzdycky jsem nasel nejakou neprijemnou slabinu, ktera se resila obezlickami a hacky, ale tady to vypada jako v raji.

Opravdu moc hezke! Jen tak dal!

[----]

Co se týče grafiky, tak ta je spíš zásluhou enginu Tesseract; já spíš dělám tu skriptovací část, resp. možnost v tom něco tvořit, protože Sauerbraten/Tesseract jsou spíš přímo hry.

[dumblob]

Mel jsem na mysli obor grafiky a tedy vse co k "ciste" grafice neodmyslitelne patri (tzn. presne to, co popisujes a par dalsich veci jako sit, GUI, apod.).

[----]

Btw, tady je taky pár slabin - hlavně to, že nelze mít více vrstev průhlednosti - viditelná bude jen jedna (s výjimkou vody viditelné přes sklo/alpha materiál) a nelze mít realtime ne-screenspace odrazy (takže odrážet se bude jen to, co je na obrazovce, jinak statické odrazy odráží vše) - to už jsou holt omezení deferred rendereru... zase nazpět poskytuje možnost mít mnoho dynamických světel bez toho, aby to bylo moc pomalé...

[Bedňa]

Budeš riešiť aj také veci, ako je fyzika objektov? A aby sa mapa dala s tankom zrovnať na rovinu? :)

[----]

fyzika - ano, destrukce map - ne

[Bedňa]

Nemyslel som priamo terén, ale budovy atď.

[----]

v tom není žádný rozdíl z technického hlediska, kdyby něco tak u budov je to ještě složitější