My:Abs

Материал из synset
Перейти к: навигация, поиск

Атлас текстур

Предлагается (Хить, Степанов) следующее решение.

  • Все графические ресурсы хранятся в отдельных png или jpg (если без маски) файлах (лучше сжатые, так как чтение с диска критично). В файле описания ресурсов (xml или bin ?!) указывается имя этого файла и имя текстурного файла, который по умолчанию нулевой (отсутствует).
  • Редактору ресурсов текстуры не нужны (стандартное gui).
  • В редакторе сцены:
    • если текстуры нужны (область редактирования делается на GL) и текстурный файл ресурса нулевой, то текстуры генерятся налету. Т.е. при перетаскивании ресурса (объекта) на сцену, в памяти создаётся новая текстура, куда копируются битмапы объекта. Когда текстура заполнится ресурсами, создаётся новая текстура и т.д. Время не играет роли на фоне времени перетаскивания. Память (неэффективность заполнения) под Windows, по-видимому тоже.
    • если область редактирования делается на обычном gui, то текстуры не нужны. Впрочем, подобное решение, видимо, хуже, т.к. в будущем теряется возможность простого использования функций шкалирования и поворота, заложенных в GL.
  • Во вьювере хидена, запускаемом из редакторов сцены и/или уровней (написанном на движке) текстуры также создаются налету при чтении файла-описания сцены (как указано выше). Для тестирования игры, возможная задержка (сопровождаемая прогресс-баром) при переходе со сцены на сцену непринципиальна (в разумных пределах). Во вьювере хиддена стоит предусмотреть кеширование raw изображений в памяти для создания текстур налету (чтобы постоянно не читать файлы). Одно дело загрузить уровень и играть в него, другое работать по принципу подправил сцену - посмотрел (тут секунды критичны). Стоит использовать ресурсы из предыдущей сцены, если хватает памяти.
  • В окончательно собранном приложении возможно несколько решений, требующих исследований:
    • Создание текстур налету как выше. При этом все графические файлы, возможно, надо упаковать в один большой сжатый бинарник, для сокращения времени на открытие-закрытие файла. Если особой задержки нет, это идеальное решение.
    • По всем файлам описания сцен и уровней создаётся оптимальный (с точки зрения логики игры) набор текстур в автоматическом или полуавтоматическом режиме.

Разное

  1. Проблему целостности данных предлагается пока решить простейшим образом. Если объект был перетащен из редактора ресурсов куда-либо, у него увеличивается счётчик использований. Объект нельзя удалить из базы ресурсов, если счётчик ненулевой. Обратного уменьшения счётчика не будет. Это возможно приведёт к некоторому захламлению базы, однако, сборка проекта всё равно будет происходить по файлам описания сцены и ничего лишнего из базы ресурсов не возьмётся. В дальнейшем, возможны различные механизмы организации целостности: от запуска утилиты, которая знает все файлы-описания различных редакторов и подправляет счётчики, до клиент-серверной архитектуры. Везде стараемся сначала реализовать простейшее решение.
  2. В описании сцен идёт ссылка на текстовое имя ресурса (имя_базы.имя_ресурса), поэтому дублирование не принципиально. Касательно атласа текстур см. раздел ниже.
  3. Вся та же, что и сейчас используется. Стоит сразу начать писать документацию на файл-описание ресурсов. По ходу все по-добавляют. К слову, вопрос - должен ли это быть xml-файл? Может лучше бинарный, с утилитой конвертации res2xml?
  4. Аналогично, в соответствии с возможностями нашего движка. Начать с минимума возможностей, потом расширять (нужна документация - см.выше).
  5. Возможно множество решений. Как мы решили на совещании, должны совместно существовать ряд баз (например, по именам художников). В простейшем случае это файлы-описания в xml-формате (или bin), по одному на каждую базу, собранные в одной директории. Там же есть поддиректории (своя для каждого файла описания) в которых находятся собственно картинки. Эти базы (файлы-описания) являются корневыми для древестной иерархии-систематизации объектов. Сама иерархия описывается в отдельных файлах по одному для каждой базы. Ещё одна директория для каждой базы содержит иконки объектов стандартного размера для графического списка объектов в редакторе ресурсов. Возможно, всё это окажется избыточным и на практике будет только одна база, но лучше заложить подобное разделение совместной работы на всякий случай. В дальнейшем потребуется функция переноса ресурсов из базы в базу (из одного дерева в другое). Это может делать "ответственный администратор". В любом случае, если некто открыл базу (файл-описаний) другие его изменять не должны быть способны. Это же относится к изменению древестной иерархии. Уже этого достаточно для совместной работы над одной базой (художники сидят в одной комнате - "Эй Олег, выйди из редактора...").
  6. Это лучше начать набрасывать в каком-либо дружественном gui (например, VCL Builder или др.).
  7. Как и выше, после утрясания архитектуры редактора ресурсов, нужно начинать писать документацию на формат файла-описания сцены. Сразу всё прояснится.
  8. Групповое добавление сейчас видится только двух видов:
    1. анимированный объект. Он является единым объектом, свойства которого практически всегда (?) настраиваются в редакторе ресурсов. При перетаскивании, приходит информация о всех его кадрах.
    2. фон вместе с объектами (см. концепт редактора хиденов). Перетаскивание фона с удержанием некоторой кнопки (Shift и т.п.) перетаскивает и фон и объекты которые были с ним связаны. Если кнопка не нажата перетаскивается только фон.