resource management, tj. gde i kako smestiti resurse za igru

Eto dosao sam i do tog problema, na netu nisam video konkretan odgovor na pitanje.

Dakle, kada se igra startuje potrebno je u memoriju ucitati sve neophodne resurse (grafiku, zvuk, ...)
Na pocetku ja sam to odradio tako sto bi svaki objekat ucitao svoje resurse , npr: ship->loadResources(); rocket->loadResources(); ....

Onda sam dosao do problema da imam gomilu objekata koji koriste iste resurse, npr. kod
projektila (rocket) imam vektor objekata koji koriste isti sprajt.

Onda sam dosao na "genijalnu" ideju da resursi za takve objekte budu smesteni u static promenljivu (objekat) , koji se inicijalizuje
na pocetku i jedinstven je za sve instance te klase.

Eh, tada sam ukapirao da je sve to glupost i da mi je potreban jedna klasa koja ce da se bakce sa resursima i kojoj
svi objekti mogu da pristupaju - ali kako to da resim?

Nadam se da sam bio jasan i da nisam previse dosadan...

Ja koristim resource manager koji radi samo sa handle-ovima. Handle predstavlja bilo koji resurs (3D model, tekstura, zvuk, itd.) i svaki handle je uvek dostupan čak i ako sami podatci koji predstavljaju resurs nisu učitani.

Pojednostavljeno izgleda ovako:

Ovaj resource manager je ujedno i cache streaming za resurse, tj. ne postoji potreba da ceo nivo bude učitan da bi se iscrtao neki model. Takođe je moguće podešavati količinu memorije koja je dostupna resource cache-u i učitavanje se vrši asinhrono.

Ako više objekata koristi isti resurs, on neće biti učitan više puta, nego će se koristiti isti handle za sve instance resursa.

Potpis

https://github.com/bkaradzic/bgfx

Pa za pocetak mi je samo potrebno da instanca klase CResourceManger bude dostupna svim objektima pa me zanimalo kako to da resim.
Imao sam dve mogucnosti i obe su mi se cinile ruznim:
1) da svakom objektu prosledim pokazivac na instancu resourcemanager
2) da odredjene metode klase CResourceManager ucinim statickim tako da ih mogu pozivati bez inicijalizacije objekta

cini mi se da si ti koristio drugu mogucnost. (?)

Uobičajeno rešenje je singleton pattern, i ako je to jedan od najgorih patterna ikad napravljenih (nije thread safe).
Ne verujem da postoji univerzalno rešenje (još uvek), sve zavisi od ostatka tvog programa kao i namene istog.

A bas sam se nadao da postoji univerzalno resenje, i da nema potrebe za izmisljanjem tople vode.
hmm...priznajem nisam razmisljao o Singletonu za ovu namenu.

dakle: back to laboratory....

Evo jednog resenja:



Kada pravis tvoju klasu, nasledis TSingleton:



Kada jednom napravis instancu klase MyClass, posle joj pristupas:

MyClass::getSingletonPtr(); //pointer

ili

MyClass::getSingletonRef(); //referenca

Ta implementacija singleton-a gore uopshte ne valja, iz mnogo razloga.

Vec je raspravljano na temu singleton-a u C++ forumu na es-u par puta, i generalni zakljuchak je uvek bio isti - prochitash poglavlje u "Modern C++ Design" knjizi i nauchish kako da pravish thread-safe/type-safe singleton.

Nijedno resenje nije savrseno, sve zavisi sta radis i za sta ti treba. Ovo je samo primer jedne od mogucih implementacija Singleton pattern-a.

Sem sto navodis naslov knjige "Modern C++ Design" (svakako cu pogledati), mozes li ukratko obrazloziti zasto ova varijanta Singleton-a "uopshte ne valja"?

www.drizzle.com/~scottb/publish/gpgems1_singleton.htm (otprilike ono sto je dmn trazio)

Kao što Bojan reče, pogledaj C++ forum, tamo ima diskusija o singletonima.
Ovo što si okačio je iz gems-a 1, korišćen je u jednoj domaćoj igri ;)

da to je bas to sto je dmn trazio, a pogotovo mi se svidja deo na kraju :


Hvala

ps: mozda ta implementacija singleton-a gore uopshte ne valja, iz mnogo razloga, ali ce posluziti za prvi pokusaj :)

Ta implementacija je opste poznata i dosta koriscena. Bas kao sto rece tosa pominje se i u "game programming gems 1" kao i na jos mnogo drugih mesta.

