| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
nou
Založen: 28. 07. 2007
Příspěvky: 1051
|
 Zaslal: 4. listopad 2008, 10:10:50 Předmět: |
 |
|
v inom topicu ( http://www.ceske-hry.cz/forum/viewtopic.php?t=1216 ) bolo ze OpenGL si vsetko drzi a teda o manazment zdrojov sa nemusi programator starat. teraz tu je ze sa musi a ze sa to straca. alebo to mam chapat tak ze pri strate kontextu sa strati vsetko nastavenie GL a treba ho nastavit znova. a teraz len pre poriadok straca sa pri tom uplne vsetko teda textury, VBO, shader object teda vsetko co ma nejake OpenGL id?
a dalej este k singletonu. je vhodne ak si vytvorim urcitu triedu CORE ktoru si budem predavat do kazdeho modulu enginu a v nich to budem pouzivat asi tymto systemom.
| kód: |
Core.getTextureManager().Loadtexture();
Core.getGUI().getButton().setText(); |
teda proste urcitu triedu ktora bude sprostredkovavat prepojenie medzi jednotlivimi triedami.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
 |
Quiark
Založen: 29. 07. 2007
Příspěvky: 816
Bydliště: Chlívek 401
|
| Zaslal: 4. listopad 2008, 10:24:15 Předmět: |
|
|
Na to uz jsme odpovedeli. Tak jeste jednou - to core bude jeden velky singleton, takze to bude prinaset vsechny jeho nevyhody a navic do nej budes mit nutkani casem davat kde co, takze v podstate cesta do pekla 
_________________
Mám strach |
|
| Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007
Příspěvky: 1537
Bydliště: u Prahy
|
| Zaslal: 4. listopad 2008, 13:31:35 Předmět: |
|
|
OpenGL vsechno manazuje, ale kdyz zrusis OpenGL kontext, tak jej proste zrusis  (ve Windows se pri zruseni okna zrusi logicky i OpenGL kontext v nem). Je to stejne, jako kdyz ukoncis svoji aplikaci, jeji pamet taky ztratis.
Zakladem tedy je okno nerusit, jen mu zmenit velikost - pak OpenGL funguje dal. Z vlastni zkusenosti, problem je jen, kdyz zmenite barevnou hloubku (to pak ne vsechny ovladace grafiky rozdejchaj). Ted neresim, jak je to realizovane v SDL, nemam ted cas se na to podivat.
_________________
Award-winning game developer |
|
| Návrat nahoru |
|
|
nou
Založen: 28. 07. 2007
Příspěvky: 1051
|
| Zaslal: 4. listopad 2008, 13:55:50 Předmět: |
|
|
ok tak som skusil SDL. po zavolani SDL_SetVideoMode() sa strati kontext - treba loadovat textury. ale ked pride sprava SDL_VIDEORESIZE treba upravit perspektivu v OGL a potom spravit tento hack
| kód: |
surface->w = event.resize.w;
surface->h = event.resize.h; |
bez tohoto sa okno sprava ako keby malo svoje stare rozmery pri zachytavani SDL_MOUSEMOTION, SDL_MOUSEBUTTON funguje aj bez toho. takto sa da zmenit velkost aj v SDL bez straty kontextu. ale pri prepinani z/do fullscreenu sa tomu nevyhneme kedze SDL_ToogleFullscreen() funguje iba na X11 a experimentalne na MacOS. na win to asi nikdy nebude.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
|
VODA
Založen: 29. 07. 2007
Příspěvky: 1721
Bydliště: Plzeň
|
| Zaslal: 6. listopad 2008, 07:11:34 Předmět: |
|
|
Abych se vrátil k našemu panu singletonu...
Pořád jsem přemýšlel, jak udělat to, aby se texturovací manager vytvořil jen jednou...teď jsem ale vymyslel něco jiného, nevím jestli lepšího, ale jiného...
V deklaraci třídy vytvořím dva statické atributy...jedno pro uložiště (datový kontejner vector, který ukládá cestu, název textury a index vrácený Opengl) a druhý pro počet přístupů k uložišti...
Díky tomu, že budou atributy private, tak se k nim dostanu jen skrz třídu....
Při každém vytvoření třídy TEXTURELIB se v konstruktoru přičte k této přístupové hodnotě jednička, v destruktoru se naopak odečte...a dále se v destruktoru zjistí jestli už přístupová hodnota náhodou není = 0... pokud ano je čas vymazat textury z paměti, protože neexistuje žádný vytvořený manager...
Pokud samozřejmně vytvořím někde další (po smazání všech předchozích) tak manager bude fugovat dále, ale textury se musí načíst znovu...
Nevím jestli to není opět jen "ochcání" singletonu...ale zamezilo by to tomu, že se budou textury v paměti opakovat...a nebude použit singleton pattern
A navíc to bude fungovat tak, že se objekt zničí tam kde byl vytvořen...jak jste psali...
No a jak udělat ve Win to s tou změnou rozlišení ve Fullscreenu...
Prostě jenom když přijde příkaz do rendereru, že má změnit rozlišení, tak vymaže všechny textury z paměti (ale ne odkazy v manageru), změní context a podle dat v manageru opět textury načte...
_________________
Opravdovost se pojí s trýzní... |
|
| Návrat nahoru |
|
|
Augi
Založen: 28. 07. 2007
Příspěvky: 782
Bydliště: Čerčany
|
| Zaslal: 6. listopad 2008, 07:59:41 Předmět: |
|
|
Já jsem TextureManager vždy řešil tak, že byl právě jeden pro každé zařízení (nějaká třída Device, kterou jsem si všude předával pomocí parametrů). TextureManager měl pak především metody LoadFromFile(string) a Release(Texture). LoadFromFile se nejprve podívala do nějaké hash table, jestli není textura už naládovaná a v takovém případě by metoda vrátila existující objekt Texture. Metoda Release pouze snížila counter u dané Textury a pokud hodnota dosáhla nuly, došlo k jejímu uvolnění (v destruktoru by bylo už moc pozdě rozhodovat jestli zrušit/nezrušit objekt).
Samozřejmě je možné parametrizovat nejen jménem textury, ale také dalšími nastaveními. Jo a před ukládáním file name textury doporučuju tu cestu normalizovat (např. na full path). |
|
| Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007
Příspěvky: 2156
|
| Zaslal: 6. listopad 2008, 09:09:45 Předmět: |
|
|
| VODA napsal: |
| Při každém vytvoření třídy TEXTURELIB se v konstruktoru přičte k této přístupové hodnotě jednička, v destruktoru se naopak odečte...a dále se v destruktoru zjistí jestli už přístupová hodnota náhodou není = 0... pokud ano je čas vymazat textury z paměti, protože neexistuje žádný vytvořený manager... |
skvele objevil jsi neco cemu se rika reference counting  |
|
| Návrat nahoru |
|
|
Augi
Založen: 28. 07. 2007
Příspěvky: 782
Bydliště: Čerčany
|
| Zaslal: 6. listopad 2008, 10:59:17 Předmět: |
|
|
| No IMHO je hezčí si na to přijít sám než přijmout cizí myšlenku jako dogma |
|
| Návrat nahoru |
|
|
quas4
Založen: 18. 10. 2007
Příspěvky: 199
|
| Zaslal: 6. listopad 2008, 12:32:49 Předmět: |
|
|
bez ref-countingu (princip je podobny s tim co psal Augi):
| kód: |
.cc
typedef std::map<long, Resource*> res_map;
typedef res_map::iterator res_it;
static res_map textures; // ... a dalsi
template<typename T>
T* fetch_resource(res_map& map, const std::string& name)
{
if (name.empty()) return 0;
const long name_h = hash_str(name); // custom funkce (optimalizace)
res_it it = map.find(name);
T* res;
if (it == map.end()) {
res = new T(name);
map[name_h] = res;
} else res = (T*)it->second;
if (! res->valid()) return 0; // neni-li nahozen bool Resource::loaded zkusi nacist
return res;
}
Texture* resource_texture(const std::string& tex_filename) // definice v header
{
return fetch_resource<Texture>(texture_map, tex_filename);
}
void resource_textures_cleanup() // definice v header
{
// u vsech prvku v texture_map zavola Texture::unload()
// a pripadne promazne cele texture_map
}
// a obdobne treba:
// Sound* resource_mesh(const std::string& sound_filename)
// {
// return fetch_resource<Sound>(sound_map, sound_filename);
// }
|
Mesh ma tedy napr. difuzni texturu v std::string a pri kazdem vykresleni zavola resource_texture(diffuse_map) + setup vracene Texture* v rendering pipeline.
Prubezne uvolnovani (mazani textur) neni imho potreba. O to se postara driver (opengl) ktery obvykle implementuje LRU. Pred kazdym kolem/levelem se jen zavola resource_texture_cleanup() - zalezi uz na konretni hre. Cely algoritmus se samozrejme nehodi na hru ktera se napr. odehrava v rozsahle mape (mesto) a v takovem pripade je potreba vyrazne slozitejsi system cachovani..
k tematu threadu: jsem dost velkym odpurcem design patterns. Plne se ztotoznuju s nazorem:
http://realtimecollisiondetection.net/blog/?p=44
http://realtimecollisiondetection.net/blog/?p=81 |
|
| Návrat nahoru |
|
|
VODA
Založen: 29. 07. 2007
Příspěvky: 1721
Bydliště: Plzeň
|
| Zaslal: 6. listopad 2008, 20:44:33 Předmět: |
|
|
| rezna napsal: |
| skvele objevil jsi neco cemu se rika reference counting |
Já rád vymýšlím věci, které už někdo jednou vymyslel...
_________________
Opravdovost se pojí s trýzní... |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 6. listopad 2008, 20:55:56 Předmět: |
|
|
quas4> Pěknej kód, trochu tam vidím podobný princip jak u sebe. Ten reference counting se tam jinak ale hodí, viz níže.
| quas4 napsal: |
| Cely algoritmus se samozrejme nehodi na hru ktera se napr. odehrava v rozsahle mape (mesto) a v takovem pripade je potreba vyrazne slozitejsi system cachovani.. |
Právě kvůli tomuto bych teda osobně nedoporučil psát engine, který naráz uvolní všechno a pak načte něco jinýho. Většina moderních her má tak složitej svět a tak málo paměti (256MB nebo 512MB na Xbox360 sdílená mezi CPU a GPU!), že zobrazování scény by se sesypalo bez neustáleho mazání a loadování nových dat. Taky je poslední dobou moderní dělat plynulou hru bez mezi-loadingů.
Pěkné čtení, nicméně mi přijde přehnané srovnávat design patterns s metodikou učení se na zkoušku.
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava
|
| Zaslal: 6. listopad 2008, 21:00:07 Předmět: |
|
|
Ad LRU v OpenGL driveru - to není dobrej příklad, protože při nedostatku paměti ve VRAM jde výkon stejně do kytek a všechny textury se stejně mirrorují v RAM a tam to zabírá místo zbytečně.
_________________
AMD Open Source Graphics Driver Developer |
|
| Návrat nahoru |
|
|
VODA
Založen: 29. 07. 2007
Příspěvky: 1721
Bydliště: Plzeň
|
| Zaslal: 10. prosinec 2008, 15:22:11 Předmět: |
|
|
Nevím jestli to stále patří sem, ale to co napíši nemá k tématu určitě daleko. Jde o to, že chci poskytnout uživateli (mně ) standartní funkce...trochu jsem hledal a našel jsem na microsoftích msdn, že math v C# je statická třída a math v VC++ je třída se statickými metodami...
Samozřejmě pak lze v programu napsat někde MATH::cos(d)...(teď mluvím o VC++)...svoje matematické funkce pro práci s vektory mám navrženou stejně, jde ale o to, jestli je to v rámci OOP správně...v knížce "OOP bez předchozích znalostí", že statické metody se využívají...
Teď by mě ale zajímalo, jaký na to máte názor...
Je to banalita, ale přece jenom mám napsáno v popisu mé maturitní práce, že jde o OOP návrh...
Takže díky...
_________________
Opravdovost se pojí s trýzní... |
|
| Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007
Příspěvky: 2156
|
| Zaslal: 10. prosinec 2008, 15:41:07 Předmět: |
|
|
v C# jinou sanci ani nemas - tam se musi vsechno schovat za objekt - v C++ muzes vyuzit klasickych globalnich metod, ale to uz nesplnuje OOP zapouzdreni, takze ti nejspis po formalni strance nic jineho nez trida Math se statickymi metodami nezbyva
singleton tu povazuju za zhovadilost - staticka metoda by mela byt rychlejsi |
|
| Návrat nahoru |
|
|
Yossarian
Založen: 28. 07. 2007
Příspěvky: 274
Bydliště: Šalingrad
|
| Zaslal: 10. prosinec 2008, 16:35:40 Předmět: |
|
|
| Ono, ciste prakticky a objektove, by mela v c# byt trida Math extension typu int/double, tzn. misto Math::Cos(PI) bys psal PI.Cos() .. |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
