LINUX.ORG.RU

Менеджер ресурсов «игровой» поиск реализации/архитектуры

 , , ,


0

2

Продолжаю пилить велосипед.

Вообщем так дошло до управления ресурсами выхода два велосипедить или рыться в сторонних движках.

Предпочитаю первый вариант так как тут не код важен, а архитектура хотя и реализация тоже если найдется будет годно.

При первом варианте думается следующее.

Смотрел как делают велосипедисты на специфичных форумах и абсолютно все сводят к передачи указателя на файл, который и должен использовать пользователь, а работа менеджера сводится к предотвращению дублирования данных и выгрузке не используемых данных.

Может это так принято или удобно разрабам? Обычно делают как передают менеджеру на прямую или косвенно(конфиг например), файл, менеджер регистрирует его выделяет память загружает отдаёт указатель на объект и всё далее сам или по запросу удаляет его и при повторном запросе объекта проверяет есть ли он в индексе своём и если есть снова просто отдаёт указатель на то что уже есть.

Разраб далее работает с указателем как с объектом передавая его туда сюда.

А что если:

Переложить на плечи менеджера загрузку, выгрузку, учёт и помимо этого всего и передачу данных подсистемам.

То есть грузим ---> менеджер регистрирует, грузит, создаёт указатель заносит его в базу генерит идентификатор(просто число int) и отдаёт его разрабу.

Разраб будет иметь просто переменную с идентификатором скажем переменная int monstr. Далее передаёт её скажем рендеру render(monstr,-10,0,0); рендер передаёт значение обратно менеджеру тот ведёт поиск по идентификатору указателя на объект и уже реально передаёт настоящему рендеру косвенно или на прямую производя все необходимые операции.

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

Жду пинков по ссылкам, примерам, статьям.

★★★★★

Ответ на: комментарий от amaora

Ну тут я ещё упорно думаю.

Dron ★★★★★
() автор топика
Ответ на: комментарий от amaora

Менеджер ресурсов у меня (по большей части пока в голове) вырисовывается как эдакий планировщик который берёт данные ведёт их учёт и дёргает подсистемы звук,графика и т.д. передавая им на обработку ресурсы с заданными параметрами.

По мере обдумывания и написания собственно менеджера решил вырезать из него загрузчик и оформить его как вообще отдельную подсистему, которую в свою очередь и будет дёргать менеджер.

Не лучше ли оставить такие вопросы самому рендеру?

Да конечно, работа менеджера сводится к тому чтобы когда нужно что-то отрисовать это было уже готово и сидело в памяти ожидая обращения.

Думая об этом я ещё решил ввести приоритеты ресурсов что должно грузится в первую очередь и что нельзя выгружать, а что выгружать нужно плюс ко всему менеджер ведёт статистику обращений к ресурсу чем чаще обращение тем выше поднимается приоритет и дольше, он сидит в памяти плюс статический приоритет который понизить нельзя.

Dron ★★★★★
() автор топика
Ответ на: комментарий от AIv

Следите за руками. На каждый ID, а каком бы контейнере он не лежал, требуется держать некую структура данных - состояние объекта, тип объекта и т.д. и т.п. У вектора самая большая скорость доступа, памяти под него (под не используемые ID) при известном и разумном числе объектов потребуется немного.

Не много? Ну-ну. Ну а теперь последите и вы за руками. Код символа в юникоде лежит в достаточно большом диапазоне. Вы предлагаете вектор для хранения этого набора. Зачем в векторе те символы, которые не используются в приложении? Каков размер вектора будет в вашем случае?

Про кэширование - ОС лучше Вас знает что и как кэшировать.

Вообще не понял, каким боком тут кеширование на уровне ОС?

а при наличии коллизий по сравнению с вектором аццки тормозит?

От коллизий нужно избавляться. Это же очевидно.

Мне нужны магические решения, которые обеспечивают доступ к хэш таблице с той же скоростью, что и к вектору. У Вас такие еcть?

Я же уже приводил свое решение выше.

andreyu ★★★★★
()
Ответ на: комментарий от x4DA

cast x4DA А не подбросишь примеров использования physfs и вот ещё, он как я понял не может работать с зашифрованными архивами.

