Menedżerowie zasobów - czy są dobrzy?

Wiele razy widziałem w kodzie źródłowym, takie rzeczy [cóż, to bardziej mój pseudo pomysł C ++]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

Zastanawiałem się, jak przydatna jest taka klasa, coś, co:

• Załadowane pliki multimedialne
• Przechowałem je w pamięci
• Zrobił to na początku ekranu ładowania poziomu.
• Oczyszczone

Zamiast posiadania systemu:

• Zasoby są w posiadaniu wyłącznie podmiotów lub są luźne.
• Odpowiedzialny za własne ładowanie do pamięci.

Pierwszy to „menedżer” jako taki; coś, co czuję, wskazuje, że jest to niewłaściwe w użyciu. Pozwala to jednak na przekazanie czegoś w rodzaju wektora nazw zasobów, zamiast rozglądać się za wszystkim, co trzeba załadować.

Dobry menedżer zasobów jest kluczem do tego, jak dobrze - i jak elastycznie - będzie twój silnik gry.

Nie tylko rozwiązuje wiele problemów związanych z zarządzaniem zasobami niskiego poziomu, ale także pomaga upewnić się, że zasoby są ładowane tylko raz, a następnie ponownie wykorzystywane, jeśli są już załadowane.

Jeśli system zasobów jest dobrze wyodrębniony, podstawowe informacje mogą różnić się między systemem plików, pamięcią physfs, sql, a nawet ...

Po prostu poprosisz o zasób, który zostanie ci przekazany.

Nie musisz martwić się o identyfikatory zasobów i tym podobne.

Obsługa zduplikowanych konfliktów zasobów itp.

Pozwól menedżerowi zasobów to rozwiązać.

W zależności od tego, jak to zaprojektujesz - jeśli C ++ zaprzyjaźnij się ze swoimi klasami scenemanaging, aby upewnić się, że własność jest odpowiednio obsługiwana.

Puli zasobów ?

Nie ma problemu.

Zapomniałeś uwolnić zasoby?

Nie ma problemu.

Ten sam interfejs do zasobów bez względu na to, gdzie się znajdują: pamięć, dysk, archiwum, sieć.

Nie ma problemu.

Chcesz streamować?

Wątki?

Pozwól zająć się tym centrum zarządzania zasobami.

Możesz mieć pewność, że poinformuje Cię, kiedy zasoby będą gotowe do użycia.

Ogre 3D ma bardzo elastyczny system zarządzania zasobami, ale jestem pewien, że są inni.

Niedawno napisałem menedżera zasobów, który działa całkiem dobrze w moim przypadku. Główne cechy:

• Zasoby są wymagane na podstawie identyfikatora ciągu, na przykład ResourceManager::instance().getTexture("textures/player.png"). Identyfikator tekstury jest obecnie mapowany bezpośrednio do pliku na dysku, co jest wygodne podczas programowania, ale później zostanie zastąpione przez wyszukiwanie w niektórych archiwach.

• Menedżer zasobów trzyma mapę identyfikatorów zasobów, więc nie przeładuje zasobu, który został już załadowany.

• Powyższe wywołanie nie zwraca Textureobiektu, ale Resource<Texture>obiekt; dzwoniący ma przechowywać Resource<Texture>obiekt, a nie faktyczną teksturę. Resource<Texture>Działa jak inteligentny wskaźnik do Texture; jego operator*()Zwraca Texturesam obiekt. Zaletą jest to, że faktyczną teksturę można ponownie załadować lub rozładować bez konieczności aktualizacji wszystkich klientów.

• Menedżer zasobów okresowo sprawdza, czy pliki na dysku uległy zmianie, i w razie potrzeby ładuje je ponownie. To pozwala mi modyfikować tekstury lub shadery i widzieć wynik bez ponownego uruchamiania gry.

• Zasoby mogą być od siebie zależne. Większość, jeśli nie wszystkie, zasobów zależy od Filezasobu, którym jest plik, z którego zostały załadowane. Jeśli na przykład model zależy od tekstury, model zostanie ponownie załadowany za każdym razem, gdy plik tekstury zmieni się na dysku.

• Gdy nie można znaleźć zasobu lub nie można go załadować, zasób domyślny zostaje po cichu zastąpiony. To pozwala mi korzystać z zasobów, których jeszcze nie utworzyłem, bez zawieszania gry. (Planowana funkcja: wskaż „niezbędne” zasoby, takie jak shadery GPGPU, bez których gra w ogóle nie będzie działać poprawnie.)

• Liczenie referencji i rozładowywanie nieużywanych zasobów można łatwo dodać. Ponieważ moja gra jest dość mała, nie potrzebowałem tego jeszcze.

Myślę, że ta lista funkcji pokazuje, że tak, menedżerowie zasobów mogą być dobrzy!

Jednym z powodów posiadania menedżera zasobów jest współdzielenie zasobów. Na przykład po wywołaniu resourceManager.Get("sprite.png"), jeśli plik „sprite.png” jest już załadowany, menedżer zasobów może po prostu zwrócić wskaźnik do już załadowanego zasobu sprite zamiast tworzyć nowy obraz i ponownie ładować go z dysku.

Menedżer zasobów może również buforować zasoby, dzięki czemu chociaż ostatnie odwołanie do zasobu zostało usunięte, menedżer zasobów może zdecydować o zachowaniu go w pamięci na wypadek, gdyby został ponownie załadowany w najbliższej przyszłości. Menedżer zasobów zostałby zaprogramowany do automatycznego zarządzania całym zarządzaniem pamięcią przy użyciu zasobów.

Wreszcie, myślę, że bardzo przydatną funkcją jest przeładowywanie zasobów w grze. Ponieważ menedżer zasobów posiada uchwyty do wszystkich zasobów gier, możesz wbudować funkcję, która powoduje, że wszystkie zasoby są ponownie ładowane z dysku i aktualizuje grę w czasie rzeczywistym, co jest niezwykle przydatne dla artystów / projektantów pracujących z Twoją grą .

Kolejną korzyścią jest to, że oprócz buforowania i liczenia referencji jest w stanie obsłużyć zależności (model potrzebuje tekstury b? Otrzymam ją za ciebie!) I problemy z kolejnością ładowania (model a musi wiedzieć, czego wymaga moduł cieniujący b? Pozwól mi załadować moduł cieniujący b przed załadowaniem modelu!)