Мини-лекция про IMGUI [лектор - Zeux] (комментарии)

Мини-лекция про IMGUI [лектор - Zeux] (комментарии)

Это сообщение сгенерировано автоматически.

Во-блин! Только увидел!
НЕ ДЕЛАЙТЕ ТАК!!! Это в ЛЮБОМ случае который чуть сложнее тривиального приведет даже страшно подумать к чему.
Размазывать код гуи по всему проекту это ппц.
Zeux
ты реально(до сих пор? пост просто давно был) не понимаешь почему это плохо?

> НЕ ДЕЛАЙТЕ ТАК!!!
ТАК это как?

> Это в ЛЮБОМ случае который чуть сложнее тривиального приведет даже страшно подумать к чему.
> Размазывать код гуи по всему проекту это ппц.
o_O размазывать код гуи по всему проекту как-то относится к IMGUI?

> ты реально(до сих пор? пост просто давно был) не понимаешь почему это плохо?
А ты понимаешь? Расскажи, если понимаешь...

Zeux
:)
>ТАК это как?
я подумал, что будет понятно, что я про использование IMGUI.

>o_O размазывать код гуи по всему проекту как-то относится к IMGUI?
могу пояснить, просто я подумал что и так понятно. просто используя этот так называемый IMGUI у тебя выйдет просто мешанина кода гуи с игровым и не дай бог системным, мало того IMGUI это невероятный 100%й тормозняк, ибо оптимизации он не поддается(если не рассматривать примитивизмы типа "а сколько тактов на функцию ушло").

>А ты понимаешь? Расскажи, если понимаешь...
Как надо я рассказывать пожалуй не буду(надоело уже), а вот минусов IMGUI подхода могу еще привести. Только на конкретном примере уже чтобы голословным не быть.

> могу пояснить, просто я подумал что и так понятно. просто используя этот так называемый IMGUI у тебя выйдет просто мешанина
> кода гуи с игровым и не дай бог системным
Откуда такая идея?

> мало того IMGUI это невероятный 100%й тормозняк, ибо оптимизации он не поддается(если не рассматривать примитивизмы типа "а сколько тактов на функцию ушло")
А такая идея откуда?

> минусов IMGUI подхода могу еще привести. Только на конкретном примере уже чтобы голословным не быть.
Угу, нужны примеры ко всему.

Cool Ace
Ты серьезно не понимаешь, что проблемы IMGUI мягко говоря совсем не те, о которых ты пишешь?

Zeux
Допрос? по первым 2м пунктам, во первых это не идеи это факты, а ответ  значит "из жизненного опыта", который не маленький в этой теме. Или, чтобы более понятно, то я просто работал с разными ГУИ столько, что знаю что к чему приводит и при каких условиях, причем знаю и видел это все и на практике, мало того я предсказывал проблемы в практике, которые возникнут при использовании того или иного подхода, еще до реализации идей на практике.

Значит пример такой, есть игра в которой интерфейс достаточно объемный, чтобы называть его сложным, полный редизайн и рефункционал(назовем так изменение функциональности, к примеру использовалось текстовое отображение уровня персонажа, потом его сменили на прогресс бар) его проводился 4 раза на моей памяти. Что придется делать в IMGUI? Нам пришлось 2 раза подправить код. Скорость программирования окна в случае IMGUI какая? В нашем случае с RMGUI окно вставлялось за час(окно это 20 живых контролов и еще примерно 20 оформительских). Локализовать как? В нашем случае была статическая локализация(на китайский в том числе).

MiF
Возможно! Каковы истинные проблемы IMGUI? И вообще какие проблемы могут быть с GUI? Это же так элементарно! Это же не ШЭЙДЫРЫ ПЕСАДЬ :))))

> Допрос? по первым 2м пунктам, во первых это не идеи это факты, а ответ значит "из жизненного опыта", который не маленький в этой теме.
> Или, чтобы более понятно, то я просто работал с разными ГУИ столько, что знаю что к чему приводит и при каких условиях, причем знаю и видел это все и на практике, мало того я предсказывал проблемы в практике, которые возникнут при использовании того или иного подхода, еще до реализации идей на практике.
Это все чудесно, но к конкретике - никакого отношения не имеет. Я хотел бы услышать конкретные комментарии по поводу мешанина кода гуи с игровым и не дай бог системным и IMGUI это невероятный 100%й тормозняк, ибо оптимизации он не поддается.

