Написать свой простой GUI (C++). / Общее / Форум / Программирование игр / GameDev.ru

Стоит ли делать так? Хотелось бы, чтобы для каждого элемента GUI, можно было самому передавать действия которые он должен выполнить, чтобы не плодить несколько разных классов кнопок. Тут возникает так же несколько проблем, где хранить сами данные кнопок, в классе Action или же в guiButton, так как обращение к ним будет затруднено из Action. Передавать ли в Action (guiElement &ptr) или сделать Action абстрактным и унаследоваться от него ActionButton и уже туда передавать guiButton.

Jimnik
Постоялец

#1
10:35, 16 фев 2014

Yuno
DXUTgui бери и копируй.
Всё равно лучше решения не придумаешь.

Mikey
Постоялец

#2
10:52, 16 фев 2014

Yuno
std::function

Yuno
Пользователь

#3
10:56, 16 фев 2014

>std::function
Но зачем?

I
Постоялец

#4
12:11, 16 фев 2014

void Render() <- зачем ? GUI должен рендериться в своем потоке, своими методами, сам компонент не чего о рендере знать не должен ...

I
Постоялец

#5
12:22, 16 фев 2014

Yuno
> Стоит ли делать так? Хотелось бы, чтобы для каждого элемента GUI, можно было
> самому передавать действия которые он должен выполнить, чтобы не плодить
> несколько разных классов кнопок. Тут возникает так же несколько проблем, где
> хранить сами данные кнопок, в классе Action или же в guiButton, так как
> обращение к ним будет затруднено из Action. Передавать ли в Action (guiElement
> &ptr) или сделать Action абстрактным и унаследоваться от него ActionButton и
> уже туда передавать guiButton.

1 нужно передавать не действия, а подписываться на события из контролла
2 какие данные кнопок ? кнопка это кнопка, у которой есть параметры ( базовые )

вобще иерархия должна быть приблизительно такая

View {
    bool userInteraction; // default false
    addEventListener;
    ....
}
- GUIButton {
    
}

в коде делаешь просто так 
GUIButton*button1 = 
button1->addEventListener(MESSAGE,method);

function METHOD(... info) {
      // message resave 
}

как именно ты внутри реализуешь эту схему или снаружи зависит от того как тебе будет удобнее

=A=L=X=
Постоялец

#6
14:45, 16 фев 2014

Yuno
> >std::function
> Но зачем?

Для реализации реакции на события наиболее естественным образом. Всякие Action-классы это переголова.
Как это реализуется.
Сперва определяются базовые понятия - например GUI у нас состоит из прямоугольных контролов, возможно вложенных друг в друга и взаимодействует с пользователем через клавиатуру и мышь по определенной спецификации.
Тогда вырисовывается что то типа:

class Control
{
   int x, y;
   int width, height;
   std::list<Control *> childs;
   Contorl *owner;
   virtual bool IsUnderPoint( int x, int y );
   virtual void MouseMove( int x, int y );
   virtual void MouseClick( int x, int y );
   virtual void Paint(); // возможно более богато типа Paint( Canvas &c )
};

Заметим, что реализация IsUnderPoint должна сперва опрашивать childs (получается что рекурсивно) на предмет не попал кто то из них под мышь, и естественным образом возникает понятие Z-order.
Код управляющий всем этим безобразим при получении от ОС клика мыши допустим что делает - ищет по IsUnderPoint на кого мышь попала и вызывает ему MouseClick. Нормально.
Кроме того нужны понятия фокуса (активного контрола) для ввода с клавиатуры, порядка обхода для TAB, если нужно, захвата мыши и т.п. Если пробовать писать и писать то это всё само начнёт вылазить.

Но идем далее - что должна делать та же Button получив MouseClick? Если для разных реализаций MouseClick разных кнопок придётся писать новых наследников от Button или даже от некоего более абстрактного Action, то это переголова начинается.
Идеальный вариант - когда мы можем на событие клика мыши назначить внешний метод. В С это были бы указатели на функции. В С++ возникает резонное желание потянуться по аналогии к указателям на методы, но увы, указатели на методы слишком узкий механизм непригодный по целому ряду причин для наших целей. Выручает std::function!

