Войти
ПрограммированиеФорумГрафика

Рендер GUI (4 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#45
16:10, 4 фев. 2019

Suslik
> то надо брать imgui, вообще без вариантов. поддержку html имеет смысл как раз
> интегрировать для юзерфрендли интерфейса со скиннингом и свистоперделками.
Я хз, варианты игрового gui, которые я смотрел все были с чудовищным user expirience. Даже банальнейшая вещь - нажать кнопку мышкой и не отжимая отвести мышь в сторону - в десктопе действие не сработает, в играх почти поголовно сработает. Всякий отладочный и профилирующий GUI по мне так лучше по максимому опыт десктопа наследует, чтобы и по ctrl+V вставлялось и по Ctrl+стрелки бегало и выделение текста нормальное было (в играх к слову редко встречается), и клики по тексту чекбокса нормально отрабатывали. Вылетела ошибка в движке в виде игровой-модалки, хочу нажать Ctrl+C и чтобы текст в буфере был.

gamedevfor
> Это ты называешь объяснением? Это им так захотелось.
Я если что веб-разработчик (серверный правда), не рассказывай мне какого оно :D

gamedevfor
> Думаю что HTML слишком тяжелый для игр, иначе не было бы всяких WebGL-ей в нём.
У HTML и WebGL абсолютно разные области применения.

gamedevfor
> К тому же формат слишком статичный в то время когда в играх нужен очень
> динамичный UI.
ээ, чего? По сравнению с вебом интерфейс игр просто неизменяемый.


#46
16:21, 4 фев. 2019

Suslik
> imgui
глянул в пол глаза - описание интерфейса в коде? Там ничего декларативного нет что-ли? Я уже оочень давно так не писал, даже моя собственная UI система, которую почти 13 лет назад писал, работала на xml-ках.

#47
(Правка: 17:25) 17:25, 4 фев. 2019

Мизраэль
> Я уже оочень давно так не писал, даже моя собственная UI система, которую почти
> 13 лет назад писал, работала на xml-ках.
фигово тебе. imgui специально разрабатывается для отладочного gui и для тулзов. одна кнопка — одна строчка в коде, причём там, где она понадобилась. а тебе надо искать свой xml, добавлять в него какой-нибудь убогий лэйаут, в лэйаут добавлять кнопку, по какому-нибудь айдишнику вешать на неё коллбэк, в коллбек передавать какой-нибудь экземпляр класса для отладки, в этом классе делать какой-нибудь метод для отладочной информации и прочее удовольствие, так скажем, на любителя.

#48
(Правка: 23:30) 23:25, 4 фев. 2019

Мизраэль
> Я хз, варианты игрового gui, которые я смотрел все были с чудовищным user expirience.
ты бы отличал игровой узкоспециализированный гуй от полноценного
у меня, например, в играх небыло надобности отводить курсор от кнопок

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

#49
8:00, 5 фев. 2019

clc
> в некоторых играх текст может выводится текстурными плашками, а его ввода не
> предусмотрено. И, вообще говоря, мало где предусмотрено.

Как так? А ввести имя игрока например? Или какие-нибудь настройки?

#50
8:01, 5 фев. 2019

clc
> у меня, например, в играх небыло надобности отводить курсор от кнопок

Не даешь пользователю второй шанс?

#51
12:48, 5 фев. 2019

Suslik
> фигово тебе
если GUI нужен не вот прям один раз кнопку добавить и пару текстовых полей с параметрами для отладки, то проще нормально свёрстанную разметку иметь, имхо. Ну и плюсом получаем возможность редактировать всё это в рантайме, открыл xml, добавил пару нужных полей, сохранил, а двиг подхватил всё это, с хардкодом у тебя так не выйдет.

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

clc
> в некоторых играх текст может выводится текстурными плашками, а его ввода не
> предусмотрено. И, вообще говоря, мало где предусмотрено.
- почти во всех играх с рейтингами есть ввод имени игрока
- в настройках можно указать имя сервера или его адрес
- иногда нужны слайдеры с нормальным функционалом (в настройках гаммы или громкости например) - таскание за указатель, клик в полосе, изменение значения кнопками
да много всего может потребоваться и если это реализовать на от@#бись, то пользователи будут страдать, не надо так делать.

#52
13:15, 5 фев. 2019

Мизраэль
> с хардкодом у тебя так не выйдет.
У некоторых выходит
http://chrismdp.com/2015/08/how-to-add-live-code-reload-to-your-game/
http://www.randygaul.net/2017/02/24/writing-a-game-engine-in-2017/
но это, ясное дело,- тоже на любителя.

#53
16:08, 5 фев. 2019

Мизраэль
У нас вот есть два аналогичных игровых проекта, один на XML android интерфейсе, а второй полностью самописный, где интерфейс создается кодом.
Мало того, что весь код теперь работает стабильнее, так как отсутствует привязка по айдишникам, так его и легче создавать и вешать на них всякие обработчики и взаимодействовать с другими элементами, потому что вот все оно в одном месте, а не раскидано по файлам.

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

Единственный минус - нельзя увидеть предполагаемый результат по коду.

#54
18:55, 5 фев. 2019

Suslik
>imgui специально разрабатывается для отладочного gui и для тулзов.

Для отладочного gui и тулзов больше какой нить Delphi/C++Builder подойдёт.

#55
17:38, 6 фев. 2019

Che@ter
> У нас вот есть два аналогичных игровых проекта, один на XML android интерфейсе,
> а второй полностью самописный, где интерфейс создается кодом.
если у вас интерфейс пишет программист, то можно дальше не продолжать :)
впрочем, а в коде у вас как интерфейс написан? Прям вот так:

