?

Log in

No account? Create an account
IMGUI - Zeux's journal [entries|archive|friends|userinfo]
Zeux

[ website | blog ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

IMGUI [Mar. 31st, 2007|12:52 am]
Zeux
[Tags|, ]
[music |Gipsy Kings - Salsa de noche]

Что-то давно у меня не было нормальных околотехнических постов. А картинок не было уже очень давно (5 месяцев, ого!). А предполагается, что я как бы интересуюсь графикой, а значит - должны быть скриншоты... Ну ладно, вот тогда кое-что не совсем о графике, но зато с картинками. Без диалогов, диалог был в предыдущем посте ;)


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

Короче говоря, всем, кто интересуется/занимается GUI, я бы порекомендовал посмотреть на IMGUI (Immediate Mode GUI, в противовес RMGUI - Retained Mode GUI, обычно используемый подход). Основные бонусы, которые я уже успел увидеть - простой код (как в реализации GUI библиотеки, так и в использовании); отсутствие колбеков и потребности в синхронизации; очень просто добавлять контролы и менять функциональность существующих. Основные минусы - в зависимости от потребностей и реализации, код самой библиотеки может перестать быть совсем простым (каким он является у меня сейчас); не все контролы одинаково хорошо ложатся в концепцию (возможен гибридный подход с явным сохранением каких-то стейтов/данных); если хочется редактор GUI и вариант "посадить GUI дизайнера за Lua" отпадает, то придется делать RM-style враппер вокруг IM, что будет все равно лучше, чем pure RM, но убьет часть бонусов pure IM.
В любом случае, для меня это совсем другой взгляд на создание GUI, что по меньшей мере интересно.

Обещанные существующие документы на тему.

Оригинальное видео с описанием подхода (зеркало 1 зеркало 2) - 60 Mb - если трафик бесплатный, и IMGUI интересует, то не пожалейте времени.

Код/туториалы:
Tutorial по IMGUI - местами наивная реализация IMGUI, но с нее неплохо начинать. Но есть ввод с клавиатуры с tab order.
Реализация IMGUI к статье в GDMag - менее наивная реализация IMGUI, но зато без клавиатурного ввода.

Форум:
Molly Rocket IMGUI - форум с обсуждениями на тему, если действительно интересует подход - почитайте, там есть интересные вещи. Там же обитает автор видео и автор статьи в GDMag (это разные люди :) casey и sean). Подборка полезных/интересных тем:
Immediate Mode Graphical User Interfaces (IMGUI) - thread, с которого начался форум; разные вещи
Why not Button.Do()? - вгляд на IMGUI автора статьи в GDMag
game editor example, tree-view - пара интересных кусков кода
User customizable GUIs and IMGUIs - что можно пытаться делать с т.з. data-driven way, оставаясь IM
Event management - title says it all

И для полноты "Why IMGUI arguments fall short" (однако я не очень понимаю, про кого говорит автор поста).

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

Текстуры из public демок Unigine, да простят меня Frustum и binstream. Руками собраны в атлас - на всякий случай замечу, что IM совсем не означает ">= 1 DIP per control", отсутствия кеширования и прочих подобных вещей. Впрочем, это все есть в видео/на форуме.
linkReply

Comments:
[User Picture]From: _winnie
2007-03-31 12:25 am (UTC)

ИМХО, просто - потому что просто.

Не понял ничего из поста, кроме того что IMGUI есть. Посмотрел туториал, который "наивный". Чем оно отличное от всего другого, непонятно. Просто оно реализует очень простую функциональность, потому и простое. При постепенном усложнеии всё будет усложнятся до обычной схемы, что бы меньше писать кодеру. Так, например slider в пятой части уже имеет state.
static int bgcolor;
int slider(int id, int x, int y, int max, int &value)


При постепенном усложнении и рефакторинге этот int превратится на struct и скорее всего уже будет не static, а член какого-то класса, который представляет игровой экран (static-переменная в функции в C++ - часто неприемлема. Например, потому что зовётся из двух разных мест).

А если у нас есть Foo(Bar &state), то уже больше похоже на Bar::Foo()

Так что я вижу только одно принципиальное отличие - вместо кэллбека и автоматического апдейта по списку - ручной выхов Update.

