Как работать с элементами GUI?

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

Я думал о том, как это сделать. Я имею в виду следующие элементы:

• Радио-кнопки
• Введите текст здесь, поля
• Кнопки
• Слайдеры
• Флажки

Я пока не смотрю, как их сделать. Но больше о том, как они пойдут.

идея

У меня было бы каждое состояние, в котором нужны вещи, так что почти у всех был бы контейнер Элементов. Каждый элемент является частью GUI.

У каждого из них есть позиция, графика и т. Д.

Часть, на которой я застреваю - это их логика.

Моя идея для этого, чтобы учесть модульность и простоту, состояла в том, чтобы избежать MainMenuStartButton; OptionsOneBackButton и т. д. и вместо этого можно сделать Slider slider1; или кнопка запуска ;.

Вместо этого каждый из них будет иметь функцию boost :: function для функции в пространстве имен GUI, например, Gui :: StartButtonClick или GUI :: ColourSliderHover.

Мне просто интересно, будет ли это исключительно медленно или нет.

И если уж на то пошло, есть ли простой и простой способ создания GUI для игр? Нет Qt, wxWidgets или что-нибудь.

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

Одна из "простых" вещей, которые вы можете сделать, это попытаться использовать промежуточное ПО. Там это вопрос о том, что здесь .

Если вы собираетесь это сделать самостоятельно, я бы предложил несколько вещей.

• Элементы GUI обычно имеют «родителя», либо другой элемент GUI, либо «окно», или что-то в этом роде. Либо указав вверх, либо указав родительскую точку, означает, что вы можете установить состояние / положение / и т. Д. Для всего, что является дочерним.

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

• Многие так называемые специализированные виджеты являются просто замаскированными кнопками. Флажки - это просто кнопки с состояниями и специальными изображениями. Радиокнопки - это просто флажки, которые имеют мета-состояние (один и только один активен в любой момент времени) с другими радиокнопками. Используйте это в ваших интересах. В одной игре, над которой я работал, «чекбоксы» делались с помощью обычных кнопок полностью через сценарии и искусство.

• Для вашего первого проекта рассмотрите возможность выбора более прямого маршрута. Да, сделайте ваши действующие делегаты событий и назначьте то, что вам нужно при создании элемента (например, onMouseButtonDown, onMouseButtonUp, onHover и т. Д.), Но подумайте только о жестком кодировании того, что вы хотите, чтобы происходило иначе (например, изменение цвета при наведении, нажатия кнопок), пока не получите что-то функциональны. Когда вы достигнете этой точки, подумайте над созданием этих данных о поведении (т. Е. Используйте переменную на кнопке для «нажатия звука») или, возможно, подумайте о наличии компонентов, которые ваши элементы пользовательского интерфейса используют для определения поведения, которое вы просто прикрепляете к ним при создании.

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

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

Моя любимая система пользовательского интерфейса - Windows Presentation Foundation (WPF). Это действительно берет потенциал для дифференциации пользовательского интерфейса на следующий уровень. Вот некоторые из его более интересных функций:

1. По умолчанию элементы управления выглядят как «безликие». Логика и внешний вид элемента управления, как правило, не связаны. Каждый элемент управления поставляется со стилем по умолчанию и шаблоном, который описывает его внешний вид по умолчанию. Например, кнопка может быть представлена ​​в виде скругленного прямоугольника с внешним штрихом, сплошным цветом или градиентным фоном и предъявителем контента (для представления подписи). Разработчики (или дизайнеры) могут создавать собственные шаблоны стилей, которые изменяют внешний вид и (в некоторой степени) поведение элемента управления. Стили можно использовать для переопределения простых свойств элемента управления, таких как цвет переднего плана / фона, шаблон и т. Д .; шаблоны меняют фактическую визуальную структуру.

2. Стили и шаблоны могут включать «Триггеры». Триггеры могут прослушивать определенные события или значения свойств (или комбинации значений) и условно изменять аспекты стиля или шаблона. Например, шаблон кнопки обычно имеет триггер для свойства «IsMouseOver» для изменения цвета фона при наведении курсора мыши на кнопку.

3. Существует несколько различных «уровней» элементов пользовательского интерфейса: от легких элементов с минимальной функциональностью до полнофункциональных элементов управления с большим весом. Это дает вам некоторую гибкость в том, как вы структурируете свой интерфейс. Простейший из классов элементов пользовательского интерфейса UIElementне имеет стиля или шаблона и поддерживает только самые простые входные события. Для простых элементов, таких как индикаторы состояния, эта функциональность может быть всем, что вам нужно. Если вам требуется более обширная поддержка ввода, вы можете извлечь из FrameworkElement(что расширяется UIElement). Традиционные виджеты, как правило, являются производными Control, которые расширяют FrameworkElementи добавляют пользовательский стиль и поддержку шаблонов (среди прочего).

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

5. Внедрение WPF включало новый декларативный язык программирования под названием Xaml. Xaml, основанный на Xml, является предпочтительным языком для объявления «сцен» пользовательского интерфейса. Это на самом деле довольно гладко, и, хотя на первый взгляд может показаться схожим, оно в корне отличается от существующих языков, таких как XUL (и гораздо более мощный).

6. WPF имеет очень продвинутую текстовую подсистему. Он поддерживает большинство, если не все функции шрифтов OpenType, двунаправленное сглаживание ClearType, позиционирование субпикселей и т. Д.

«Хорошо, отлично, а как это относится к разработке игр?»