var button1 = new Button();
button1.Caption = "OK";
button1.Position = ...
button1.Size = ...
panel1.Controls.Add(button1);

Если так, то это же просто треш.

Che@ter
> Мало того, что весь код теперь работает стабильнее, так как отсутствует
> привязка по айдишникам, так его и легче создавать и вешать на них всякие
> обработчики и взаимодействовать с другими элементами, потому что вот все оно в
> одном месте, а не раскидано по файлам.
Это никак не связано с вариантом реализации интерфейса. Для меня тут очевидно только то, что у вас программисты криворукие, если умудрились на декларируемом языке описать нестабильный интерфейс.

Che@ter
> В обеих вариантах нужно описывать элемент, количество строк одинаковое
LOL что? Сравни с примером выше:

 <Button Caption="OK" Position="10, 20" Size="20,80" />
Это ещё и валидируется схемами и в рантайме можно перестраивать.

Che@ter
> для создания динамического интерфейса вариант с кодом выигрывает в удобности,
> ведь уже нет разницы создавать динамически или статически.
в чём удобство то? декларативный язык - жирный плюс над императивным, возможность валидации интерфейса в design time, возможность разрабатывать интерфейсы непрограммисту, почти нулевой бойлерплейт, возможность навигации по описанию интерфейса (за счёт иерархии).

#56
17:40, 6 фев. 2019

FordPerfect
> У некоторых выходит
Я лучше варианты знаю. Писать интерфейс на С++ - это вообще убожество, я бы хоть C# или VB.NET взял, а их можно в рантайме без проблем компилить.

#57
(Правка: 18:06) 17:51, 6 фев. 2019

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

> Если так, то это же просто треш.
Да, именно так.

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

> возможность разрабатывать интерфейсы непрограммисту
А зачем? Он все равно не сможет заставить этот интерфейс работать. Все равно придется программисту это делать. Потом он будет адски ругаться на реализацию этого "не-программиста".

> LOL что? Сравни с примером выше:
Предполагал такой вариант:

<Button
  Caption="OK"
  Position="10, 20"
  Size="20,80"
/>
В таком виде количество строк почти одинаковое. На плюсах тоже можно в одну строчку все написать.

> почти нулевой бойлерплейт, возможность навигации по описанию интерфейса (за
> счёт иерархии).
Если этот интерфейс разрабатывается как универсальный для общего пользования, то лучше выбрать твой вариант. А если интерфейс делается чисто для своего закрытого движка/своего проекта - то зачем тратить на это время?

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

#58
20:55, 6 фев. 2019

Мизраэль
> Если так, то это же просто треш.
Это не треш. :)

> Это ещё и валидируется схемами и в рантайме можно перестраивать.
То, что ты назвал трешем - валидируется компилятором. А если чуть-чуть подумать, то этот интерфейс и в рантайме можно перестраивать.

> возможность разрабатывать интерфейсы непрограммисту
Вот только по факту человек, который руками набивает <Button Caption="OK" Position="10, 20" Size="20,80" /> - программист. И его точно так же можно научить набивать это:

var button1 = new Button();
button1.Caption = "OK";
button1.Position = ...
button1.Size = ...
panel1.Controls.Add(button1);

>почти нулевой бойлерплейт
Что для тебя бойлерплейт? button1 перед каждым словом? Так это решается. Например на шарпе можно так:
Button.Set(Caption: "OK", Position: {10, 20}, Size: {20, 80});
Что как бы не сложнее:
<Button Caption="OK" Position="10, 20" Size="20,80" />
На плюсах можно например так:
Button->Cation("OK")->Position(10, 20)->Size(20, 80)
То есть избавиться от бойлерплейта при желании - расплюнуть.

> возможность навигации по описанию интерфейса (за счёт иерархии)
Иерархии чего? Ты на языке программирования так же можешь описать эту самую иерархию:

panel.AddChilds(
  new Button.Set(Caption: "OK", Position: {10, 20}, Size: {20, 80}),
  new Button.Set(Caption: "Cancel", Position: {110, 20}, Size: {20, 80})
);

Если ты программист, набиваешь руками xml с интерфейсом, и считаешь, что это благо - то твой мозг когда-то свернул не туда, и был успешно промыт всякими xaml-ами.
Для программиста проще писать интерфейс на том языке, на котором он пишет все остальное (именно поэтому существуют imgui и прочие библиотеки). Для дизайнера - проще иметь редактор, в котором он мышкой накидает кнопочек, как это было скажем в VCL в Delphi, только желательно иметь отдельный редактор. И этот редактор может сохранять "UI формы" в бинарном виде, xml для этого не нужен. Так что в чем xml хорош - так это в промывании мозга другим программистам, что собственно мы и видим на практике.

#59
23:11, 6 фев. 2019

MrShoor
> То, что ты назвал трешем - валидируется компилятором. А если чуть-чуть
> подумать, то этот интерфейс и в рантайме можно перестраивать.
компилятор только синтаксис валидирует, чего ты там понаписал ему пофиг.

MrShoor
> Вот только по факту человек, который руками набивает <Button Caption="OK"
> Position="10, 20" Size="20,80" /> - программист
не обязательно. Верстальщики никак не программисты.

MrShoor
> Что для тебя бойлерплейт? button1 перед каждым словом? Так это решается.
нет. Даже в примитивном однострочном примере уже жопой придётся вертеть и уменьшать читаемость в угоду краткости. А тут ещё даже биндингов нет.

MrShoor
> Button.Set(Caption: "OK", Position: {10, 20}, Size: {20, 80});
на шарпе это будет примерно так:

Panel.Controls.Add(new Button()
{
  Position = new Point(10, 10),
  Size = new Size(20, 80),
  Caption = new StackPanel()
  {
    Children = new List<UIControl>()
   {
      new Image()
     {
         Source = new BitmapImage()
        {
                ......
        },
        Width = 20,
        Heigt = 20,
     },
     new TextBlock()
    {
        Text = "OK",
        FontFamily = ....
        ....
    }
   }
  }
});

и на xaml:

<Button Position="10, 10" Size="20, 80">
   <StackPanel>
    <Image Source="some.jpg" Width="20" Height="20" />
    <TextBlock FontFamily="Arial" ...>My text here</TextBlock>
  </StackPanel>
</Button>
А теперь добавим анимацию, биндинги и стили и твой код можно выкидывать на помойку.
Ты просто похоже интерфейсы сложнее пары кнопок не рисовал.

MrShoor
> Для программиста проще писать интерфейс на том языке, на котором он пишет все
> остальное
Разве что для начинающего. Для нормального программиста надо использовать тот язык, на котором это проще реализовать, проще читать, проще поддерживать и меньше возможностей допустить ошибку.

MrShoor
> Для дизайнера - проще иметь редактор, в котором он мышкой накидает кнопочек,
> как это было скажем в VCL в Delphi, только желательно иметь отдельный редактор.
> И этот редактор может сохранять "UI формы" в бинарном виде, xml для этого не
> нужен. Так что в чем xml хорош - так это в промывании мозга другим
> программистам, что собственно мы и видим на практике.
существование HTML, XAML, QML, XML формы для андроида,  уже должно тебя насторожить, что возможно ты чего-то не понимаешь в профессии разработчика ПО.

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика