| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
perry
Založen: 28. 07. 2009
Příspěvky: 879
|
 Zaslal: 19. leden 2015, 08:18:24 Předmět: |
 |
|
| 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 |
|
 |
Radis
Založen: 29. 03. 2014
Příspěvky: 235
|
| Zaslal: 19. leden 2015, 09:49:43 Předmět: |
|
|
| 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?  )
| 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 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
| nemo napsal: |
alebo child o svojom parentovi  |
Ano, to v tomto vlakne uz taky padlo. |
|
| Návrat nahoru |
|
|
nem0
Založen: 23. 03. 2009
Příspěvky: 31
|
| Zaslal: 19. leden 2015, 13:46:07 Předmět: |
|
|
| 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 |
|
|
perry
Založen: 28. 07. 2009
Příspěvky: 879
|
| Zaslal: 19. leden 2015, 13:54:23 Předmět: |
|
|
| citace: |
| Pokial to dobre chapem, tak GameObject vyzera nejak takto? |
Víceméně 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 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 ). Tohle mi žere daleko více paměti, než těch 8MB.
_________________
Perry.cz |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
