 | Что-то давно у меня не было нормальных околотехнических постов. А картинок не было уже очень давно (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 и
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
binstream. Руками собраны в атлас - на всякий случай замечу, что IM совсем не означает ">= 1 DIP per control", отсутствия кеширования и прочих подобных вещей. Впрочем, это все есть в видео/на форуме. 
March 31 2007, 00:25:21 UTC 5 years ago
ИМХО, просто - потому что просто.
Не понял ничего из поста, кроме того что IMGUI есть. Посмотрел туториал, который "наивный". Чем оно отличное от всего другого, непонятно. Просто оно реализует очень простую функциональность, потому и простое. При постепенном усложнеии всё будет усложнятся до обычной схемы, что бы меньше писать кодеру. Так, например slider в пятой части уже имеет state.При постепенном усложнении и рефакторинге этот 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 в аллокациях - то это в огороде бузина, в киеве дядька.
Если развивать до любого уровня, что бы пользователю было красиво (плавное затухание и тп) и было много кнопочек - то превратится в обычную схему.
March 31 2007, 00:29:43 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
Хотя, если слабать по быстрому главное меню для харкорного шутера, где дизайн GUI - дело десятое, то подойдёт.March 31 2007, 01:04:11 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
Цитата из "Why IMGUI arguments fall short"?При чем здесь дизайн, я слабо понимаю. Только потому, что в туториале SDL-ные квадратики?
March 31 2007, 10:02:36 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
>При чем здесь дизайн, я слабо понимаю. Только потому, что в туториале SDL-ные квадратики?Не, потому что в туториале - всё "мгновенное".
>Я повторюсь, define "и тп". Затухание то же делается тривиально.
А как его добавить?
>> static-переменная в функции в C++ - часто неприемлема. Например, потому что зовётся из двух разных мест
>ты собираешься рисовать GUI из нескольких потоков?
Нет, просто зовём из двух мест. Два похожих меню на одном экране например.
Или собираем из простых элементов кнопки+edit box сложный - выпадающий combo-box. И где теперь функции combo_box хранить стейты своих подкнопок?
March 31 2007, 10:27:05 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
> Не, потому что в туториале - всё "мгновенное".Не понимаю.
> А как его добавить?
Добавление внутреннего стейта fade time. hash_map
Не понимаю.
> А как его добавить?
Добавление <b>внутреннего</b> стейта fade time. hash_map<int, float>, и в конце каждого кадра уменьшение float-ов и удаление записей, где он <= 0. Приложение его вообще не видит.
> Нет, просто зовём из двух мест. Два похожих меню на одном экране например.
Ну, и где тогда проблемы?
> Или собираем из простых элементов кнопки+edit box сложный - выпадающий combo-box. И где теперь функции combo_box хранить стейты своих подкнопок?
Винни, у кнопок нет стейтов. Даже в том туториале нет.
March 31 2007, 00:53:34 UTC 5 years ago
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 "и тп". Затухание то же делается тривиально.
March 31 2007, 00:58:40 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
Поправка к "не захочется" - it depends, можно делать многопроходные схемы, насколько я понимаю, так работает GPL-библиотека, на которую я дал линк.Забыл уточнить, состояние слайдера это что, bgcolor или value? value - да, состояние, но в общем не совсем состояние и не совсем слайдера. У тебя же в приложении есть где-то этот int, который ты модифицируешь слайдером? bgcolor - тут вообще хак, в принципе - мог бы быть глобальным состоянием. Хотя конечно скорее был бы в теме.
March 31 2007, 01:02:59 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
и кстати, что такое много кнопочек? :)March 31 2007, 10:20:25 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
Много кнопочек - это два десятка button в одной функции + два десятка их state где-то вышеMarch 31 2007, 10:32:25 UTC 5 years ago
Re: ИМХО, просто - потому что просто.
http://zeux.info/pub/temp/calc2.jpgтут достаточно кнопочек? :)
March 31 2007, 05:33:57 UTC 5 years ago
Передам нашему дизайнеру, что у нее теперь и дизайн GUI тырят, помимо веб- и прочего дизайна =) Так-то не жалко, только ссылки указывайте и в коммерческие проекты не пихайте, пожалуйста.
March 31 2007, 09:55:46 UTC 5 years ago
March 31 2007, 14:45:37 UTC 5 years ago
Во-вторых, бывают ситуации, когда список всех элементов интерфейса бывает по меньшей мере очень полезен. Например, в "Альфа: Антитеррор" иконки персонажей огибали элементы интерфейса, будучи прикрепленными к краям экрана (см. скриншоты http://screenshots.ag.ru/ag15/geo/1
В-третьих, соглашусь с _winnie, что любые дополнительные навороты лягут тяжким грузом на клиентский код.
В-четвертых, в чистом виде IMGUI плохо масштабируется (в голове сразу пошли мысли про аналоги glGenLists, glNewList и т. д.)
March 31 2007, 16:12:51 UTC 5 years ago
Второе - зависит, конечно, от того, где лейаут остального гуи. Но безусловно ситуации бывают. Они кстати даже решаются, можно опять же кешировать всякое, ну или два прохода. Конечно, будет менее удобно, и сильно ближе к RMGUI. См. ниже.
Третий и четвертый пункт нуждаются в пояснении, потому что "дополнительные навороты" и "плохо масштабируется" бесконечно далеки от конкретики.
Я хотел бы на всякий случай уточнить, что я совсем не утверждаю, что в любой задаче следует использовать IMGUI. Я попробовал, мне понравилось. Цель дискуссии - исключительно выяснить для себя возможности подхода.
Deleted comment
March 31 2007, 15:37:18 UTC 5 years ago
Если нет колбеков, но есть скрипты, то проблема наверняка не в колбеках!
March 31 2007, 15:22:20 UTC 5 years ago
Если правильно понял :)
March 31 2007, 15:39:45 UTC 5 years ago
Систему с кучей возможно полезных фич, однако, я бы не стал делать ни в каком варианте :)
March 31 2007, 16:18:33 UTC 5 years ago
March 31 2007, 16:23:05 UTC 5 years ago
Все очень прямолинейно, и это то, что мне нравится больше всего :)
March 31 2007, 16:30:13 UTC 5 years ago
Но истина как всегда между. :) И то что остается - делает программированием чуть больше чем ремесло.
March 31 2007, 16:36:18 UTC 5 years ago
* удобно использовать
* не содержит лишних зависимостей (от модулей которые гуи используют)
* можно быстро прототипировать используя визуальный редактор.
и интересно как это все сделать не выбиваясь из рамок IMGUI. сможешь объяснить?
March 31 2007, 18:06:19 UTC 5 years ago
Плохо с визуальным редактором. Без RM надстройки, использующей IMGUI, я не очень знаю, как его делать. Много на эту тему я не думал, т.к. мне пока такое не нужно.
Со всем остальным проблем вроде возникнуть не должно.
5 years ago
March 31 2007, 16:23:01 UTC 5 years ago
March 31 2007, 16:25:31 UTC 5 years ago