А потом у нас появится сложная логика внутри if (button) и мы заходим вынести её в функцию.

if (button_eat(10, 10, &m_button_eat_state))
Eat();
if (button_jump(10, 20, &10, 10, &m_button_jump_state)
Jump();

И станет ясно, что сунуть кэллбек в конструктор - меньше кнопкодавства.

А потом - захочется разделить Draw и Update (могут быть разные объективным причины, например хотим только Draw без Update или наоборот, или вызвать Update для всех, а потом все Draw).

Лично у меня - интрузивный список (те. можно обходится без аллокаций, кнопки заводит сам юзер у себя) + базовый жирный интерфейс с виртуальными функциями у элементов + келлбеки (Winnie Closure). Всё без аллокаций. То есть, если единственный пойт это IMGUI в аллокациях - то это в огороде бузина, в киеве дядька.
Если развивать до любого уровня, что бы пользователю было красиво (плавное затухание и тп) и было много кнопочек - то превратится в обычную схему.

(Reply) (Thread)
[User Picture]From: _winnie
2007-03-31 12:29 am (UTC)

Re: ИМХО, просто - потому что просто.

Хотя, если слабать по быстрому главное меню для харкорного шутера, где дизайн GUI - дело десятое, то подойдёт.
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 01:04 am (UTC)

Re: ИМХО, просто - потому что просто.

Цитата из "Why IMGUI arguments fall short"?

При чем здесь дизайн, я слабо понимаю. Только потому, что в туториале SDL-ные квадратики?
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-03-31 10:02 am (UTC)

Re: ИМХО, просто - потому что просто.

>При чем здесь дизайн, я слабо понимаю. Только потому, что в туториале SDL-ные квадратики?
Не, потому что в туториале - всё "мгновенное".
>Я повторюсь, define "и тп". Затухание то же делается тривиально.
А как его добавить?

>> static-переменная в функции в C++ - часто неприемлема. Например, потому что зовётся из двух разных мест
>ты собираешься рисовать GUI из нескольких потоков?

Нет, просто зовём из двух мест. Два похожих меню на одном экране например.
Или собираем из простых элементов кнопки+edit box сложный - выпадающий combo-box. И где теперь функции combo_box хранить стейты своих подкнопок?



(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 10:27 am (UTC)

Re: ИМХО, просто - потому что просто.

> Не, потому что в туториале - всё "мгновенное".
Не понимаю.

> А как его добавить?
Добавление внутреннего стейта fade time. hash_map
[Error: Irreparable invalid markup ('<int,>') in entry. Owner must fix manually. Raw contents below.]

> Не, потому что в туториале - всё "мгновенное".
Не понимаю.

> А как его добавить?
Добавление <b>внутреннего</b> стейта fade time. hash_map<int, float>, и в конце каждого кадра уменьшение float-ов и удаление записей, где он <= 0. Приложение его вообще не видит.

> Нет, просто зовём из двух мест. Два похожих меню на одном экране например.
Ну, и где тогда проблемы?

> Или собираем из простых элементов кнопки+edit box сложный - выпадающий combo-box. И где теперь функции combo_box хранить стейты своих подкнопок?
Винни, у кнопок нет стейтов. Даже в том туториале нет.
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 12:53 am (UTC)

Re: ИМХО, просто - потому что просто.

> Не понял ничего из поста, кроме того что IMGUI есть.
Пост ставит своей целью донести, что такое слово есть, и дать набор линков. Пост с задачей справился :)

> Просто оно реализует очень простую функциональность, потому и простое.
Что такое сложная функциональность?

> static-переменная в функции в C++ - часто неприемлема. Например, потому что зовётся из двух разных мест
ты собираешься рисовать GUI из нескольких потоков?

> А если у нас есть Foo(Bar &state), то уже больше похоже на Bar::Foo()
На самом деле у нас и так Foo(Bar &state) (Bar == Context/Screen/whatever), а не Bar::Foo исключительно из-за того, что в С++ нельзя добавлять ф-ии в класс.

> Так что я вижу только одно принципиальное отличие - вместо кэллбека и автоматического апдейта по списку - ручной выхов Update.
Да, это основное отличие. Его следует формулировать слегка иначе, но по сути оно так.

> А потом у нас появится сложная логика внутри if (button) и мы заходим вынести её в
функцию.
И вынесем. В этом один из бонусов.

> А потом - захочется разделить Draw и Update
Основная идея в том, что не захочется.

> Всё без аллокаций. То есть, если единственный пойт это IMGUI в аллокациях - то это в огороде бузина, в киеве дядька.
Аллокации не при чем.

> Если развивать до любого уровня, что бы пользователю было красиво (плавное затухание и тп) и было много кнопочек - то превратится в обычную схему.
Я повторюсь, define "и тп". Затухание то же делается тривиально.
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 12:58 am (UTC)

Re: ИМХО, просто - потому что просто.

Поправка к "не захочется" - it depends, можно делать многопроходные схемы, насколько я понимаю, так работает GPL-библиотека, на которую я дал линк.

Забыл уточнить, состояние слайдера это что, bgcolor или value? value - да, состояние, но в общем не совсем состояние и не совсем слайдера. У тебя же в приложении есть где-то этот int, который ты модифицируешь слайдером? bgcolor - тут вообще хак, в принципе - мог бы быть глобальным состоянием. Хотя конечно скорее был бы в теме.
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 01:02 am (UTC)

Re: ИМХО, просто - потому что просто.

и кстати, что такое много кнопочек? :)
(Reply) (Parent) (Thread)
[User Picture]From: _winnie
2007-03-31 10:20 am (UTC)

