Архитектура движка.Форум

Resource Manager (2 стр)

Страницы: 1 2
#15
20:49, 23 янв 2006

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) а через минуту.

Но это всё добавления.

То есть - с моей точки зрения - ресурс менеджер -- тупой/умный кеш между диском и теми, кто что-то просит ((меш/текстуру)/тупую пачку байтов).

Хм. Написал, и увидел два уровня - который предоставляет тупую пачку байтов и типизированный.

#16
9:28, 24 янв 2006

> То есть - с моей точки зрения - ресурс менеджер -- тупой/умный кеш между диском и теми, кто что-то просит ((меш/текстуру)/тупую пачку байтов).
Неправильно. Для этого есть Windows. Про типизированный - другой разговор, но тут тоже я пока не понял, что за resource manager и зачем он нужен.

#17
12:49, 24 янв 2006

neteraser
>но тут тоже я пока не понял, что за resource manager и зачем он нужен.
1. Предоставление интерфейса доступа к файловой системе (ОС, архива, etc, etc)
2. Преобразование ресурсов из внешних форматов в форматы движка (.JPEG, .X, .XML, etc, etc)
3. Кэширование декодированых ресурсов в RAM
Это как я себе RM представляю...

#18
15:52, 24 янв 2006

D.Rider
Неправильно. Для этого есть Windows

Плюс, возможно, тонкие vfs надстройки, RM никак с ними не связан.
Внешние форматы, это форматы toolset-а, пусть даже in-game, RM никак с ними не связан, имхо.

#19
19:03, 24 янв 2006

neteraser
>Неправильно. Для этого есть Windows
Игрок умирает, загружается... Можно читать с диска заново, а можно из кэша...

>Внешние форматы, это форматы toolset-а, пусть даже in-game, RM никак с ними не связан, имхо.
Это правильно, зачем в готовой игре код для декодирования 10-ти форматов изображений, но кто-то должен разобрать файлы с mesh'ами, текстурами, пусть даже они находятся в своем формате, но на диске, и преобразовать их в классы Mesh, Texture и пр. Кто-то должен загрузить, разобрать и, возможно, закэшировать файл настроек, или скрипт, почему не RM?

#20
22:17, 24 янв 2006

D.Rider
> Игрок умирает, загружается... Можно читать с диска заново, а можно из кэша...
Что такое кеш? Боюсь на PC я точно ничего не знаю про HDD-cache. Так о чем разговор? И вообще, у нас память и так уже страничная, и со страницами можно вытворять страшные вещи асинхронно (и даже часто очевидно). RM не сможет также, полагаясь, что память плоская (но я готов переубедиться ;).

Если игрок умирает: не понимаю какой при этом происходит процесс? Что читать с диска заново? И вообще что такое читать с диска заново? Я в последнее время все больше верю, что читать с диска - вообще неграмотно (а читать грамотно - очень нетривиально). На Песи, imho, хватит только редкого проецирования c нужным смещением (MapViewOfFileEx)  на 1-8 MB вперед; очевидность теряется - ну а кто о ней пекся?

> Это правильно, зачем в готовой игре код для декодирования 10-ти форматов изображений
Вот и я спрашиваю - зачем? ;)

> и преобразовать их в классы Mesh, Texture и пр.
Нельзя путать сериализацию ("Mesh class") и упаковку ресурсов ("Mesh").

#21
16:37, 25 янв 2006

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, проинициализированный необходимыми значениями (битрейт, длина, декодер, поток) этот ресурс помещается все в тот же кэш, с ключем по имени файла. Теперь при следующем обращении к ресурсу, ресурс не будет создаваться и инициализироваться, а будет взят из кэша.

Ресурсы не обязательно кэшируются (это по желанию).

#22
16:38, 25 янв 2006

neteraser
>Неправильно. Для этого есть Windows
Windows не панацея.
если мы хотим реализовать непрерывный мир, то по любому ручками придется выгружать и загружать ресурсы, основываясь на хитрых стратегиях.

#23
11:24, 29 янв 2006

А кто спорит-то? Просто нельзя смешивать функциональность. И есть стойкое мнение, что RM в том, виде что здесь представлено - это именно и есть ее смешивание.

#24
11:46, 31 янв 2006

neteraser
>Просто нельзя смешивать функциональность
Можешь описать функциональность RM в твоем понимании? По пунктам... Так проще будет, а потом поспорим.

#25
22:25, 31 янв 2006

Нет такого абстрактного RM, в моем понимании. Есть совершенно различные технологии подгрузки ресурсов. И имеется ввиду не асинхронное чтение из памяти, а правильное предсказание, обработка. А в некоторых случаях из чтение памяти разное!

Я слышал про академичные системы, где все-равно что анимации, что игровая логика. Но я бы такое делать точно не стал. Не на PC.

#26
6:22, 8 фев 2006

Кэшируются сущности. Пусть есть набор сущностей A, из который получается сущность B. Если поцесс получения сущности B медленный, то можно ввести сущность C, содержащую набор B. Когда требуется новая сущность B, она сначала ищется в C, находится - берется оттуда, не находится - создается из A. C называется кэшем. Заметим, что ключевым моментом создания кэша является медленный процесс получения сущности B. Этот принцип применяется в том или ином виде в разных вариантах - кэш диска, кэш процессора и т.п. Например разные аллокаторы заменяющие new - тоже кэш. Кэштровать надо сущности, причем пользователю кеш давать нельзя. Вместо этого есть менеджер, который собственно и занимается раздачей попугаев, вот он то и использует кеш. Задача кэша - хранить, менеджера - раздавать. Причем как это делает менеджер пользователя менеджера не волнует. Чем сложней процесс логического получения сущностей, тем умней должен быть менеджер. 
Так по классической теории :)

#27
14:05, 8 фев 2006

легкий трэш по теме http://www.everfall.com/paste/id.php?3gvsbrfl7e39

Страницы: 1 2
Архитектура движка.Форум

Тема в архиве.