class Button: public Control
{
   std::function< Button *, int x, int y > onClick; // вот это - делегат
   /*virtual*/ void MouseClick( int x, int y )
   {
        if ( onClick ) onClick( this, x, y );
   };
};

Важно тут то, что Button не знает что ему вменят в onClick - указатель на функцию или указатель на метод класса, или даже лямбду - для него выглядит так что он просто кому то посылает сообщение что состоялось нажатие. В коде использовать такую кнопку становится очень просто:

class MyWindow: public Window // что то такое тоже должно быть. или Application.
{
     Button btn1;
     ...
     btn1.owner = this;
     btn1.onClick = std::bind( &MyWindow::onButton1Click, this, _1, _2, _3 ); // что это такое - см. доки
     ...
     void onButton1Click( Button *sender, int x, int y )
     {
          show( std::string( "button " ) + control_to_string( sender ) + " was clicked at: " + int_to_str( x ) + ":" + int_to_str( y ) );
     };
};

Заметим - мы не создаём чертову кучу оголтелых классов для разных реализаций нажатия - это конкретные методы, обычные регулярные кусочки кода какого то контрола же (допустим составного, собственно MyWindow от Window тоже обычно наследуется от Control, таки да), которые пристёгиваются к кнопке через его std::function onClick налету. Такая архитектура обычно называется событийной.

Kartonagnick
Постоялец

#7
15:10, 16 фев 2014

Yuno, гуй представляет собой mvc в сферическом факкуме.

То бишь это система из трех модулей: модель, контролл, вьюха.

Модель:

+ Показать

− Скрыть

Гуй оперирует единственным понятием - виджет. Это данные модели.

+ Показать

− Скрыть

кнопка - это виджет, настроенный особенным образом
статическая картинка - это виджет, настроенный особенным образом
скроллбар - это виджет, настроенный особенным образом
(ну вы понэли)

Виджет умеет держать в себе другие виджеты.

Есть ещё базовая простая картинка. Деталь релизации. Пользователи про неё не знают. Но с её помощью виджету можно добавить картинку.
Есть ещё базовый звук. Деталь релизации. Пользователи про неё не знают. Но с её помощью виджету можно добавить звучание.

В общем, все что знает пользователь - это что есть виджет. Который может выступать в виде картинки, реагировать на мышку, его можно перемещать по экрану, вращать, и тд и тп.

Когда пользователь делает Button button;
На самом деле он создает Windget, который по дефолту настроен так, что бы лучше всего соответствовать внешнему виду и поведению простой кнопки.
То бишь, из коробки доступны уже настроенный виджет "простая стандартная кнопка".

Но можно взять просто виджет и самому легко и просто настроить его так, что бы он вел себя "как кнопка".

Это нужно для того, что бы у пользователей была возможность изготавливать кастомные кнопки.

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

+ Показать

− Скрыть

В игровом гуе черезвычайно важно уметь получать кастомные виджеты.
В отличие от системного гуя, игровой гуй - не ограниченный полет фантазии.

Например: представьте себе обычную кнопку, которая выглядит как квадратик, в центре окружности.
В левой правой части квадратика - патроны (число), а сам квадратик - иконка пушки.

После нажатия на пушку происходит выстрел - количество патронов уменьшается. Пушка становится не активной (больше нельзя нажимать), а вокруг пушки начинает вращаться окружность. Это типа пушка перезаряжается. Скорость вращения - это скорость перезарядки. Когда она повернется на 360 градусов - пушка перезарядилась.
Кнопка снова должна стать активной.

Вот это - "кастомная кнопка" в понятии игрового гуя. Она сложнее, чем "стандартная кнопка", но не слишком. Гуи должна предоставлять пользователям быстро изготавливать виджеты нужного поведения.