Re: ИМХО, просто - потому что просто.

Много кнопочек - это два десятка button в одной функции + два десятка их state где-то выше
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 10:32 am (UTC)

Re: ИМХО, просто - потому что просто.

http://zeux.info/pub/temp/calc2.jpg
тут достаточно кнопочек? :)
(Reply) (Parent) (Thread)
[User Picture]From: binstream
2007-03-31 05:33 am (UTC)
Текстуры из public демок Unigine, да простят меня Frustum и binstream.

Передам нашему дизайнеру, что у нее теперь и дизайн GUI тырят, помимо веб- и прочего дизайна =) Так-то не жалко, только ссылки указывайте и в коммерческие проекты не пихайте, пожалуйста.
(Reply) (Thread)
[User Picture]From: zeux
2007-03-31 09:55 am (UTC)
Естественно.
(Reply) (Parent) (Thread)
[User Picture]From: _gvozdoder_
2007-03-31 02:45 pm (UTC)
Во-первых, баланс данные-код я предпочитаю, по возможности, смещать в сторону данных.
Во-вторых, бывают ситуации, когда список всех элементов интерфейса бывает по меньшей мере очень полезен. Например, в "Альфа: Антитеррор" иконки персонажей огибали элементы интерфейса, будучи прикрепленными к краям экрана (см. скриншоты http://screenshots.ag.ru/ag15/geo/14882/12-r.jpg и http://screenshots.ag.ru/ag15/geo/14882/09-r.jpg).
В-третьих, соглашусь с _winnie, что любые дополнительные навороты лягут тяжким грузом на клиентский код.
В-четвертых, в чистом виде IMGUI плохо масштабируется (в голове сразу пошли мысли про аналоги glGenLists, glNewList и т. д.)
(Reply) (Thread)
[User Picture]From: zeux
2007-03-31 04:12 pm (UTC)
Первый пункт мне комментировать сложно :)
Второе - зависит, конечно, от того, где лейаут остального гуи. Но безусловно ситуации бывают. Они кстати даже решаются, можно опять же кешировать всякое, ну или два прохода. Конечно, будет менее удобно, и сильно ближе к RMGUI. См. ниже.
Третий и четвертый пункт нуждаются в пояснении, потому что "дополнительные навороты" и "плохо масштабируется" бесконечно далеки от конкретики.

Я хотел бы на всякий случай уточнить, что я совсем не утверждаю, что в любой задаче следует использовать IMGUI. Я попробовал, мне понравилось. Цель дискуссии - исключительно выяснить для себя возможности подхода.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: zeux
2007-03-31 03:37 pm (UTC)
Повторяю, пост о том, что существует такое IMGUI. Прочитавший пост поймет, что это не конкретная библиотека.

