My:Abs — различия между версиями
WikiSysop (обсуждение | вклад) (→Разное) |
WikiSysop (обсуждение | вклад) (→Разное) |
||
Строка 17: | Строка 17: | ||
# Проблему целостности данных предлагается пока решить простейшим образом. Если объект был перетащен из редактора ресурсов куда либо, у него увеличивается счётчик использований. Объект нельзя удалить из базы ресурсов, если счётчик ненулевой. Обратного уменьшения счётчика не будет. Это возможно приведёт к некоторому захламлению базы, однако, сборка проекта всё равно будет происходить по файлам описания сцены и ничего лишнего из базы ресурсов не возьмётся. В дальнейшем, возможны различные механизмы организации целостности: от запуска утилиты, которая знает все файлы-описания различных редакторов и подправляет счётчики, до клиент-серверной архитектуры. | # Проблему целостности данных предлагается пока решить простейшим образом. Если объект был перетащен из редактора ресурсов куда либо, у него увеличивается счётчик использований. Объект нельзя удалить из базы ресурсов, если счётчик ненулевой. Обратного уменьшения счётчика не будет. Это возможно приведёт к некоторому захламлению базы, однако, сборка проекта всё равно будет происходить по файлам описания сцены и ничего лишнего из базы ресурсов не возьмётся. В дальнейшем, возможны различные механизмы организации целостности: от запуска утилиты, которая знает все файлы-описания различных редакторов и подправляет счётчики, до клиент-серверной архитектуры. | ||
+ | # В описании сцен идёт ссылка на текстовое имя ресурса (имя_базы.имя_ресурса), поэтому дублирование не принципиально. Касательно атласа текстур см. раздел ниже. | ||
+ | # Вся та же, что и сейчас используется. Стоит сразу начать писать документацию на файл-описание ресурсов. По ходу все по-добавляют. К слову, вопрос - должен ли это быть xml-файл? Может лучше бинарный, с утилитой конвертации res2xml? |
Версия 18:47, 1 августа 2011
Содержание |
Атлас текстур
Предлагается следующее решение.
- Все графические ресурсы хранятся в отдельных png или jpg (если без маски) файлах (лучше сжатые, так как чтение с диска критично). В файле описания ресурсов (xml или bin ?!) указывается имя этого файла и имя текстурного файла, который по умолчанию нулевой (отсутствует).
- Редактору ресурсов текстуры не нужны (стандартное gui).
- В редакторе сцены:
- если текстуры нужны (область редактирования делается на GL) и текстурный файл ресурса нулевой, то текстуры генерятся налету. Т.е. при перетаскивании ресурса (объекта) на сцену, в памяти создаётся новая текстура, куда битмапы объекта копируются. Когда текстура заполнится ресурсами, создаётся новая текстура и т.д. Время не играет роли на фоне времени перетаскивания.
- если область редактирования делается на обычном gui, текстуры не нужны. Впрочем, подобное решение возможно хуже, т.к. в будущем теряется возможность простого использования функций шкалирования и поворота, заложенных в GL.
- Во вьювере хидена, запускаемом из редакторов сцены и/или уровней (написанном на движке) текстуры также создаются налету при чтении файла-описания сцены (как указано выше). Для тестирования игры, возможная задержка (сопровождаемая прогресс-баром) при переходе со сцены на сцену непринципиальна (в разумных пределах). Во вьювере хиддена предусмотреть кеширование raw изображений в памяти для создания текстур налету (чтобы постоянно не читать файлы). Одно дело загрузить уровень и играть в него, другое работать по принципу подправил сцену - посмотрел (тут секунды критичны). Стоит использовать ресурсы из предыдущей сцены, если хватает памяти.
- В окончательно собранном приложении возможно несколько решений, требующих исследований:
- Создание текстур налету как выше. При этом все графические файлы, возможно, надо упаковать в один большой сжатый бинарник, для сокращения времени на открытие-закрытие файла. Если особой задержки нет, это идеальное решение.
- По всем файлам описания сцен и уровней создаётся оптимальный (с точки зрения логики игры) набор текстур в автоматическом или полуавтоматическом режиме.
Разное
- Проблему целостности данных предлагается пока решить простейшим образом. Если объект был перетащен из редактора ресурсов куда либо, у него увеличивается счётчик использований. Объект нельзя удалить из базы ресурсов, если счётчик ненулевой. Обратного уменьшения счётчика не будет. Это возможно приведёт к некоторому захламлению базы, однако, сборка проекта всё равно будет происходить по файлам описания сцены и ничего лишнего из базы ресурсов не возьмётся. В дальнейшем, возможны различные механизмы организации целостности: от запуска утилиты, которая знает все файлы-описания различных редакторов и подправляет счётчики, до клиент-серверной архитектуры.
- В описании сцен идёт ссылка на текстовое имя ресурса (имя_базы.имя_ресурса), поэтому дублирование не принципиально. Касательно атласа текстур см. раздел ниже.
- Вся та же, что и сейчас используется. Стоит сразу начать писать документацию на файл-описание ресурсов. По ходу все по-добавляют. К слову, вопрос - должен ли это быть xml-файл? Может лучше бинарный, с утилитой конвертации res2xml?