LINUX.ORG.RU

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

 , , ,


0

2

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

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

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

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

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

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

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

А что если:

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

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

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

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

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

★★★★★

Я думаю, что int тут ничего разработчику не скажет. Что ты с ним будешь делать? Попробуй лучше запили VFS, как почти во всех играх. Например есть архив с ресурсами, который ты монтируешь в удобный тебе «виртуальный» путь в программе. А ещё я советую не иметь себе мозг с этими вашими указателями, а взять нормальный язык. Сэкономит кучу времени

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

int тут ничего разработчику не скажет

А и не должен, значение есть 'номер' объекта. Отдаём туда сюда,а менеджер рулит ресурсами полностью сам.

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

Ну да, а загруженные данные связывать с каким-нибудь строковым идентификатором. Можно сделать ещё и выгрузку при неиспользовании

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

VFS

Осилить надо, но опять же если нужно что то руками сделать скажем свойства модели задать или сцене целиком всё равно нужно как то управлять отдельно взятыми ресурсами.

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

Можно сделать ещё и выгрузку при неиспользовании

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

Dron ★★★★★
() автор топика

man сборка мусора на основе подсчета ссылок.

На крестах есть всякие смарт-пойнтеры, в С ХЗ но как то тоже делают.

Любое юзание ID подразумевает что у менеджера есть таблица, с разреженными ключами, поиск по которой требует времени. Так делать имеет смысел только если указатели чем то не задались (например объекты сериализуются или передаются по сети) - но тогда это уже монструозная система, разработчики подобных систем подобных вопросов обычно не задают;-)

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

А шо, в Вашем проекте уже памяти катастрофически не хватаеть, и свап не справляется? Зачем Вы пытаетесь делать его работу?

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

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

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

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

(defvar *global-id* 0)
(defun get-id () (incf *global-id*))

то потом хрен программист сможет использовать его ещё раз.

Всё, ожидаем скобкотроллей.

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

Да выгрузка будет приводить к фрагментации базы, её либо упорядочивать что не прокатит либо быстро искать, короче да над этим надо думать.

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

Ничего для образования полезно.

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

Надо экономным быть :)

Ой как надо! И экономить надо в первую очередь собственное время. Без достаточных обоснований подобное велосипедостроение называется «преждевременная оптимизация» и обычно приводит к кардинальной задержке разработки или краху всего проЭкта.

Не надо так делать.

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

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

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

Ну какбе подгрузка уровня по ходу игры подразумевает хранение данных и в памяти и на диске. Всякие деревья для разбиения пространства могут решать проблему подгрузки/выгрузки.

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

Ну я не буду усердствовать очень, учтём спасибо, сейчас даже до кода не дошло, пока только поиск принципов методов и вообще архитектуры.

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

Если человек сделает некий универсальный менеджер ресурсов, то может будет и польза.

amphibrakhij
()

В исходниках cube2 есть файл /docs/dev/readme_developer.txt где Wouter дает некоторые поснения, после которых в движке легче разобраться. Там же написано, что основная цель - сделать движок максимально минималистичным. Поковыряй код, может подчерпнешь что. Плюс, в сборнике книг, который я тебе дал, есть книга Game Engine and Game Design/Game Engine Programming/001GameArchitx.pdf Настоятельно рекомендую прочитать.

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

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

Согласись,что такое:

#define CAR(n) (0xf00|(n))
render (CAR(4));

выглядит хуже, чем

render («car4»);

amphibrakhij
()

А расскажи-ка про твою игру. Что она делает? Может тебе правда взять нормальный язык?

amphibrakhij
()

Тем и хорош ООП, что ответ на такой вопрос даёт сразу ;)

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

Боитесь тратить время на проектирование?

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

А есть ли принципиальная разница между указателем и int в данном случае?

Далее передаёт её скажем рендеру render(monstr,-10,0,0);

Странно, что юнит не хранит информацию о своём положении в пространстве (ориентация+позиция).

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

/docs/dev/readme_developer.txt

Ок гляну.

в сборнике книг, который я тебе дал

2~4 пира до сих пор качаю. Как солью почитаю спасибо.

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

Проектированием пока и занимаюсь.

А есть ли принципиальная разница между указателем и int в данном >случае?

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

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