Если нет колбеков, но есть скрипты, то проблема наверняка не в колбеках!
(Reply) (Parent) (Thread)
[User Picture]From: cofffe
2007-03-31 03:22 pm (UTC)
мое ИМХО - Хороший вариант когда довольно четко известно что надо сделать, а не надо делать "расширяемую data-driven систему, c кучей _возможно_ полезных фич". Т.е. получается подход к GUI в примерно XP стиле.
Если правильно понял :)
(Reply) (Thread)
[User Picture]From: zeux
2007-03-31 03:39 pm (UTC)
Я в целом согласен. Уточню, что мне было бы достаточно не "четко известно, что надо сделать", а возможность распределить написание GUI шире, чем в 1 таск (хотя оно в любом случае будет так :)). Т.е. сделали достаточную на текущий момент базу. Как только понадобилось что-то еще - быстро сделали это. Как-то так.

Систему с кучей возможно полезных фич, однако, я бы не стал делать ни в каком варианте :)
(Reply) (Parent) (Thread)
[User Picture]From: cofffe
2007-03-31 04:18 pm (UTC)
"Систему с кучей возможно полезных фич" - расширяемый дизайн. Т.е. базовая догика допускает добавление "фич". В твоем(в системе гуи которую ты описываешь) случае понятия "базовая логика" по сути нет. Есть просто "логика гуи". Так?
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 04:23 pm (UTC)
Ну, есть кое-какая общая функциональность, которая отдельно - это мб можно назвать базовой логикой. Все расширяется очень тупо - надо сделать новый контрол? Добавили функцию. Надо изменить функциональность существующего? Изменили ф-ию. И так далее.
Все очень прямолинейно, и это то, что мне нравится больше всего :)
(Reply) (Parent) (Thread)
[User Picture]From: cofffe
2007-03-31 04:30 pm (UTC)
ну да. по сути взгляд Си-шника на проблему. перешли от ООП к простому функциональному программирование и поняли что программы можно писать просто не придумывая пару неймспейсов и десяток классов :)
Но истина как всегда между. :) И то что остается - делает программированием чуть больше чем ремесло.
(Reply) (Parent) (Thread)
[User Picture]From: cofffe
2007-03-31 04:36 pm (UTC)
но для конкретики. нужна система GUI которую:
* удобно использовать
* не содержит лишних зависимостей (от модулей которые гуи используют)
* можно быстро прототипировать используя визуальный редактор.

и интересно как это все сделать не выбиваясь из рамок IMGUI. сможешь объяснить?
(Reply) (Parent) (Thread)
[User Picture]From: zeux
2007-03-31 06:06 pm (UTC)
Я IMGUI попробовал в первый раз 3 дня назад, такие вопросы лучше не мне задавать :)

Плохо с визуальным редактором. Без RM надстройки, использующей IMGUI, я не очень знаю, как его делать. Много на эту тему я не думал, т.к. мне пока такое не нужно.

Со всем остальным проблем вроде возникнуть не должно.
(Reply) (Parent) (Thread)
From: ex_zorgg254
2007-04-05 09:15 pm (UTC)
Я думаю, ничего не мешает подгружать какие-то статические данные заранее, из внешнего редактируемого файла.

xml:

<button x=10 y=10 caption="Click me" id="Button1" />

cpp:

if ( button("Button1" ) ) MessageBox("Clicked.");

...

при чем, вызов button("Button1") вполне соответствует концепции IMGUI - он и рисует кнопку и возвращает её состояние. Просто принимает все параметры - положение и caption - в виде ссылки на запись в некоторой загружаемой таблице, а не как формальные параметры.
(Reply) (Parent) (Thread)
[User Picture]From: cofffe
2007-03-31 04:23 pm (UTC)
К слову. Если честно то не понятно причем тут GUI вообще. Вроде все что описано подойдет фактически для любой системы состоящей из (взаимодействующих) элементов. В т.ч. и для игры. И возможно это и есть наиболее экономически правильных подход к созданию логических аркад и всего подобного.
(Reply) (Thread)
[User Picture]From: zeux
2007-03-31 04:25 pm (UTC)
Конечно, GUI на самом деле совсем не при чем. Решение создавать систему в immediate mode/retained mode применимо к чему угодно, просто вывод в каждом конкретном случае каждый для себя делает разный.
(Reply) (Parent) (Thread)