.[ ČeskéHry.cz ].
SceneGraph
Jdi na stránku Předchozí  1, 2, 3
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
perry



Založen: 28. 07. 2009
Příspěvky: 870

PříspěvekZaslal: 19. leden 2015, 08:18:24    Předmět: Odpovědět s citátem

citace:
Aky zmysel ma aby vsetky komponenty mali spolocneho predka?


Třeba ten, abych nemusel psát určitý kód na X místech pořád dokola. Není to úplně interface, je to abstraktní metoda, nicméně v C++ stejně interface jako takový úplně není.

citace:

2. Volanie virtualnych funkcii
3. Cache missy - kapitola sama o sebe


Tak to by se dalo vyřešit tímhle, ne? http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

citace:
zozeru mi len tieto pointre 4B x 2miliony game objectov = 8MB


Nemyslím si, že 8MB je nějaký podstatný problém v dnešní době.

citace:
Zbavis sa tym sice castovania ale nahradis ho virtual callom a stale budes musiet prechadzat vsetky komponenty.


Virtual call je daleko rychlejší než cast a opět, když to nebrzdí, neřeším to. Jinak proč bych musel procházet všechno? Prostě uvnitř GameObject mám ty ukazatele natypované už správně, pouze metoda AddComponent používá IComponent, vevnitř si to přetypuju a uložím podle typu.

Ty virtual metody ve výsledku moc nepoužívám na volání za běhu, ale spíš místo dynamic_castu, popř. když potřebuju aby uživatel danou metodu skutečně implementovat (např. pure virtual Release())
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Radis



Založen: 29. 03. 2014
Příspěvky: 228

PříspěvekZaslal: 19. leden 2015, 09:49:43    Předmět: Odpovědět s citátem

nem0 napsal:

Momentalne robim na hre, ktora ma cca 2 miliony objektov, 99% z toho su obycajne staticke meshe. Keby sme ich skladovali takymto sposobom, zozeru mi len tieto pointre 4B x 2miliony game objectov = 8MB

Takhle bychom se tady mohli bavit donekonecna. Pro kazdy design najdeme nejaky pripad a nejakou platformu, na kterou to nebude vhodne. To ale prece neznamena, ze je to obecne spatny pristup. (Btw 8 MB je problem? Smile)

nemo napsal:

2. Volanie virtualnych funkcii
3. Cache missy - kapitola sama o sebe

Jeden pozadavek je vykon a druhy pozadavek je udrzovatelnost a citelnost kodu. Opravdu bych nerad zahazoval vymozenosti OOP jako treba dedicnost a programoval strukturalne jen kvuli vykonu Smile Nevolat nic pres interfaces, pouzivat staticke metody, nevolat nic virtualniho - takove veci jsem resil naposledy v J2ME. Ted mame rok 2015 a clovek se muze dost rozsoupnout treba i na mobilech, jak co se tyce pameti, tak vykonu.

Samozrejme zalezi na konkretnim pripadu, jen bych to takhle nezobecnoval.

Ano, cache-missy jsou kapitola sama o sobe, ale ne kazde virtualni volani zpusobi cache-miss a naopak prime volani funkce taky muze zpusobit cache-miss.

nemo napsal:

4. nemoznost prisposobovat si sposob prace s danym komponentom - plne ine potreby ma mesh component, ktory je na ~99% objektov, a ine camera component, ktory je na ~0.1%

Jak konkretne ti zdedeni par metod z bazove abstraktni tridy znemoznuje prizpusobit si zpusob prace s komponentami? Ve spouste enginu to funguje, nechapu problem.

nemo napsal:
samotne Unity vedia, ze je GetComponent pomale

No samozrejme... a v cem je problem? Proste staci to nevolat v kazdem framu, s konceptem cachovani vysledku volani metody jsou snad vetsinou programatori obeznameni Smile

nemo napsal:

alebo child o svojom parentovi Wink

Ano, to v tomto vlakne uz taky padlo.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
nem0



Založen: 23. 03. 2009
Příspěvky: 31

PříspěvekZaslal: 19. leden 2015, 13:46:07    Předmět: Odpovědět s citátem

perry napsal:
Nemyslím si, že 8MB je nejaký podstatný problém v dnešní dobe.