Činjenica je da je dosta korišćena implementacija, korišćena je u igri na kojoj smo radili i Bojan i ja,
ali ni jedan od nas je ne bi više upotrebio iz već pomenutih razloga.

1. Shto se tiche resource-a i handle-ova - na ovu temu, vezano za programiranje engine-a, je dosta puta pisano. Prva knjiga GPG-a ima par chlanaka na tu temu. U principu, nema univerzalnog reshenja - koristi ono koje ti najbolje lezhi u konkretnom kontekstu. U "domacoj igri" koju Tosa pominje smo, recimo, koristili object/property manager-e i LUA skriptu za instanciranje objekata i vezivanje resursa za iste.
Ovaj tekstic o handle-ovima je pisao moj prijatelj (fenomenalan game programmer), iako je vec dosta mator (tekst, ne on :) i dalje je prilichno relevantan. Doc fajl na ovoj lokaciji : http://gyurchev.com/docs/resource2.doc

2. Da ne ostanem duzhan odgovora - gornja implementacija, izmedju ostalog, ne valja jer ne koristi nijedan idiom C++a, vec se zasniva na run-time proverama (assert). Ako u Release verziji zaobidjesh assert-check niko ti ne garantuje da necesh imati gomilu instanci tog singletona okolo, u kompletu sa crash-bagovima koje nije lako naci. Sa praktichne strane - zashto ja moram da znam, u trenutku kad mi zatreba instanca singleton-a, da li je on vec instanciran ili ne (jer se singleton inicira u konstruktoru)? Ako pozovem getSingletonPtr() niko mi ne garantuje da cu dobiti validan pointer. Kod singletona ono shto zhelish je da sakrijesh konstruktore i da incijalizaciju izvodish u samoj GetInstance() funkciji. Tu u igru ulazi i thread-safe koncept - odnosno dupli lock koji morash da izvedesh tokom samog instanciranja. Scott Meyers je pisao na temu thread-satefy u singletonu, a Alexandrescu je razradio koncept do kraja.
Na kraju, sa strane sw dizajna - ne valja prisiljavati nekog da koristi nasledjivanje ako ne zheli (hint: prochitati shta chika Herb Sutter ima da kazhe na temu sw dizajna u C++u). Taj templejt je moguce zamotati okolo klase, tako da od svake klase mozhesh da napravish singleton bez potrebe da menjash vec jednom napisanu klasu.

Da, konkretan slucaj moze da favorizuje i ovo sto si napisao:

1) da svakom objektu prosledim pokazivac na instancu resourcemanager

Na primer u logickoj slagalici ( kao bejeweld ) koristio sam ovaj nacin i pravo da ti kazem navukao sam se :) Meni je bilo malo ruzno u pocetku, ali na taj nacin objekat moze sam da vodi racuna o sebi. Isto i sa random generatorom, pa novom obliku koji upada u slagalicu prozoves:

Jewel->Spawn();

Jewel sam cekira random, dobije novi ID, onda na osnovu njega zatrazi teksturu i to je to, zeleni dijamant postaje plava kuglica, bez da mu se to "od gore" servira.
Isti sistem koristim i za linijice koje trenutno radim.



P.S. Pitanja ti uopste nisu dosadna, stavise...

problem sam resio sa Singleton klasom:

dakle moja CResourceManager klasa samo nasledi pomenutu singleton klasu i inicijalizujem objekat resourceManager negde na pocetku main() programa,
zatim u definiciji svake klase gde su mi potrebni resursi ukljucim sledece dve linije:



i mogu da slobodno pristupam resursima u okviru te klase, npr ovako :



jeste znam da su iskusniji developeri leepo rekli da ovakav pristup ima mane, i ja sam to primio K znanju, i zahvalan sam na savetima i komentarima.
Pozdrav

Svaka implementacija ima svojih prednosti i mana. Bitno je prepoznati koja najbolje resava konkretan problem. Resenje koje nudi Scott Bilas je elegantno i prihvatljivo u vecini slucajeva.

Singleton pattern je jedan od najjednostavnijih patterna i ne vidim da nudi previse prostora za diskusiju. Predlazem da nastavis sa pitanjima oko problema koje prepoznajes u svom projektu. Tako cemo mozda zapoceti mnogo bogatije diskusije oko: Observer, State Machine, Memento, Strategy, Prototype ... i ostalih patterna koji su svakako zanimljiviji od trivijalnog Singletona.

BTW
Zasto #define ResourceMgr CResourceManager::getSingletonPtr() ne ubacis u CResourceManager.h?

Singleton je sve samo ne trivijalan, but I digress

U odnosu na neke druge jeste.