Менеджери ресурсів - чи корисні вони?


20

Я багато разів бачив у вихідному коді подібні речі [ну, це більше псевдо C ++ ідея мого]

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

Мені було просто цікаво, наскільки корисним був такий клас, що таке:

  • Завантажені медіа-файли
  • Зберігав їх у пам’яті
  • Зробив це на початку рівня завантаження екрана.
  • Прибраний

Замість того, щоб мати систему:

  • Ресурси утримуються лише суб'єктами господарювання або є вільними.
  • Відповідає за власне завантаження в пам'ять.

Перший - це «менеджер» як такий; те, що я відчуваю, вказує на неправильне використання. Однак це дозволяє передавати щось на зразок вектора імен ресурсів, а не потрібно намагатися шукати все, що потрібно завантажити.



1
Не зовсім. Я думаю, що це справедливе питання.
Ricket

Не зовсім, але схожі області та подібні плюси / мінуси. Але є речі, які ви зробили б із менеджером, які ви не зробили б із маніфестом. Маніфести - це німі речі, які просто збирають неоднорідні ресурси в єдиний індекс. Менеджер ресурсів може нести набагато більше відповідальності та краще взаємодіяти з ігровим двигуном.
MrCranky

Я не думаю, що я прошу те саме. Це, здається, запитує, чи маєте ви мати якесь скорочення файлових шляхів, тоді як я запитую щось про тип завантажувача ресурсів / типу кешу. Однак я думаю, що це не з'явилося в сенсі, оскільки я використовував ресурс, а не актив.
Качка комуністична

2
@ Брайан, я не погоджуюсь, "чи є менеджери активів гарною ідеєю" - це питання, який є іншим, ніж "як ви реалізуєте менеджерів з активів". Зрозуміло, деякі люди намагалися відповісти на перше запитання на друге питання, що спричинило б багато відповідей, що збігаються.
Тетрад

Відповіді:


20

Хороший менеджер ресурсів є ключовим для того, наскільки добре - і наскільки гнучким буде ваш двигун гри.

Це не тільки вирішує багато проблем із управлінням ресурсами низького рівня, але також допомагає забезпечити завантаження ресурсів лише один раз, а потім повторно використане, якщо вони вже завантажені.

Якщо ресурсна система добре абстрагована, деталі, що лежать в основі, можуть побоюватися між файловою системою, зберіганням фізкультур, sql навіть ...

Ви просто вимагаєте ресурс, і він вам видається.

Не потрібно турбуватися про ідентифікатори ресурсів та подібні речі.

Повторне вирішення конфліктів з ресурсами тощо.

Нехай менеджер ресурсів розбере це.

Залежно від того, як ви його розробляєте - якщо C ++, то подружиться з вашими класами управління сценами, щоб переконатися, що право власності належним чином обробляється.

Пул ресурсів?

Без проблем.

Забули звільнити ресурси?

Без проблем.

Той самий інтерфейс до ресурсів, де б вони не були: пам'ять, диск, архів, мережа.

Без проблем.

Ви хочете потоково?

Нитки?

Нехай ваш центр управління ресурсами подбає про це.

Ви можете бути впевнені, що він повідомить вас, коли ресурси будуть готові до використання.

Ogre 3D має дуже гнучку систему управління ресурсами, але я впевнений, що є і інші "там".


1
Я повинен подякувати вам за цю відповідь. Я не переконався в корисності виділеного менеджера ресурсів до того, як прочитав це, і зараз я його впроваджу дуже скоро.
Джейк МакАртюр

13

Нещодавно я написав менеджер ресурсів, який працює досить добре для мого випадку. Основні риси:

  • Ресурси запитуються рядки ID, наприклад, ResourceManager::instance().getTexture("textures/player.png"). На даний момент текстурний ідентифікатор відображається прямо у файл на диску, що зручно під час розробки, але це згодом буде замінено пошуком у деякому архіві.

  • Менеджер ресурсів тримається на карті ідентифікаторів до ресурсів, тому не завантажує вже завантажений ресурс.

  • Вищезазначений виклик не повертає Textureоб'єкт, а швидше Resource<Texture>об'єкт; Очікується, що абонент повинен зберігати Resource<Texture>об'єкт, а не фактичну текстуру. Resource<Texture>Діє як смарт - покажчик на об'єкт Texture; його operator*()повертає сам Textureоб’єкт. Перевага полягає в тому, що фактичну текстуру можна перезавантажувати або вивантажувати, не потребуючи оновлення всіх клієнтів.

  • Менеджер ресурсів періодично перевіряє, чи змінилися файли на диску, і при необхідності перезавантажує їх. Це дозволяє мені змінювати текстури або шейдери і бачити результат, навіть не перезавантажуючи гру.

  • Ресурси можуть залежати один від одного. Більшість, якщо не всі, ресурси залежать від Fileресурсу, який є файлом, з якого вони були завантажені. Якщо, наприклад, модель залежить від текстури, модель буде перезавантажена щоразу, коли файл текстури зміниться на диску.

  • Якщо ресурс неможливо знайти або не вдасться завантажити, ресурс за замовчуванням тихо підміняється. Це дозволяє мені використовувати ресурси, які я ще не створив, без збоїв у грі. (Планована функція: вкажіть "основні" ресурси, такі як шейдери GPGPU, без яких гра взагалі не може належним чином працювати.)

  • Підрахунок довідок та вивантаження невикористаних ресурсів можна легко додати. Оскільки моя гра досить мала, я ще не потребував цього.

Я думаю, що цей список функцій показує, що так, менеджери ресурсів можуть бути хорошими!


2

Однією з причин наявності менеджера ресурсів є обмін ресурсами. Наприклад, коли ви телефонуєте resourceManager.Get("sprite.png"), якщо "sprite.png" вже завантажений, менеджер ресурсів може просто повернути вказівник на вже завантажений ресурс спрайту, а не створити нове зображення та перезавантажити його з диска.

Менеджер ресурсів також може кешувати ресурси, так що, хоча остання посилання на ресурс була відхилена, менеджер ресурсів може вибрати, щоб він зберігав його в пам'яті, якщо він найближчим часом знову завантажиться. Менеджер ресурсів буде запрограмований так, щоб автоматично обробляти все управління пам'яттю вашими ресурсами.

Нарешті, я вважаю, що дуже корисною функцією є завантаження ресурсів у грі. Оскільки менеджер ресурсів підтримує обробку всіх ігрових ресурсів, ви можете побудувати функцію, яка змушує перезавантажувати всі ресурси з диска та оновлювати гру в режимі реального часу, що надзвичайно корисно для художників / дизайнерів, які працюють з вашою грою .


1

Ще одна перевага, окрім кешування та підрахунку посилань, полягає в тому, що він може вирішувати залежності (модель потрібна текстура b? Я отримаю це для вас!) Та задавати замовлення (модель потрібна, щоб знати, що потрібно шейдер b? Дозвольте завантажити шейдер b перед завантаженням моделі!)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.