Поставь высокий приоритет у этой книги.

Уже.

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

Делить не сущности, не смешивать такие сущности как модель, файл модели и юнит, использующий модель; чертить диаграммы сущностей в пределах одной подсистемы.

А ещё в C++ есть смартпойнтеры и перегрузка оператора new.

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

Странно, что юнит не хранит информацию о своём положении в >пространстве.

Ну скажем параметры опциональны, можно и без них.

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

указатель хрен пойми на что

Есть в C++ какие-то смарт-поинтеры, хотя я не знаю, что это такое, и вообще не советую пользовать C++ ;)

Тут главная проблема при отказе от централизированного менеджера - это невозможность переиспользования.

amphibrakhij
()
Ответ на: комментарий от quiet_readonly

не смешивать такие сущности как модель, файл модели и юнит

Именно, я и хочу скрыть всё это внутри менеджера, разрабу останется только рулить именами объектов и всё.

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

не смешивать такие сущности как модель, файл модели и юнит, использующий модель;

Ну это и я говорю и ООП тут не при чём.

> А ещё в C++ есть смартпойнтеры и перегрузка оператора new.

C++ тут будет проблемой, а не средством её решения. C++ сам по себе проблема

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

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

Если объект невовремя удалён, то хоть с указателем, хоть с интом произошла ошибка. Кроме того, указатель является, по сути, ссылкой, и пока ссылку явно не минуснут — менеджер не вправе удалять объект.

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

Разницы между интом и указателем нет, разве что в размере на 64-битных системах.

quiet_readonly ★★★★
()
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от amphibrakhij

и вообще не советую пользовать C++

Всё намного веселей чисто Сишка :) без плюс плюс )))

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

Ну скажем параметры опциональны, можно и без них.

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

В игре может быть 10 лучников, которые имеют один набор анимаций, одну модель, но разные визуальные эффекты вроде горения/крови и разное положение в пространстве. Значит, прототип лучника и лучник — разные вещи.

Кроме того, некоторые движки (такие, как cocos2d-x) вообще не требуют явно вызывать render, объект просто добавляется на сцену и удаляется с неё явно либо путём удаления родительского узла.

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

Разрабу надо рулить юнитом, а не его именем. При этом Ульрих Дреппер и другие рекомендуют не давать явного доступа к структуре GameUnit (раз уж мы говорим о C) и вместо этого создавать функции для изменения тех или иных его параметров; это нужно для возможности изменения полей структуры в будущем без нарушения ABI или API.

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

и пока ссылку явно не минуснут — менеджер не вправе удалять >объект

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

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

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

хотя я не знаю, что это такое
и вообще не советую пользовать C++ ;)

Наверное эти две фразы связаны. И наверное не стоит высказывать своё мнение о C++, не имея достаточной компетенции для таких высказываний. C++ ругать любят, причём даже первоклассные специалисты. Только говорят они при этом чепуху полнейшую, типа «C++ долго компилируется из-за кучи проверок и строгой типизации».

В таких случаях надо просто брать булочку и жевать. И уж ни в коем случае не советовать другим отказаться от C++, хотите гнить — делайте это с собой и других не втягивайте.

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

Тут главная проблема при отказе от централизированного менеджера - это невозможность переиспользования.

Решается на уровне глобальных таблиц в соответствующих порождающих объекты функциях, если это уж так важно.

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

Ок покурю на эту тему.

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

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

Ответ на этот вопрос был в том же посте — можно выгрузить внутренние ресурсы юнита, такие как его модель или текстуры.

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

Они все правы, С++ совершенно ужасный ЯП. К сожалению, если важна производительность, высокоуровневость, гибкость и тд и все в одном флаконе - ничего лучше пока не придумали;-(

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

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

Ну вот. Никакой ошибки. Ресурс не в памяти, но обрабатывается менеджером

amphibrakhij
()
Ответ на: комментарий от quiet_readonly

Чтой-то ты так бурно среагировал?

В C++ нет автоматического управления памятью - раз, и идентификаторы указывают на значение, а не на ссылку, - два. Отсюда вообще потребность в _каких_либо_ указателях. То что он ещё и усложнен, так что только первоклассные спецы вроде тебя могут разобраться - это уже проблемы второй важности

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