Dron ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Не много? Ну-ну. Ну а теперь последите и вы за руками. Код символа в юникоде лежит в достаточно большом диапазоне. Вы предлагаете вектор для хранения этого набора. Зачем в векторе те символы, которые не используются в приложении? Каков размер вектора будет в вашем случае?

А кто и где сказал, что в качестве ID используется код символа??? Те символы которые используются попадают в вектор (добавляются по мере использования). Те которые не используются - не попадают.

Я же уже приводил свое решение выше.

Это с hash%N? Ну и чем это лучше вектора длины N с 0<=ID<N ?

AIv ★★★★★
()
Ответ на: комментарий от AIv

А кто и где сказал, что в качестве ID используется код символа??? Те символы которые используются попадают в вектор (добавляются по мере использования). Те которые не используются - не попадают.

Ага, а в мапке хранится соответствие индекса в векторе коду символа? :)

Это с hash%N? Ну и чем это лучше вектора длины N с 0<=ID<N ?

Тем, что при ID может быть много больше N. Неужели не очевидно?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Ага, а в мапке хранится соответствие индекса в векторе коду символа? :)

Зачем??? ID - непосредственно индекс в векторе.

Тем, что при ID может быть много больше N. Неужели не очевидно?

Не очевидно. Если число ID много больше N имеем коллизии, и rb-tree оказывается быстрее.

AIv ★★★★★
()
Ответ на: комментарий от AIv

Да просто «товарищ не понимает»;-)

Ну пусть так. Мне от вашего мнения холоднее не стало.

Не бывает серебряных пуль, и хэш-таблицы не исключение.

Кто говорил, что хеши - это серебрянная пуля?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Просто я привык по нескольку раз объяснять студентам одно и то же, пока до них не дойдет;-) Меня вот удивляет, что Вы с первого раза не поняли. Или есть какие то прЫнципиальные возражения супротив вектора, не связанные с религией?

Кто говорил, что хеши - это серебрянная пуля?

А зачем же Вы тогда их не к месту лепите? Озвучьте все таки вариант данной задачи, когда хэш будет лучше вектора и лучше rb-tree. Правда интересно.

AIv ★★★★★
()
Ответ на: комментарий от AIv

Вы снова по кругу пошли. Может и студентам вы по нескольку раз поясняете не потому, что они не понимают, а потому, что что то у вас не так?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Вы по делу что нить можете сказать не переходя на личности, или у Вас и это «решается на этапе сборки»? Если нет - до свиданья, слив засчитан.

AIv ★★★★★
()
Ответ на: комментарий от AIv

Вы по делу что нить можете сказать не переходя на личности,

По делу и не переходя на личности я уже несколько раз говорил. Но вы ходите по кругу. Извините, но мне ваш хоровод не интересен, водите его со своими студентами.

или у Вас и это «решается на этапе сборки»?

Читайте выше.

Если нет - до свиданья, слив засчитан.

Вы преподаватель или сантехник, о каких сливах вы говорите?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

По делу

«По делу» Вы ни слова ни сказали о разрешении коллизий, ни слова ни сказали о накладных расходах по разрешению коллизий, упорно считаете что диапазон ID обязательно превышает размер вектора (с чего Вы это взяли мне неясно), и наконец если это действительно так ни слова не сказали о том, как скорость доступа хэш таблицы с учетом разрешения коллизий соотносится с rb-tree.

Вы преподаватель или сантехник, о каких сливах вы говорите?

О Вашем балабольстве в этом треде.

AIv ★★★★★
()
Ответ на: комментарий от wingear

Cube 2(Sauerbraten). Но читая его код, который автор писал, стараясь сделать его как можно минималистичнее (читай: код без комментариев и документации), я начинаю понемногу сходить с ума. Плюс, он заточен на мультиплеер, а я хочу сделать синглплеерную игру. Я начинаю задумываться о велосипеде, который будет использовать irrlicht, SDL, bullet и python (в качестве языка для скриптов). Но что-то заставляет меня пытаться дальше понять код cube 2.

netcat ★★
()
Ответ на: комментарий от netcat

Я начинаю задумываться о велосипеде.

Не надо, да за один массовый редактор стоит пилить дальше, к тому же ты столько времени на него убил, в чём то ты уже разобрался, планы прикрутить assimp и ogre достойны уважения.

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

Dron ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.