Получается, что виджет - это контейнер, который может тащить на борту медиа-типы (картинки/звуки), обладать состоянием и обладать поведением.

В библиотеке CEGUI для кастомизации виджета, вы задаете ему список состояний, в котором может находится виджет (например: состояние "кликнули" ), и сопоставить состоянию внешний вид (например: отобразить на всей площади виджета картинку с именем "клик.png", и прозвучать звук "клик.wav")

И тогда, каждый раз, когда вы кликните на такой виджет, он будет принимать ту картинку и таким образом, как вы ему это указали, и звучать.

В общем, способы кастомизации - это отдельная интересная тема для разговора.

Контроллер:

+ Показать

− Скрыть

Контроллер - модуль системы, который отвечает за её бизнес-логику.

Приличный гуй умеет обрабатывать ввод (клавиатуру, мышку). Но при этом, приличный гуй никак не связан с устройством ввода-вывода.
То есть, он понятия не имеет откуда взять данные о состоянии той же мышки.

Для этого у гуя есть функции, позволяющие сообщить ему о клавиатуре/мыши.
В CEGUI (если не ошибаюсь в MyGui та же самая схема) есть методы инжекта ввода наподобие:

+ Показать

Тот кто держит систему гуя (обычно это - движок), на каждом очередном рабочем цикле через сторонние устройства (в примере это библиотека OIS идущая в коробке движка OGRE), добывает данные о состоянии ввода,и инжектит их подсистеме гуй.

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

Например, он определяет какой из виджетов оказался под курсором мыши, и передает этому виджету состояние курсора.
Виджет (допустим он настроен как кнопка), в свою очередь может кликнуться.

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

Вьюха:

+ Показать

− Скрыть

Отвечает за отображение гуя на экране.

Тут две схемы:

1. Вьюха держит на борту собственный рендер, и знает как рендерить картинки, которые виджеты используют для своего отображения.

2. Вьюха выступает в качестве адаптера между внешним рендером, и собственными виджетами. То есть, она знает какие виджеты нужно отрисовать, и в каком виде он должны быть отрисованы. Но не знает, как именно это делать будет рендер.

В этом случае, вьюха содержит адаптеры.

Адаптеры преобразует данные о виджетах, таким образом, что бы целевой рендер понял что нужно рисовать.

Хороший Гуй не привязывается к конкретному рендеру. Поэтому, обычно в его коробке допусны несколько адаптеров для связки с самыми ходовыми популярными рендерами.

Например, библиотеки CEGUI и MyGui из коробки умеют работать с движком OGRE и многими другими.
То есть, они рисуют не своими руками, а руками рендера, который используются в движке.

Если я не ошибаюсь, то изначально MyGui рисовал только руками OGRE, который был хардкорно зашит во вьюху MyGUI.
Но позже их разработчики поняв потенциал библиотеки, отвязались от хардкора в пользу возможности переключаться между рендерами.

Таким образом, задачу вьюхи можно охарактиризовать так:

1. Либо просто рисовать виджеты на экране

2 Либо предоставить интерфейсы, которые позволят относительно безболезненно менять один рендер на другой.
И рисовать свои виджеты руками этого рендера.

nes
Постоялец

#8
18:26, 16 фев 2014

Yuno
>Стоит ли делать так? Хотелось бы, чтобы для каждого элемента GUI, можно было самому передавать действия которые он должен выполнить
>самому передавать действия которые он должен выполнить
>самому
Ой палишься )

Yuno
Пользователь

#9
18:56, 16 фев 2014

=A=L=X=
Kartonagnick
Большое спасибо за объяснения, не сильно поняла конечно, особенно в плане рендера, не привязывая конкретный рендер к объектам гуи, как именно в таком случае содержать данные, спрайтов, шрифтов и.т.д.? Все же попробую разобраться, может что получится или посмотрю исходники HGE и на их основе сделаю свой.

nes
Лал, была когда-то привычка писать от мужского пола, иногда проскальзывает. ;)