Radis napsal:
(Btw 8 MB je problem? Smile)

Samozrejme vsetko zavisi od toho, aku hru clovek robi a na aku platformu je urcena, ale pokial chces vytiahnut z HW maximum, tak 8 MB moze byt dost (obzvlast ak tychto 8MB vobec netreba). Na starych konzolach (x360, ps3, wii) sme mali "safety buffer", ktory bol velky 1MB. Tento 1MB casto rozhodol o tom, ci sme presli submissionom alebo sme museli zaplatit obrovske peniaze za dalsi. Ano, na stare konzoly sa uz dnes aj tak takmer nerobi, ale este stale su bezne pouzivane mobily s horsim vykonom, ako stare konzoly a hry sa na ne robia. Tych 8 MB nie je len o zabranej pamati, je to aj o 2 milionoch alokacii, ktore nie su zrovna rychle operacie. Je to aj o tom, ze memory tool, ktory zobrazuje vsetky alokacie, ich bude musiet zobrazit o 2 miliony viac, co ho znacne spomali. Pokial si zapnem nejaky memory debug, potom tieto alokacie nebudu mat 8MB ale kludne 80MB a to sposobi ze uz sa dany debug ani nezmesti do pamate. Robil som na projekte, kde takmer neslo pustit debug build kvoli pamati a nie je to nic prijemne. A netreba zabudat, ze dnes uz pointre maju bezne 8B.

perry napsal:
Proste uvnitr GameObject mám ty ukazatele natypované už správne, pouze metoda AddComponent používá IComponent, vevnitr si to pretypuju a uložím podle typu.

Pokial to dobre chapem, tak GameObject vyzera nejak takto?
kód:

class GameObject
{
   ...
   TransformComponent* m_transform;
   MeshComponent* m_mesh;
   RigidBodyComponent* m_rigid_body;
   AnimationComponent* m_animation;
   CameraComponent* m_camera;
   /* Unity ma cca 10 priamych accesorov */
   ...
};

Nie je vacsina tych pointrov nullova? Nevraviac o tom, ze core GameObject vie o veciach, o ktorych by vediet nemal.


Radis napsal:
Opravdu bych nerad zahazoval vymozenosti OOP jako treba dedicnost a programoval strukturalne jen kvuli vykonu

Samozrejme ze zbavovat sa OOP vobec netreba, len na urovni komponentov mi pripada zbytocne. OOP nie je len dedicnost, polymorfizmus, zapuzdrenie, ale aj single responsibility principle, open/closed principle a ine.

Radis napsal:
Jak konkretne ti zdedeni par metod z bazove abstraktni tridy znemoznuje prizpusobit si zpusob prace s komponentami? Ve spouste enginu to funguje, nechapu problem.

Pokial vyrabam komponenty sposobom gameobject->addComponenet(new SphereCullComponent()), tak potom som nuteny mat
kód:

class SphereCullComponent
{
   int m_layer;
   bool m_is_visible;
   Vector3 m_position;
   float m_radius;
};

1. Komponenty su kade tade po pamati
2. Raz naalokovany komponent len tak lahko nepresuniem na ine miesto v pamati
3. Nemusi zodpovedat access patternu - castokrat mi treba skor strukturu poli ako pole struktur
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
perry



Založen: 28. 07. 2009
Příspěvky: 870

PříspěvekZaslal: 19. leden 2015, 13:54:23    Předmět: Odpovědět s citátem

citace:
Pokial to dobre chapem, tak GameObject vyzera nejak takto?


Víceméně Smile Ano, není to ideální.. ale nedělám AAA engine, pro mé potřeby stačí, že to funguje a hlavně je to lehké na správu.

Optimalizovat začnu, až mi začne chybět výkon / paměť, což se imho ještě chvíli nestane. Plus, mám tam horší věci o kterých vím Smile Jako třeba stringová ID - dobré pro debug a pro to na co to hlavně používám, ale pro release a hru už ne tak moc (ale proč to řešit, když mi to zatím nijak nebrzí / neomezuje - viz. YAGNI Smile). Tohle mi žere daleko více paměti, než těch 8MB.
_________________
Perry.cz
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné Časy uváděny v GMT + 1 hodina
Jdi na stránku Předchozí  1, 2, 3
Strana 3 z 3

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna