Pull to refresh

Comments 56

Киньте картинку рабочего стола, уж больно понравилась ) спасибо

в калде проще интерфейс сделать на шейдерах, из-за реализации 2 матричной проекции, там реализация оч красивая выходит, как бы сам интерфейс на вашем скриншоте говорит об этом(это просто обьекты 2д у которых есть свойства и размеры с расположением в ортогональной проекции соотв), у д3 тоже шейдеры скорее всего просто там еффекты уже накидываются на обьекты (dear Imgui где-то в той же степи, но dear Imgui просто даёт возможность не делать сразу свой интерфейс на шейдерах соотв)

наверно шейдеров нету в ультиме-онлайн, там всё на тайлах сделано, просто с картинка-текстурками работаем, хотя может в те времера были тоже шейдеры(в обновлённой ультиме не знаю вроде шейдеры, а может и нету не знаю ))

из примера текстового редактора на шейдерах это 4coder

у swing это g и рисование в поточный класс, в своё время эту технику показал thebennybox - она просто по производительности будет около акселерации до сих пор(почти аналог библиотека sdl(сдл может в софтварное рисование и в шейдерное))

Впечатлила libUI, так как единственная feels native

Какая-то очень странная штука, Gtk4 и одновременно Foundation Kit для MacOS и iOS плюс Win32. Ни документации ни примеров.

Сами-то пробовали это завести?

Не пробовал (лежит у меня в коллекции идей вместе с упомянутой libui). Причина: меня не устраивают библиотеки GUI с огородом кастомных функций API. Всего есть ~13 элементов форм, Они одинаковы на всех платформах и их свойства на 90% совпадают (размер, видимость, цвет...). Отсюда форма должна задаваться в JSON-е и, в зависимости от платформы, разворачиваться в множество нативных элементов. Любой элемент иметь доступ по ID и управляться API из 3-х функций: установть атрибуты, установить значение, взять значение. Размер такой библиотеки будет минимален (десятки килобайт кода). Похожее было реализовано в VC6 как ClassWizard и FormEditor с DDE.

Мой прототип для HTML

Любой элемент иметь доступ по ID и управляться API из 3-х функций: установть атрибуты, установить значение, взять значение

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

Современная форма это далеко не только ввод, это еще и например выбор из выпадающего списка и закладки (табы) и еще много чего.

Сейчас вожусь с мини-движком, превращающим С++ в (подобие) JS:

var x = "hello", y = 1, z = T_MAP;

z["a"] = x;

z["b"] = y;

z["c"] = false;

var str = z.json(), str2 = json("{ "a" : 1, "b" : [1,2,3, "hello"], "c" :{} } ");

z = 8;

z += 2;

...

...

Затем, когда дойдут руки до GUI, дам на GUI на github ссылку. ;)

дам на github ссылку. ;)

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

"некоторые" = 99,99% в процентном соотношении.

*

...Пора бы уже к этому привыкнуть.

А мне до них есть дело?! :)

А мне до них есть дело?! :)

Если быстро бегаете и вообще огнеупорны тогда конечно проблем нет )

egui, iced, tauri, fltk – тоже интересные библиотеки для ui

Для tauri там какой-то левый репозиторий, не относящийся к проекту, и использующий старую версию tauri.

Лучше по этой ссылке смотреть https://v2.tauri.app/

egui – универсальная библиотека, умеет как нативно рендерить под платформы, так и в веб, используя WebGL (никаких HTML/CSS/JS)

неплохо так вентиляторы разгоняет, когда работает в браузере ,")

тогда советую вам пересесть с celeron на какой-нибудь более новый процессор

Примерно как ютуб плеер, а то и того меньше.

А встречалось ли где-нибудь (не зацепился ли глаз за) сравнение с wxwidgets? Я давно хотел перевести один проект с wxwidgets на что-нибудь поизящнее, вдруг тут прямо упоминали о такой возможности?

Точно нет, wxwidgets сильно навороченный, там таблицы и тд.

Да, ожидаемо. Спасибо.

