aruslan
>скажи мне, что такое ресурс менеджер
typedef std::string resource_name_t;
std::map<resource_name_t, shared_array<unsigned char> > / пачка std::map<resource_name_t, shared_ptr<T> >
(С моей кочки зрения).
Далее, можно к этому добавить fetch, что бы заранее сказать, что мы хочем загрузить и через какое время, что бы можно было грамотно спланировать чтения с диска.
можно к этому добавить хитрую политику удаления - удаляем не сразу, как (0 == --ref_count) а через минуту.
Но это всё добавления.
То есть - с моей точки зрения - ресурс менеджер -- тупой/умный кеш между диском и теми, кто что-то просит ((меш/текстуру)/тупую пачку байтов).
Хм. Написал, и увидел два уровня - который предоставляет тупую пачку байтов и типизированный.
> То есть - с моей точки зрения - ресурс менеджер -- тупой/умный кеш между диском и теми, кто что-то просит ((меш/текстуру)/тупую пачку байтов).
Неправильно. Для этого есть Windows. Про типизированный - другой разговор, но тут тоже я пока не понял, что за resource manager и зачем он нужен.
neteraser
>но тут тоже я пока не понял, что за resource manager и зачем он нужен.
1. Предоставление интерфейса доступа к файловой системе (ОС, архива, etc, etc)
2. Преобразование ресурсов из внешних форматов в форматы движка (.JPEG, .X, .XML, etc, etc)
3. Кэширование декодированых ресурсов в RAM
Это как я себе RM представляю...
D.Rider
Неправильно. Для этого есть Windows
Плюс, возможно, тонкие vfs надстройки, RM никак с ними не связан.
Внешние форматы, это форматы toolset-а, пусть даже in-game, RM никак с ними не связан, имхо.
neteraser
>Неправильно. Для этого есть Windows
Игрок умирает, загружается... Можно читать с диска заново, а можно из кэша...
>Внешние форматы, это форматы toolset-а, пусть даже in-game, RM никак с ними не связан, имхо.
Это правильно, зачем в готовой игре код для декодирования 10-ти форматов изображений, но кто-то должен разобрать файлы с mesh'ами, текстурами, пусть даже они находятся в своем формате, но на диске, и преобразовать их в классы Mesh, Texture и пр. Кто-то должен загрузить, разобрать и, возможно, закэшировать файл настроек, или скрипт, почему не RM?
D.Rider
> Игрок умирает, загружается... Можно читать с диска заново, а можно из кэша...
Что такое кеш? Боюсь на PC я точно ничего не знаю про HDD-cache. Так о чем разговор? И вообще, у нас память и так уже страничная, и со страницами можно вытворять страшные вещи асинхронно (и даже часто очевидно). RM не сможет также, полагаясь, что память плоская (но я готов переубедиться ;).
Если игрок умирает: не понимаю какой при этом происходит процесс? Что читать с диска заново? И вообще что такое читать с диска заново? Я в последнее время все больше верю, что читать с диска - вообще неграмотно (а читать грамотно - очень нетривиально). На Песи, imho, хватит только редкого проецирования c нужным смещением (MapViewOfFileEx) на 1-8 MB вперед; очевидность теряется - ну а кто о ней пекся?
> Это правильно, зачем в готовой игре код для декодирования 10-ти форматов изображений
Вот и я спрашиваю - зачем? ;)
> и преобразовать их в классы Mesh, Texture и пр.
Нельзя путать сериализацию ("Mesh class") и упаковку ресурсов ("Mesh").
neteraser
Так, ладно, сначала.
Сначала выделю ключевые абстракции.
Stream, или raw data - это поток бинарных данных, хранящихся в файловой системе. Может выполнять как разовое чтение, так и блочное (file mapping) - в этом случае кэширование считывания выполняет OS. Мы будем кэшировать другие данные.
Ресурс - контейнер с информацией произвольного характера (Mesh, текстура, вершинная программа, скрипт и пр.), но структурированный для удобного использования, возможно, связанный с конкретным потоком stream (raw data).
Файловая система - хранилище данных (файл, zip архив и пр.)
Кэш - Область в оперативной памяти, в которой хранятся декодированные ресурсы.
Декодер - класс, занимающийся преобразованием ресурса из формата файловой системы в более удобный формат ресурса и начальной инициализацией ресурса (парсер XML, декодер JPEG - создает из бинарного файла текстуру, инициализирует width, height, bpp, внутренний буфер значениями из потока., декодер mp3 - инициализирует значения длительности, битрейта и пр., устанавливает связь с буфером потока)
RM - менеджер, предоставляющий интерфейс для управления остальными классами абстракции.
RM обрабатывает запрсы на получение ресурса из файловой системы в оперативную память и его начальной инициализацией, а возможно и последующим кэшированием.
Например:
Мне нужен файл конфигурации config.xml, этот файл находится в pak архиве. RM выгружает raw data в память с помощью нужной оболочки файловой системы, потом ищет декодер для типа xml, отдает ему raw data, декодер возвращает уже дерево во внутреннем формате движка. RM кэширует данный ресурс в хэш таблице, в качестве ключа используется имя файла. В следующий раз при поступлении запроса на файл конфигурации, ресурс не будет инициализироваться (парситься в данном случае), а возьмется из оперативной памяти.
Мне нужен звук sound.ogg, этот файл находится в файловой системе OS. Но мы указываем, что при создании данного ресурса должен использоваться поток блочного чтения, отображаемый в память. RM создает поток raw data и ищет декодер ogg, после чего декодер возвращает ресурс Sound, проинициализированный необходимыми значениями (битрейт, длина, декодер, поток) этот ресурс помещается все в тот же кэш, с ключем по имени файла. Теперь при следующем обращении к ресурсу, ресурс не будет создаваться и инициализироваться, а будет взят из кэша.
Ресурсы не обязательно кэшируются (это по желанию).
neteraser
>Неправильно. Для этого есть Windows
Windows не панацея.
если мы хотим реализовать непрерывный мир, то по любому ручками придется выгружать и загружать ресурсы, основываясь на хитрых стратегиях.
А кто спорит-то? Просто нельзя смешивать функциональность. И есть стойкое мнение, что RM в том, виде что здесь представлено - это именно и есть ее смешивание.
neteraser
>Просто нельзя смешивать функциональность
Можешь описать функциональность RM в твоем понимании? По пунктам... Так проще будет, а потом поспорим.
Нет такого абстрактного RM, в моем понимании. Есть совершенно различные технологии подгрузки ресурсов. И имеется ввиду не асинхронное чтение из памяти, а правильное предсказание, обработка. А в некоторых случаях из чтение памяти разное!
Я слышал про академичные системы, где все-равно что анимации, что игровая логика. Но я бы такое делать точно не стал. Не на PC.
Кэшируются сущности. Пусть есть набор сущностей A, из который получается сущность B. Если поцесс получения сущности B медленный, то можно ввести сущность C, содержащую набор B. Когда требуется новая сущность B, она сначала ищется в C, находится - берется оттуда, не находится - создается из A. C называется кэшем. Заметим, что ключевым моментом создания кэша является медленный процесс получения сущности B. Этот принцип применяется в том или ином виде в разных вариантах - кэш диска, кэш процессора и т.п. Например разные аллокаторы заменяющие new - тоже кэш. Кэштровать надо сущности, причем пользователю кеш давать нельзя. Вместо этого есть менеджер, который собственно и занимается раздачей попугаев, вот он то и использует кеш. Задача кэша - хранить, менеджера - раздавать. Причем как это делает менеджер пользователя менеджера не волнует. Чем сложней процесс логического получения сущностей, тем умней должен быть менеджер.
Так по классической теории :)
легкий трэш по теме http://www.everfall.com/paste/id.php?3gvsbrfl7e39
Тема в архиве.