> Значит пример такой, есть игра в которой интерфейс достаточно объемный, чтобы называть его сложным, полный редизайн и рефункционал(назовем так
> изменение функциональности, к примеру использовалось текстовое отображение уровня персонажа, потом его сменили на прогресс бар) его проводился 4 раза
> на моей памяти. Что придется делать в IMGUI? Нам пришлось 2 раза подправить код.
Ну как бы если у тебя есть некоторая сущность, которая представляет собой уровень персонажа, и внутри нее в случае скажем RMGUI скрыт ProgressBar или Label - то все просто, а если везде явно используется ProgressBar - то все сложно.
Если у тебя есть скажем функция, и внутри нее в случае IMGUI скрыт do_progress_bar или do_label - то все просто, а если везде явно используется do_progress_bar - то все сложно.

> Скорость программирования окна в случае IMGUI какая? В нашем случае с RMGUI окно вставлялось за час(окно это 20 живых контролов и еще примерно 20 оформительских).
Скорость программирования окна в случае IMGUI - за сколько ты успеешь набрать тот код :) 20 контролов, живых, строчек по 10 на контрол... Еще строчек 40-50 на оформительские, you get the idea. Зависит исключительно от качества imgui фреймворка - как и в случае rmgui, плохой фреймворк способен все испортить.

Zeux
>Если у тебя есть скажем функция, и внутри нее в случае IMGUI скрыт do_progress_bar или do_label - то все просто, а если везде явно используется do_progress_bar - то >все сложно.
Таких абстрагирующих оберток сколько понадобится на проект где много ГУИ?

Значит конкретные комментарии
производительность сядет на выводе нестатичного форматированного текста, в листбокс к примеру, батчинг бай бай(по крайней мере батчинг естественным путем а не извращаясь)
верстать гуи силами программистов это имхо дол...ство менеджеров.
невозможно отделить и отлаживать гуи от среды где он находится лекким способом
редактированию слабо поддается.
а по поводу размазывания кода.. как и где ты сделаешь окно управляющее опциями игры(геймплей + система), какой объем кода такого окна?
Вопрос: в реальных проектах использовал такое IMGUI? Если да то сколько времени потрачено примерно на разработку интерфейса.

Cool Ace
> Таких абстрагирующих оберток сколько понадобится на проект где много ГУИ?
Ну ровно столько же, сколько при RMGUI, нет?

> производительность сядет на выводе нестатичного форматированного текста, в листбокс к примеру, батчинг бай бай(по крайней мере батчинг естественным путем а не извращаясь)
Нестатичный форматированный динамический текст в играх? Ну, будет тормозить, сделаем кеширование, с явным setText, увы.

> верстать гуи силами программистов это имхо дол...ство менеджеров.
> невозможно отделить и отлаживать гуи от среды где он находится лекким способом
Ура!! Мы наконец-то наткнулись на недостаток IMGUI...

> а по поводу размазывания кода.. как и где ты сделаешь окно управляющее опциями игры(геймплей + система), какой объем кода такого окна?
Ровно там же, где и RMGUI, объем кода надо считать после, а не до...

> Вопрос: в реальных проектах использовал такое IMGUI?
Нет, в реальных проектах я не занимаюсь разработкой GUI :)

Zeux
>Ну ровно столько же, сколько при RMGUI, нет?
нет, нужно просто немного дальше пойти в своих представлениях архитектуры RMGUI

>Нестатичный форматированный динамический текст в играх? Ну, будет тормозить, сделаем кеширование, с явным setText, увы.
какая разница где, важно что решаться это будет уже так как в RMGUI, а значит...

>Ура!! Мы наконец-то наткнулись на недостаток IMGUI...
Это ясно как божий день с самого начала.

>Ровно там же, где и RMGUI, объем кода надо считать после, а не до...
нет

>Нет, в реальных проектах я не занимаюсь разработкой GUI :)
Я так и думал, вот именно поэтому я и сказал НЕ ДЕЛАЙТЕ ТАК, ибо гуи настолько тонкая и тяжелая вещь, что  шаг влево или вправо это ппц, огромные просто затараты времени, человеческих ресурсов, денег и нервов. Самая дибилистическая ошибка многих фирм в том что считается что ШЭЙДЭР это круто и сложно, а гуй, система ресурсов, организация логики это просто. Такой подход ведет к тому что игры затягиваются в 2-3 раза по срокам и деньгам.

Извини, мне с тобой абсолютно не о чем говорить - я услышал только два аргумента, про текст и про про редактор, все остальное - это какие-то непонятные экивоки в стиле "мое RMGUI делает твое IMGUI не напрягаясь".