Забыли про Flutter, ElectronJS, ReactNative, Python со своими Frameworks.

Это все известные штуки, которые и так каждый день используются.

В добавку, если думано как самостоятельное/встраиваемое решение, то можно глянуть в сторону LVGL , вроде есть порты и для веба, и для нативных приложений.

Известный и непонятно куда разросшийся) пробовал его использовать для мк и монохромного дисплея и управления 4 кнопками, в итоге на второй тысяче строк у меня возникло стойкое ощущение, что я пишу CRM, всё снес, переехал на u8g2 Но умные часы и всякое цветное-переливающееся-тачевое на лвгл хорошо выходит, да.

Сейчас работаю с проектом на LVGL 9. Основную работу делает верстальщик в EEZ Studio. Эта библиотека явно не для монохромного дисплея. Мы её применяет для мелкого OLED 480p в 2 дюйма. Ну и 50 fps. Красиво выходит очень. С классными анимациями

Я просто не понял, как ввести событие нажатия механической кнопки в event loop либы, несколько раз перечитал раздел input devices - не помогло) Может, скинете минимальный пример?

Для тех, кто знает только Qt и GTK в первую очередь нужно было написать, что половина (а может и все, не смотрел) из представленного в статье -- это immediate-mode gui. И вообще рассказать, что бывают 2 вида режима GUI:

  • retain -- Qt, GTK, WinAPI и прочее традиционное. Вы описываете в коде интерфейс, а рисуется он в цикле событий, вам явно не видимом. Рассылает вам события, в которых вы действия и обрабатываете

  • immediate -- вы пишите код, который буквально рисует. Все, что еще не нарисовано (т.е. по коду находится ниже) еще нет. Помню, подумал, на сайте egui ошибка, как увидел, что там написано

    if button("click").clicked() {
      ...
    }
    

    Подумал, забыли в замыкание обернуть, как оно работать-то будет? На самом деле вы и пишите внутри цикла отрисовки, и сразу же проверяете наличие флагов от событий и "на лету" меняете то, что нужно отрисовать.

Соответственно, в immediate режиме вы все UI строите с нуля каждый кадр, можете представить, что будет с энергопотреблением, если не ухищряться это все кешировать.

Я честно говоря как-то не задумывался о таком разделении, поэтому не описывал. С учетом разности подходов, кто из них retain а кто immediate сразу и не скажешь.

Что касается скорости: в качестве тестового стенда был 20-летний ноутбук с линуксом, если уж там не тормозит, то полагаю на нормальном десктопе и подавно.

Энергопотребление не замерял, но скорее всего это мало актуально, поскольку большая часть представленных библиотек — для редакторов либо изначально рассчитана на работу с GPU.

Про энергопотребление - возможно речь идет о мобильных устройствах?

Современные рендереры уже давненько приспособились к тому, чтобы не перерисовывать то что не менялось, примерно также как и в retain режиме. Поэтому, пока у вас не рисуются графики и вы не тыкаете каждый кадр во все кнопки сразу просадка фпс и повышенное энергопотребление будет появляться исключительно из-за вашего кода.

Несколько лет назад оставлял коммент с подборкой из закладок.
Если не ограничиваться С/С++, то Home - HaxeUI можно посмотреть.
Сам использую и развиваю свое, но оно слишком недокументированно, чтобы им хвастаться.

Haxe вообщем-то известная штука, использование для веба видел в РФ.

Но она слишком уж универсальная, авторы пытаются захватить весь мир видимо )

Как ни забавно, но ровно наоборот. Автор – соучредитель геймдев студии, его позиция: "если мне не хватает каких-то интрументов, я их делаю, чтобы лучше делать игры". У них там все свое: и язык, и движок, и куча инструментов.
Т.ч. haxe сделан буквально для себя, а на продвижение всем вообще плевать. Иначе, с такими-то возможностями, он был бы намного популярнее.

с такими-то возможностями

Недостаточно просто заявить о «возможностях», их еще надо постоянно проверять и поддерживать, что дорого и сложно.

Поэтому и получается что проектов заявляющих поддержку «всего везде и сразу» — вагон, а в реальности все также используют стандартные вещи от крупных вендоров.

Недостаточно просто заявить о «возможностях», их еще надо постоянно проверять и поддерживать, что дорого и сложно.

В первую очередь – сложно. Дорого – это следствие, скорее даже один из способов решать "сложное".
Я пользуюсь haxe с его анонса, почти 20 лет. Разумеется, проблемы возникают. Случаются регрессии. Тем не менее, я склонен утверждать, что "проверяется и поддерживается" на уровне.
Огромное количество тестов, ci/cd, issue tracker – все на виду.
Сейчас над компилятором на фуллтайме работают, вроде, два человека + контрибьюторы. И справляются вполне не плохо.
Есть вещи, которые становится поддерживать сложно/нерентабельно, от них отказываются медленно и вдумчиво. В релизе haxe 5 планируют убрать поддержку c#. Потенциально она может появиться как внешний модуль (проект стороннего разработчкика, но пока не production ready).
Просто со сложностью можно бороться не только через заливание деньгами.
И haxe используется. Причем, мне кажется, что говорят о нем меньше, чем используют. Так что "заявили, наобещали и растворились" – вообще не этот случай.

Сейчас над компилятором на фуллтайме работают, вроде, два человека + контрибьюторы. И справляются вполне не плохо.

У них заявлена поддержа в виде target platform: Android, iOS, Windows, Linux и веб — слегка многовато для двоих разрабов, не находите?

В релизе haxe 5 планируют убрать поддержку c#

Полагаю речь про Mono и Unity ?

У них заявлена поддержа в виде target platform: Android, iOS, Windows, Linux и веб — слегка многовато для двоих разрабов, не находите?

Вы, наверно, не совсем понимаете, как это работает. Это как раз по поводу разных подходов к "управлению сложностью". По поводу двух разработчиков мне очень нравится вот эта история Beating the Averages.
Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке. Для поддержки множества платформ достаточно поддержать в качестве результата компиляции один язык, который компилируется на все эти платформы.
Так, например, многие современные языки не реализуют самостоятельно поддержку платформ, а используют LLVM. Это очень сильно упрощает разработку компиляторов.
Так вот, поддержать кучу платформ – сейчас не сложно, такую возможность и предоставляют современные языки через LLVM.
Во-вторых, уникальность haxe в том, что он позволяет получать (относительно человекочитаемые) исходники на хорошем спектре языков высокого уровня.
Это позволяет реиспользовать код на haxe в куче окружений. Например, игровой сервер может быть написан на java, php, node, ... и подключить игровую логику просто как модуь.
Или, например, запихать описание модели/сериализацию в нужный формат в блендер, через транспиляцию скрипта в питон (я так делал)
Можно писать на haxe игровую логику под разные движки. Для Defold – через транспиляцию в lua, для Godot – через GDScript и т.д.
И в-третьих, он интересен и хорош именно как язык, по выразительнсти и функциональности.
Мощная система макросов, развитая система типов + современные фишки типа паттерн-матчинга и, уникальный по-моему подход к введению zero-overhead абстракций через понятие абстракта.

Полагаю речь про Mono и Unity ?

Совсем не обязательно. Haxe выдает исходники на c#, а вы уже можете использовать хоть на сервере/десктопе в .net, хоть в юнити (и через mono, и через il2cpp) – везде, где можно писать код на c#/

Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке.

Ок, «код на другом языке не работает» — кто виноват? Куда бежать, кому заносить?

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

везде, где можно писать код на c#/

Ээм это... очень смелое заявление, с учетом объемной спецификации C# и существенных отличий Mono (которая используется в Unity) и .NET.

Ок, «код на другом языке не работает» — кто виноват? Куда бежать, кому заносить?

Очевидно, https://github.com/HaxeFoundation/haxe/issues/
Там открываются, обсуждаются, фиксятся и закрываются тикеты и по конкретным таргетам (языкам). Для этого даже в начале тикета в квадратных скобках указывается таргет, если проблема специфична для него.

есть отличие между законченным решением и вот такой универсальным транспилером

Сформулируйте, пожалуйста.

Ээм это... очень смелое заявление, с учетом объемной спецификации C#

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

Сформулируйте, пожалуйста.

Полагаю вы не будете спорить с тем что на одном исходном коде решение не заканчивается?

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

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

Не работает такое, проходили уже.

Слишком быстро стали устаревать даже ключевые фичи, в пределах 5-7 лет обязательно что-то ломают на уровне языка.

Еще я не очень понимаю весь жизненный цикл: ну сгенерировали вы этот код из Haxe, а дальше что?

Допустим, пришлось внести какие-то ручные правки в этот сгенеренный код, повторная генерация из Haxe ведь его убьет, правильно?

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

Все это неоднократно наблюдалось в энтерпрайзе и Java — одних попыток построить систему вокруг кодогенерации штук 10 вспомню.

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

Вы начали с уверенного утверждения:

есть отличие между законченным решением и вот такой универсальным транспилером

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

Не работает такое, проходили уже.

Тоже весьма сильное заявление. Своей обобщенностью. Что не работает? Подход применияется, c# таргет используется, так что опровержение для вашей формулировки в общем виде у меня уже есть.

Еще я не очень понимаю весь жизненный цикл: ну сгенерировали вы этот код из Haxe, а дальше что?

Это хорошо, что вместо утверждений вы начали задавать вопросы. Дальше зависит от ваших задач и целей. Haxe – это инструмент, причем достаточно многогранный, решать им можно совершенно разные задачи.
Если ваша задача – делать инди игру, например, то вы берете движок OpenFL или HaxeFlixel, настраивайте его по инструкции, после чего запускаете вашу игру на haxe одной командой на любой платформе.

openfl test android

и игра запустится на подключенном телефоне,

openfl test html5

– откроется в браузере и т.д.

Другой вариант. Вы делаете сложную стратегию. И клиент с красивой графикой, допустим, на юнити. А сервер, допустим, на ноде. Красивую графику вы, понятно, на c# пишете. А логику: сколько ресурсов списать, каких солдатов улучшить – на haxe. И на билд-сервере есть задачи, которые после пуша запускают тесты, конвертят ресурсы и много чего еще, но среди прочего запускают haxe два раза с разными флагами и получают два артефакта .net dll и js файл.
Один попадает в проект на юнити, другой – в сервер на ноде. И клиент в результате может относительно долго играть в оффлайне, записывая действия пользователя. Когда подключится – отправит серверу эти действия. А сервер тоже выполнит их и будет уверен, что пользователь не жулил с результатами.

Ну или вот есть у меня там игра на openfl. А в игре я мешки использую и формат у меня свой, мне удобный. Я пишу на haxe маленькую утилиту-апи.
Для использования как-то так:

var m = new Mesh();
m.addVert(0,0,0);
export(m, "asset.json");

Транспилирую в питон и кидаю в каталог аддона к блендеру.
Уже на питоне пишу импорт утилиты как библиотеки и использую готовый экспорт в нужный мне формат.

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

Ручные правки не используются. Человекочитаемые исходники помогают, если реально напоролся на случай, когда код работает по-разному и нужно разобраться. После этого либо переписываешь исходники haxe по-другому, либо репортишь баг. Либо и то и то. Ситуация в целом экстраординарная.

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

Напомню, 20 лет уже проекту. Посмотрите только по стиму суммарно движки
Lime/OpenFl, Heaps.
https://steamdb.info/tech/
В веб-проектах распространение еще шире. Ничего общего с in-house наколенной кодогенерацией технология не имеет.

Из чего я предположил, что у вас есть критерии "законченного решения", которым не удовлетворяет haxe и экосистема вокруг него

Никогда не использовал Haxe, но полагаю сравнивать стоит со всем известным Unity, так что пусть будет Unity — законченное решение, поскольку содержит в себе все необходимое для разработки игры с нуля — от редактора 3Д‑сцен до редактора кода и собственно компиляции в готовое приложение.

Что не работает?

Ну я же написал «в пределах 5–7 лет ломают сам язык», те код написанный пять лет назад легко может не собраться в новой среде.

Ручные правки не используются.

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

Даже в Unity их поддержка реализовывалась через вставку нативного кода на Swift/Objective-C, но там предусмотрели подобное и есть возможность подобных вставок.

А как вы предполагаете забарывать такое без ручных правок на Haxe?

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

Haxe – язык программирования. Unity – игровой движок. C# – язык программирования. На нем пишут под юнити. Понятно, к чему я веду?
Если не понятно: язык/тулинг корректно сравнивать с языком, движок – с движком. Примеры движков я вам уже привел. Можете еще Heaps - Haxe Game Engine - Heaps.io Game Engine посмотреть.

Ну я же написал «в пределах 5–7 лет ломают сам язык», те код написанный пять лет назад легко может не собраться в новой среде.

Ну у вас не работает, а у других работает. Если я не ошибаюсь, то многие изменения C# как языка – именно на уровне языка. Новый сахар часто компилировался в старый il код. Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?

А как вы предполагаете забарывать такое без ручных правок на Haxe?

В haxe это предусмотрели более гибко и удобно, чем в юнити. Интероп с окружением таргета – это тоже сильная сторона haxe.
https://haxe.org/manual/lf-externs.html
Нюансы, разумеется, зависят от таргета. В общих чертах – не уникальо, описываем в терминах haxe, как вызывать платформенный код, собираем и/или исполняем так, чтобы вызовы были доступны.
А концепция Abstract про которую я писал в контексте zero-overhead в комбинации с экстернами вообще позволяет творить чудеса.
Можно написать обертку вокруг нативного класса так, что из прикладного haxe кода она будет выглядеть, как haxe класс, в сгенерированном коде будет вызов конструктора нативного класса. При этом в абстракт можно еще дописать методы, которые по желанию заинлайнятся вокруг обращения к нативному или превратятся в статические.

через вставку нативного кода

Но не редактирование же вывода транспилятора! Такой способ тоже доступен на уровне языка.
Что-то вроде

#if java
untyped __java__("native java code here");
#elseif js
untyped __js__("native js code here");
#end

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

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

Ну у вас не работает, а у других работает.

Наверное не самый показательный пример, зато самый свежий.

Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?

Именно ради таких dll и устанавливают по несколько рантаймов .NET разных версий.

На моей памяти: 3.5, 4.x и Core — все имеют проблемы с совместимостью.

Что-то вроде

Ага, значит подобные вставки все же поддерживаются.

 в вас говорило совершенно необоснованное предубеждение перед мощной технологией

Я же сразу написал, что не использовал Haxe, но спасибо за столь подробные ответы — думаю кому‑то из читателей пригодится.

Наверное не самый показательный пример, зато самый свежий.

В общем, моя гипотеза в том, C# код написанный максимально стандартным образом будет поддерживаться.
Например, список совместимости
https://www.nuget.org/packages/Newtonsoft.Json
достаточно приличный и, как я понял, это всле для одной ревизии исходников. Так что вряд ли стоит ожидать, что с# таргет текущей версии компилятора перестанет поддерживаться c# экосистемой в обозримом будущем.

Ага, значит подобные вставки все же поддерживаются.

Технология делается 20 лет исключительно с целью применения. Ее вообще не пытаются кому-то втюхать. Разумеется, большинство практических задач решено.

Да, рад, что пришли к консенсусу и тоже надеюсь, что кому-нибудь пригодится.

На скриншоте, подписанном как «Call of Duty» на самом деле меню настроек из Battlefield 3!

Не мог пройти мимо…

"Пишешь Манчестер, а читаешь Ливерпуль"

Кажется хотя бы в начале статьи, нужно было упомянуть Avalonia UI. Прекрасное решение для крсс-платформенных приложений. https://github.com/AvaloniaUI/Avalonia

Avalonia очень известен и широко используется, про него неоднократно писали даже на Хабре.

Sign up to leave a comment.

Articles