cegui

Crazy Eddie's Gui System Mk-2

http://www.cegui.org.uk

Copyright © 2004 - 2022 Paul D Turner, команда разработчиков Cegui и авторы, выступающие

Большинство вспомогательных файлов для CEGUI, которые раньше были простым текстом, теперь хранятся в «доксигенизированном» формате в каталоге DOC/DOXYGEN - см. Эти файлы или генерируйте документацию для более дружественного формата. В качестве альтернативы, посетите http://static.cegui.org.uk/docs для всех ваших потребностей в документации!

Далее следует только быстрое руководство, перейдите в наши документы Doxygen для более подробной документации.

Доступные филиалы и версии

• Репозиторий CEGUI состоит из нескольких ветвей:
  • v0-8 предоставляет последнюю стабильную версию ABI, совместимую с ABI (до 0,8.x) версию CEGUI. Основано на стандартном и совместимом с наиболее распространенными компиляторами C ++ 03 с наиболее распространенными компиляторами, включая Visual Studio 2008-2015. Поскольку эта ветвь совместима с ABI, можно заменить динамические библиотеки CEGUI версии 0.8.x на более новые версии 0,8.x или наоборот, без необходимости перекомпилировать проект. Эта ветвь также является основой для новых выпусков 0,8.x.
  • v0 предоставляет новейшую стабильную версию API, совместимую с CEGUI и содержит изменения, которые разрушают ABI. Основано на стандартном и совместимом с наиболее распространенными компиляторами C ++ 03 с наиболее распространенными компиляторами, включая Visual Studio 2008-2015. Версии из этой ветви будут использоваться для следующего выпуска второстепенной версии.
  • default содержит изменения, которые будут использоваться только в следующей крупной версии. На основе стандартных и совместимых C ++ 11 с наиболее распространенными компиляторами даты, включая Visual Studio 2013 или более новый. Эта ветвь очень нестабильна, внесет фундаментальные изменения и разрывы ABI и совместимость с API . Мы не рекомендуем вам использовать это в производстве, если вы не зависят от функции и не обсуждали это с разработчиком CEGUI раньше: это рекомендуется, чтобы вы знали обо всех потенциальных рисках. В общем случае вам рекомендуется использовать одну из стабильных ветвей, чтобы сохранить вам большую головную боль.

Ветви v0-8 и v0 считаются стабильными, но подвергаются фиксам ошибок и небольшим изменениям, которые не ломают ABI и API соответственно. Эти изменения, конечно же, представляют небольшой риск того, что в филиалах могут быть временные проблемы. Если вы заметили какие -либо ошибки в этих филиалах, пожалуйста, сообщите о них нам как можно скорее - используйте форум и/или наши каналы IRC #cegui и #cegui-devel на irc.freenode.net , чтобы сообщить нам. Пожалуйста, учтите, что мы не доступны в IRC 24 часа в день, но не стесняйтесь бездействовать, пока мы не ответим. Если вы сомневаетесь, какую ветвь использовать, также не стесняйтесь спрашивать нас таким образом. Для использования производства мы обычно рекомендуем использовать стабильную версию релиза. Список выпусков можно найти на нашем сайте.

Внося

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

Вот объяснение того, как отказаться от нашего репозитория, совершать изменения в вашей вилке и создать запрос на притяжение, нацеленное на правильную ветвь: https://confluence.atlassian.com/display/bitbucet/fork+a+Repo ,+compare+code, и+ Create+Pull+Request

Пожалуйста, также имейте в виду, чтобы нацелиться на правильный репозиторий. Мы предпочитаем нацелиться на ABI -совместимую ветвь, если это возможно. В противном случае API совместимы. Для получения информации о совместимости ABI/API, пожалуйста, прочитайте эту страницу: https://community.kde.org/policies/binary_compatibility_issues_with_c%2B%2B

Если вы сомнетесь, на какую филиал нацелен, пожалуйста, свяжитесь с нами!

Здание Cegui

Следующий сценарий более или менее универсален для *NIX Systems и Windows. Незначительные изменения могут потребоваться.

 cd $cegui_folder
# you can call the folder differently but "build" is customary
mkdir build/
cd build/
# run the configure step
cmake-gui ../
# fix any issues pointed out by cmake
# not all dependencies are required so if some are not found, don't panic and carry on!
# alternative (if you are a command line pro)
# cmake ../

На этом этапе будут сгенерированы Makefiles, файлы проекта или что -то еще. Следующий шаг зависит от того, что это такое.

Для Makefiles, просто бегите

 cd $cegui_folder
cd build/
make

Для решений Visual Studio, дважды щелкните, соответственно измените режим сборки (выпуск, отладка, ...) и нажмите сборку.

Установка CEGUI

Этот раздел имеет смысл только на *NIX-подобных системах.

Убедитесь, что у вас есть правильный настройка CMAKE_INSTALL_PREFIX в время настройки. Alternativeelly повторно Cmake и установите его. По умолчанию это должно быть /usr/local/ но вы можете захотеть /usr/ .

 cd $cegui_folder
cd build/
sudo make install

Запуск образцов Cegui

Если вы установили Cegui по всей системе, просто вызовите:

CEGUISampleFramework-0

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

Если у вас нет установленной общедоступной системы, это немного более вовлечено и сложно.

 cd $cegui_folder
cd build/bin/
CEGUI_SAMPLE_DATAPATH=../../datafiles ./CEGUISampleFramework-0

Мы хотим ответить на некоторые вопросы и заблуждения:

Почему так много зависимостей?

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

Cmake говорит мне, что что -то не было найдено, это проблема?

Если Cmake скажет вам, что что -то не было найдено, вы не будете паниковать ;)! Скорее всего, это безобидное послание. Вы должны беспокоиться только о том, что зависимость, которую вы знаете, вам не нужна, или если зависимости не найдены. В последнем случае, в Windows и Mac OS X, вы, вероятно, не помещали папку «зависимости» (включая зависимости, скомпилированные в отладке/выпуске/что-то, что-то-else-nueed)) в папку, содержащую все файлы и папки Cegui. Вы также можете указать другую папку в Cmake, используя переменную cegui_dependencies_dir.

Для чего нужны номера версий в DLL и исполняемых файлах? Как их удалить?

Эта система нумерации действительно служит очень важной цели! Пожалуйста, позвольте нам сохранить их. Это позволяет дистрибутивам Linux (и другим) устанавливать несколько версий API CEGUI, наряду с тем, которые облегчает миграцию и ускоряет внедрение новых версий CEGUI. В Windows это позволит нам предоставить вам предварительные зависимости CEGUI с использованием Nuget в будущем.

В моем приложении курсоры ОС, показанные над курсором Cegui, намного быстрее, почему?

Это ожидаемое поведение. Прежде всего, вы всегда должны проверять производительность в режиме выпуска, но даже там курсор будет медленнее. Причина в том, что вполне маловероятно, что любое приложение будет иметь курсор так же быстро, как курсор ОС. Также помните, что скорость тесно связана с вашей частотой кадров, поэтому, если вы запускаете демонстрацию Helloworld на уровне 5000 кадров в секунду, разница будет меньше, но все же заметна. Любая игра, симуляция или другое приложение, которое отображает свой собственный курсор через функции OpenGL/Direct3D аналогично. Тем не менее, скорость курсора не является проблемой для пользователей, если ваше приложение работает с частоты кадров (> 60 кадров в секунду) без кадров и не воспринимается как таковая. Как только вы скрываете курсор ОС, задержка, вероятно, больше не будет заметна для вас.

Так много DLL, почему Cegui вызывает "DLL Hell"? Как насчет статического связывания?

Во -первых, термин «dll Hell» используется неправильно в этом контексте. Это не означает «я вижу много файлов DLL, это должно быть ад!». Динамическое связывание библиотеки CEGUI - лучший способ, чтобы вещи работали, как предполагается, и гарантировать хорошую совместимость и низкую вероятность проблем, возникающих с зависимостью. В Windows мы рекомендуем использовать динамическое связывание с CEGUI, а не статическое связывание, поскольку прошлый опыт (некоторые пользователи сталкиваются с техническими проблемами) показали нам, что это безопаснее. Однако, если вы знаете, что делаете, вы можете определенно использовать статическое связывание. Имейте в виду, что мы только регулярно проверяем динамическое связывание, поэтому файлы Cmake могут быть устаревшими, и вам, возможно, придется добавить связанные библиотеки самостоятельно и т. Д. На положительном примечании: в предстоящей версии 1.0 мы уменьшим количество DLL Cegui создает, объединив некоторые из них в базовую библиотеку. Короткое, но определенно не полное резюме преимуществ и недостатков статического и динамического связывания можно найти здесь: http://stackoverflow.com/questions/1993390/static-s-dynamic

Cegui медленнее/быстрее, чем другие библиотеки? Почему в моем случае медленно?

В основном, когда пользователи жаловались на форумах на скорость CEGUI, оказалось, что они либо запускали приложение в конфигурации отладки, либо сделали что -то не так: это может быть медленным, если вы загружаете ресурсы макета/файлы каждый кадр, либо вызывая ненужные обновления и события. Или это может быть медленным, если вы излишне обновляете Cegui несколько раз на кадр в своей программе. Если вы не можете найти проблему, то лучше всего выполнить поиск на форуме/Google и - если вы не найдете ничего полезного, - подробно описать вашу настройку и какие проблемы у вас есть. Когда Cegui становится медленным, это также может быть связано с очень специфическим использованием конкретных функций, которые мы не ожидали и не протесвались. В этом случае мы хотели бы, чтобы вы описали свой вариант использования на форуме, чтобы мы могли найти решение или, если вы способны решить проблему самостоятельно, создать запрос на BitBucket.

В целом Cegui очень быстрый и может легко конкурировать с другими библиотеками GUI в скорости (особенно на основе флэш -ки, поскольку они не получают доступ к OpenGL или Direct3D напрямую). Несмотря на то, что ни одна сложная библиотека никогда не будет идеально оптимизирована, Cegui можно считать высокопрофессиональными. Это верно для вычислений, сделанных на процессоре, а также на графическом процессоре. Он все еще работает оптимально, когда сотни окон открываются и отображаются одновременно.

Лучшее доказательство того, что Cegui быстрый, - это то, что большие проприетарные игры, которые отображают сотни виджетов и используют сложные иерархии, были сделаны с использованием Cegui (Torchlight 1, Torchlight 2, Venetica и т. Д.).

Большинство наших образцов, если они начинаются в режиме выпуска, будут отображаться со скоростью более 3000 кадров в секунду на современном процессоре и графическом процессоре. В качестве дополнительной записки для некоторых людей, которые любили цитировать сомнительные тесты относительно таких сравнений скорости: тесты зависят от ситуации и могут легко исказить фактическую скорость библиотеки по неправильному, неэффективному или необычному использованию. При правильном использовании и внутри границ ожидаемого использования Cegui работает очень хорошо.