> Самая дибилистическая ошибка многих фирм в том что считается что ШЭЙДЭР это круто и сложно, а гуй, система ресурсов,
> организация логики это просто. Такой подход ведет к тому что игры затягиваются в 2-3 раза по срокам и деньгам.
Нихрена себе, гуй, система ресурсов, и организация логики это уже вещи одного порядка? Много того гуя в шутерах и в экшенах?

Zeux
Слушай ну ты чего? Просто имхо только одно то что редактор это целая эпопея, это уже такой минус против которого все плюсы ничто. Производительность в любом случае меньше, те просто недоступны те оптимизации которые доступны в случае RMGUI. А самое главное плюсов нет, все что перечислено как плюсы это элементарно делается в RMGUI. Прикол еще в том что с РМГУИ теоретически можно вообще не программировать, а вот в случае IMGUI этого неизбежно просто катострофически много. Локализовать как? В код пробивать "ПА РУСКi"? Или ID по которому кто-то будет возвращать правильный текст и кучу флагов для текста со смыслом "а тут по арабски" или "а тут по китайски сверху вниз". Вот еще тема... как помигать кнопкой, а если 5 типов мигания и если одна мигает зеленым то другая должна мигать красным. и они находятся как бы в разных кусках кода? Как это сделать без управления?

Про "моё RMGUI" я тут вообще не говорил, я сказал, что пробовал много разного.

>Нихрена себе, гуй, система ресурсов, и организация логики это уже вещи одного порядка? Много того гуя в шутерах и в экшенах?
Да одного порядка, если в игре нужна более чем одна кнопка.

ЗЫ. Не хочешь не говори. Научись просто видеть.
ЗЗЫ. Все что я описал не надуманные примеры, а из жизни.

Вообще на самом деле тема интересная, потому как IMGUI vs RMGUI это такой классический тест на вменяемость процесса.
IMGUI vs RMGUI - это экономия на масштабе "стоимость изготовления фишки" vs "стоимость изготовления тула для изготовления фишки + стоимость изготовления фишки на туле".
Стоимость в данном случае понимается и как классическая стоимость дизайн+кодинг+QA+управление, так и непрямая стоимость в виде потери/приобретения opportunities.
Поэтому очень интересно как в конкретных случаях выглядят гибриды lerp(i, IM, RM).

В космосе экономии на масштабе - Правильнее и Дешевле делать в RMGUI.
Однако любой тул создает предпосылки для борьбы не с проблемой (фишкой), а с собственно тулом.
Типа "но ведь это же кнопка, а кнопки не умеют дрожать и разделяться на две кнопки!".
Естественный ответ на это - "кнопка - у тебя в голове, а в дизайне написано - дрожит и разделяется".

Пример из реальной жизни.
При споре о стоимости работ по изготовлению довольно сложного меню я привел прямолинейный аргумент - если тупо накодить всё меню тупо руками (~IMGUI), получается никак не больше чем X.
А если через Правильный и Удешевляющий Тул - то почему-то 10*X, ибо надо много всего дописать, перерефакторить и т.п.

Через это и возникают гибриды по схеме
    простой IMGUI
    простой RMGUI с простым тулом нацеленным на конкретные use-cases (и поэтому всё работает)
    неподъемный RMGUI, который возводит слишком высокую стену "кнопки бывают такие, такие и вот такие, альтернативно - пиши совсем свою кнопку"
    простой IMGUI поверх RMGUI (который в данном случае скорее из-за "так исторически сложилось")

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

aruslan
>Пример из реальной жизни.
>При споре о стоимости работ по изготовлению довольно сложного меню я привел прямолинейный аргумент - если тупо накодить всё меню тупо руками >~IMGUI), >получается никак не больше чем X.
>А если через Правильный и Удешевляющий Тул - то почему-то 10*X, ибо надо много всего дописать, перерефакторить и т.п.

Либо клинический случай с тулом был, либо я не верю в такое, ибо мой пример из жизни когда и тул и система выдержала много переделок достаточно сложных окон (по 5 раз), мало того система насколько мне известно живет и нормально в другом проекте.

>Если кто видел живой IMGUI или гибрид в сравнительно реальной жизни - расскажите, очень интересно.

Примером нормального как бы гибридного подхода может наверное считаться программирование одного "окна" в пределах одной единицы трансляции, тогда есть пример у меня :) - гуи который в DXUT все просто и быстро делается, для девелоперских нужд быстро и просто создаются достаточно сложные "окна".

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