В те времена, когда WPF еще находился в разработке (и известен как «Авалон»), я проходил курс дизайна видеоигр в Georgia Tech. Мой последний проект был пошаговой стратегической игрой, и я хотел очень способный пользовательский интерфейс. WPF / Avalon показался мне хорошим маршрутом, потому что он имел полный набор полнофункциональных элементов управления и позволил мне полностью изменить внешний вид этих элементов управления. Результатом стала игра с красивым и четким пользовательским интерфейсом с уровнем функциональности, который вы обычно видите только в полноценных приложениях.

Теперь проблема использования WPF для игр заключается в том, что он довольно тяжелый и рендерится в своей «песочнице». Под этим я подразумеваю, что не существует поддерживаемого способа размещения WPF в игровой среде Direct3D или OpenGL. Можно размещать содержимое Direct3D в приложении WPF, но вы будете ограничены частотой кадров приложения WPF, которая обычно ниже, чем вы хотели бы. Для некоторых типов игр, таких как 2D-стратегии (скриншот моего нынешнего игрового проекта WPF), он все еще может работать отлично. Для всего остального, не так много. Но вы все равно можете применить некоторые из наиболее привлекательных архитектурных концепций WPF при разработке своей собственной инфраструктуры пользовательского интерфейса.

Существует также неуправляемая реализация WPF на C ++ / Direct3D с открытым исходным кодом, называемая «WPF / G (WPF для игр)»] ( http://wpfg.codeplex.com/ ), которая специально разработана для использования в играх на обоих Win32. и Windows Mobile. Активная разработка, похоже, прекратилась, но в последний раз, когда я это проверил, это была довольно полная реализация. Текстовая подсистема была единственной областью, которой действительно не хватало по сравнению с реализацией Microsoft WPF, но это не проблема для игр. Я полагаю, что интеграция WPF / G с игровым движком на основе Direct3D будет относительно простой. Пройдя по этому пути, вы можете получить чрезвычайно функциональную, независимую от разрешения структуру пользовательского интерфейса с расширенной поддержкой настройки пользовательского интерфейса.

Просто, чтобы дать вам представление о том, как может выглядеть пользовательский интерфейс на основе WPF, вот скриншот из моего любимого проекта:

Я хотел бы сразу перейти к графическому интерфейсу, например: http://code.google.com/p/nvidia-widgets/

Виджеты nVidia основаны на IMGUI (Immediate GUI) от MollyRocket.

Я думаю, что это так просто, как GUI когда-либо может получить.

Все зависит от ваших потребностей.

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

По сути, все кнопки, флажки и т. Д. Являются подклассами класса Element; и элементы имеют события. Затем у нас есть CompoundElements (которые сами являются подклассом Element), которые содержат другие элементы. В каждом цикле вызываются три метода: processEvent (событие), tick (время) и draw (поверхность). Каждый CompoundElement затем вызывает эти методы в своих дочерних элементах. В этих вызовах (особенно в методе processEvent) мы запускаем любые соответствующие события.

Все это на Python (гораздо более медленный язык, чем C ++), и работает отлично.

Если вам понадобятся довольно сложные пользовательские интерфейсы, возможно, лучшим выбором будет просто встроить HTML-рендерер - вы получите все обычные пользовательские примитивы пользовательского интерфейса, к которым вы привыкли, и вы можете легко добавить сложный пользовательский интерфейс в свою игру, который будет вести себя так, как вам нужно. пользователи ожидают, отлично выглядят и быстро бегают (потому что браузеры уже довольно оптимизировали конвейеры рендеринга).

Существует несколько библиотек для встраивания Webkit в игры: я рекомендую Berkelium, и я слышал, что Awesomium довольно хорош (используется EVE Online) и CEF (используется Steam). Вы также можете попробовать встроить Gecko - это сделать намного сложнее, но у него есть и интересные преимущества. В настоящее время я использую Berkelium для всех своих игровых интерфейсов (он заменил комбинацию пользовательских элементов интерфейса и встроенного интерфейса и значительно сократил объем кода, который мне нужно было написать, чтобы все заработало).

Убедитесь, что вам действительно нужна сложная система графического интерфейса для вашей игры. Если вы делаете компьютерную RPG, тогда, очевидно, это будет требованием; но для чего-то вроде гоночной игры не переусердствуйте. Иногда только рендеринг текстур (изображения пользовательских кнопок) и наличие некоторых операторов «if» с жестко закодированными координатами в вашей функции ввода могут сделать работу. Игровой автомат (FSM) помогает в этом простом подходе. Или где-то посередине, забудьте о сложной иерархии и подходе к графу сцены и просто используйте класс «Button», который упаковывает вышеупомянутые текстуры и проверки ввода в простые вызовы функций, но не делает ничего сложного.

Важно придерживаться ваших требований. Если вы не уверены, просто напомните себе ЯГНИ .

Вот один пример (исходный код и все) графического интерфейса, созданного для OpenGL, специально для Slick2D под названием Thingle, который является портом Thinlet .

Другим графическим интерфейсом для Slick2D был SUI, который вы могли бы попробовать .

Я бы следовал этим примерам и использовал графический интерфейс на основе XML. Хотя эти проекты старые / мёртвые, вы можете получить некоторые идеи из них.

Я думаю, что один из лучших способов «разобраться» - это посмотреть, как работают высокоразвитые структуры GUI, такие как Windows Forms в .NET.

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

Все они содержат различные события, такие как Click, MouseOverи Resizing.

Например, когда дочерний элемент управления изменяется, он отправляет в цепочку уведомление о том, что его макет изменился, и затем все родители вызывают PerformLayout().

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

Ради интересов я думал, что выкину Scaleform . В основном художники могут использовать иллюстратор, фотошоп и т. Д., А затем дизайнер пользовательского интерфейса использует Flash для макетирования всей интерактивности. Затем Scaleform преобразует его в код для вашего движка (это мое понимание, поскольку я его не использовал). Crysis Warhead использовал эту систему для своего лобби.