My:Abs — различия между версиями

Материал из synset
Перейти к: навигация, поиск
(Атлас текстур)
Строка 9: Строка 9:
 
** если текстуры нужны (область редактирования делается на GL), они генерятся налету. Т.е. при перетаскивании ресурса на сцену, в памяти создаётся новая текстура, куда объект копируется. Когда текстура заполнится ресурсами, создаётся новая текстура и т.д. Время не играет роли на фоне времени перетаскивания.
 
** если текстуры нужны (область редактирования делается на GL), они генерятся налету. Т.е. при перетаскивании ресурса на сцену, в памяти создаётся новая текстура, куда объект копируется. Когда текстура заполнится ресурсами, создаётся новая текстура и т.д. Время не играет роли на фоне времени перетаскивания.
 
** если область редактирования делается на обычном gui, текстуры не нужны. Впрочем, подобное решение возможно хуже, т.к. в будущем препятствует простое использование, заложенных в GL функций шкалирования и поворота.
 
** если область редактирования делается на обычном gui, текстуры не нужны. Впрочем, подобное решение возможно хуже, т.к. в будущем препятствует простое использование, заложенных в GL функций шкалирования и поворота.
* Во вьювере хидена, запускаемом из редакторов сцены и/или уровней (написанном на движке) текстуры также создаются налету при чтении файла-описания сцены (как указано выше).
+
* Во вьювере хидена, запускаемом из редакторов сцены и/или уровней (написанном на движке) текстуры также создаются налету при чтении файла-описания сцены (как указано выше). Для тестирования игры, возможная задержка (сопровождаемая прогресс-баром) при переходе со сцены на сцену не принципиальна.
 +
* В окончательно собранном приложении возможно несколько решений, требующих исследований:
 +
** Создание текстур налету как выше. При этом все графические файлы, возможно, надо упаковать в один большой сжатый бинарник, для сокращения времени на открытие-закрытие файла. Если особой задержки нет, это идеальное решение.
 +
** По всем файлам описания сцен и уровней создаётся оптимальный (с точки зрения логики игры) набор текстур в автоматическом или полуавтоматическом режиме.

Версия 17:10, 1 августа 2011

Содержание

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

Предлагается следующее решение.

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