Comments 30
Добавлю две вещи:
При помощи invokeMethod можно вызывать и слоты и сигналы и методы Q_INVOKABLE, а параметр Qt::QueuedConnection позволяет это делать отложенно (т.е. из любого места в коде, сам вызов произойдёт когда это можно и в том потоке в котором можно), поэтому никаких проблем в коммуникации С++ -> QML на самом деле нет.
Купившие лицензию могут статически собирать Qt и пытаться выиграть размер итоговой сборки.
При помощи invokeMethod можно вызывать и слоты и сигналы и методы Q_INVOKABLE, а параметр Qt::QueuedConnection позволяет это делать отложенно (т.е. из любого места в коде, сам вызов произойдёт когда это можно и в том потоке в котором можно), поэтому никаких проблем в коммуникации С++ -> QML на самом деле нет.
Купившие лицензию могут статически собирать Qt и пытаться выиграть размер итоговой сборки.
Жить с Qt без MOC'a может быть и можно, но зачем? Неужели QtCreator — единственный IDE, поддерживающий компиляцию в несколько этапов?
Предлагаю обратить внимание на статическую линковку. Всё равно лицензия нужна для любого более-менее серьезного проекта
Предлагаю обратить внимание на статическую линковку. Всё равно лицензия нужна для любого более-менее серьезного проекта
Не единственная, очевидно. Полагаю, MOC можно прикрутить почти к чему угодно. К Студии так есть дополнение, которое это делает (правда, официальный add-in перестал работать в 2015ой, и до сих пор не починен, что печально).
Вот с XCode придётся шаг добавлять руками. И автоматического подбора компонент для deployment тоже не будет.
Вот с XCode придётся шаг добавлять руками. И автоматического подбора компонент для deployment тоже не будет.
Непонятно, почему не использовать qmake для генерации проекта для VS, XCode, Ninja и черта лысого, чтобы у вас был MOC и остальные плюшки автоматически.
Для VS проект из файла .PRO генерируется вот так:
Для VS проект из файла .PRO генерируется вот так:
qmake -tp vc path/to/project/file.proДля XCode — вот так:
qmake -spec macx-xcode path/to/project/file.pro
С одной стороны, я о таком не знал, поэтому видимо да, можно и нужно использовать.
С другой стороны, с высокой вероятностью, у вас проект вашей игры под любимую(ые) IDE настроен руками, и просто так взять и перегенерировать его внешним генератором нельзя (к примеру, у нас активно используются prop-файлы). С третьей стороны, кто мешает вынести UI в отдельный проект, и генерировать его… Одно из этих решений можно выбрать.
С другой стороны, с высокой вероятностью, у вас проект вашей игры под любимую(ые) IDE настроен руками, и просто так взять и перегенерировать его внешним генератором нельзя (к примеру, у нас активно используются prop-файлы). С третьей стороны, кто мешает вынести UI в отдельный проект, и генерировать его… Одно из этих решений можно выбрать.
намного проще настроить алгоритм сборки/деплоя, чем каждый раз тянуть костыль из-за отсутствия MOC. Например, qmake определяет переменную $$[QT_INSTALL_LIBS] — директория с библиотеками Qt. Добавляем все нужные библиотеки в INSTALLS, определяем и добавляем шаг сборки make install. Запускаешь билд и всё лежит на своих местах. Архивируй и распространяй.
В Visual Studio 2013 и 2015 прекрасно работает этот аддон visualstudiogallery.msdn.microsoft.com/c89ff880-8509-47a4-a262-e4fa07168408.
Можно, еще создать Makefile проект и там все прописать. Я так для малины собираю, когда виртуалку лениво включать))
Можно, еще создать Makefile проект и там все прописать. Я так для малины собираю, когда виртуалку лениво включать))
Жить без MOC можно. Не так давно ребята из Woboq header only библиотеку, которая через макросы генерирует бинарно совместимую мета объектную систему Qt.
https://woboq.com/blog/verdigris-qt-without-moc.html
https://github.com/woboq/verdigris
https://woboq.com/blog/verdigris-qt-without-moc.html
https://github.com/woboq/verdigris
Для небольших игр можно использовать CEGUI, у которого есть отрисовщики и для DirectX, и для OpenGL, и для OGRE — основное что использовал. Даже редактор свой есть (правда со своими особенностями). В сумме библиотек для релизной версии у меня получилось около 11 мб.
А для больших игр не используются сторонние наработки по причине либо их закрытости и невозможности быстро допилить нужный функционал/исправить баг, либо из-за недостаточности функционала/производительности, либо кто-то в команде сказал — «Да сейчас сделаем, тут не сложно».
А для больших игр не используются сторонние наработки по причине либо их закрытости и невозможности быстро допилить нужный функционал/исправить баг, либо из-за недостаточности функционала/производительности, либо кто-то в команде сказал — «Да сейчас сделаем, тут не сложно».
У нас в 2007ом году с CEGUI был очень грустный опыт в плане производительности и глючности. С тех пор, конечно, уже почти 10 лет прошло, но осадочек остался :) Вдобавок, я смотрю, они только в 2015ом году добавили поддержку OpenGL ES, то есть, что там творится с ним на мобилках — это ещё надо отдельно рассматривать.
Для очень больших игр стороние наработки вовсю используются — но как правило это именно Scaleform или Coherent. Там закрытость — не проблема, поскольку платный саппорт — создаёшь запрос, и через некоторое время получаешь нужную функциональность в твоей персональной ветке. Время, правда, может быть от пары дней до недель… Я лично с этим двумя, правда, почти не работал (кроме неудачного опыта со Scaleform — и, кстати, сорцы от него у нас были), но вообще с коммерческими библиотеками мы жили на первой моей работе, и с их саппортом вот так общались.
Для очень больших игр стороние наработки вовсю используются — но как правило это именно Scaleform или Coherent. Там закрытость — не проблема, поскольку платный саппорт — создаёшь запрос, и через некоторое время получаешь нужную функциональность в твоей персональной ветке. Время, правда, может быть от пары дней до недель… Я лично с этим двумя, правда, почти не работал (кроме неудачного опыта со Scaleform — и, кстати, сорцы от него у нас были), но вообще с коммерческими библиотеками мы жили на первой моей работе, и с их саппортом вот так общались.
Qt использует двойную лицензию — LGPL3 и коммерческую. Это означает, что если вас интересуют, в том числе, платформы, где динамическая линковка невозможна (iOS), то придётся раскошелится
Зануда-mode: дело не в динамической/статической линковке, под LGPL вполне можно распространять библиотеку в статически слинкованном виде с вашей проприетарной программой (при наличии исходников самой библиотеки). Этого никто не запрещает.
Что LGPL требует — так это чтобы у пользователя была возможность внести изменения в исходные коды библиотеки, собрать её, и использовать вашу программу с изменённой версией библиотеки. Чтобы это выполнить, достаточно приложить/выложить объектные файлы всего и предоставить инструкции по сборке этого в статический бинарь. Ну и не вшивать дополнительных проверок, например, чексуммы библиотеки.
С iOS другая проблема — она, насколько я знаю, не удовлетворяет именно условию того, чтобы пользователь мог пересобрать программу с изменённой библиотекой и воспользоваться результатом. Так что покупать лицензию вам всё равно придётся, если вы распространяете программы через AppStore.
Я не стал вдаваться в эти подробности, поскольку для игр в целом не характерна разработка с открытым исходным кодом или с возможность выкладывания объектных файлов для последующей пересборки. Хотя, было бы интересно поразмышлять на тему того, какие последствия для успеха проекта и компании может иметь решение соответствовать LGPL3 в одном из вариантов со статической линковкой. Но это, скорее, тема для личного блога, а не для Хабра, поскольку с моей стороны это будут совсем уж ничем не обоснованные размышления на тему.
… под LGPL вполне можно распространять библиотеку в статически слинкованном виде ...
Obligations of the LGPL
…
In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
В случае статического связывания библиотеки (линковки), приложение может перестать быть «произведением, использующим библиотеку», и т.о. стать объектом LGPL. Рекомендуется либо использовать динамическое связывание, либо предоставлять пользователям исходный код приложения по лицензии LGPL.
Не определённо это «may no longer be», в каких случаях? Есть ли у вас что сказать по этому поводу?
Фантазии продаванов Qt Company о LGPL не имеют к LGPL никакого отношения. У них и давно ересь была на сайте в сравнительной табличке, и последний раз, когда я видел, в визарде выбора лицензии (основная задача которого — убедить тебя купить лицензию).
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
P.S. Вот прямо сейчас проверил — этот визард на qt.io по вкладке Download открывается, по некоторым путям визарда спрашивает про тип линковки, спрашивает, готовы ли вы выложить исходники своего приложения, и на основе этого делает какие-то выводы.
Не знаю специфики геймдева, но вот передача сигналов в обе стороны на самом деле сильно проще, вы очень усложняете. Берем C++ объект, прокидываем его в глобальный контекст (будет доступен из любого места в QML) и радуемся жизни:
В этом объекте можно сделать сигналы, которые будут дергаться из QML, на них можно подписываться как угодно, в том числе через лямбды. Таким же образом, можно дергать в обратном направлении: сигналы дергаем из С++, а подписываемся на них из QML.
SignalsHub signal;
engine.rootContext()->setContextProperty(QLatin1String("signal"), &signal);
В этом объекте можно сделать сигналы, которые будут дергаться из QML, на них можно подписываться как угодно, в том числе через лямбды. Таким же образом, можно дергать в обратном направлении: сигналы дергаем из С++, а подписываемся на них из QML.
По поводу рендеринга контента: существует ещё два способа — Mixing Scene Graph and OpenGL. Один, тот что вы описали (рисование на контексте в момент вызова событий), второй — рисовать на текстуре/буфере, встроенной в граф сцены Qt Quick.
Плюс есть еще QQuickRenderControl, который предназначен как раз для интеграции с 3rd party OpenGL renderers. И который, наоборот, отдает цикл отрисовки приложению, UI рендерится куда укажут.
Плюс есть еще QQuickRenderControl, который предназначен как раз для интеграции с 3rd party OpenGL renderers. И который, наоборот, отдает цикл отрисовки приложению, UI рендерится куда укажут.
О, про QQuickRenderControl даже есть статья на Хабре! Полезно.
Тем временем, коллега подсказывает, что «рисовать на текстуре/буфере, встроенной в граф сцены Qt Quick» может быть не лучшей идеей на мобильных девайсах по причина того, что филлрейт там — узкое место.
Тем временем, коллега подсказывает, что «рисовать на текстуре/буфере, встроенной в граф сцены Qt Quick» может быть не лучшей идеей на мобильных девайсах по причина того, что филлрейт там — узкое место.
придётся раскошелиться на 79$ в месяц за каждого работника «использующего» Qt
Это в случае лицензии «subscription», причём оплаченной сразу за год, и также если вы «qualify for Start-Up», иначе цена выше. К тому же, после истечения подписки вы теряете право на разработку, потому для долгосрочных проектов лучше приобрести «perpetual» лицензию
«использовать», это, как я понимаю, хотя бы просто собирать проект с библиотеками
Для процесса сборки лицензия не требуется. Например, вы можете иметь несколько десятков билд-машин и лицензия для каждой из них не нужна
важным техническим аргументом против Qt является её вес
Относительно скоро появится новый «компонент» — Qt Light, который существенно снизит вес таскаемых библиотек. На самом деле, «компонент» — неудачный термин, это будет что-то вроде системы конфигурации Qt, позволяющей исключить неиспользуемые модули
просто не надо рассчитывать, что можно будет отдать Qt Designer художнику, и он вам всё настроит мышкой
Ну теоретически так и предполагается, что можно разделить работу на дизайнера и погроммиста. Первый «нарисует» UI мышью, а второй, получив от первого сгенерированный QML, напишет логику. В теории. Не знаю, применяется ли это реально в живых проектах, может у кого-то есть опыт?
обещали ещё заметно улучшить с новыми QtQuick Controls 2.0
В свежайшем релизе 5.7 они уже есть (до этого также были в 5.6, как Technical Preview). Вот видео, где человек рассказывает, за счёт чего произошли улучшения в производительности, и недавний пост
для того, чтобы распространять вашу программу, всё это добро придётся таскать с собой
Но ведь если вы приобрели лицензию, то вы можете слинковать всё статически. Кстати, можно также использовать Qt Quick Compiler, чтобы и QML файлы не лежали открыто и не компилились дополнительно
Это в случае лицензии «subscription», причём оплаченной сразу за год, и также если вы «qualify for Start-Up», иначе цена выше. К тому же, после истечения подписки вы теряете право на разработку, потому для долгосрочных проектов лучше приобрести «perpetual» лицензию
«использовать», это, как я понимаю, хотя бы просто собирать проект с библиотеками
Для процесса сборки лицензия не требуется. Например, вы можете иметь несколько десятков билд-машин и лицензия для каждой из них не нужна
важным техническим аргументом против Qt является её вес
Относительно скоро появится новый «компонент» — Qt Light, который существенно снизит вес таскаемых библиотек. На самом деле, «компонент» — неудачный термин, это будет что-то вроде системы конфигурации Qt, позволяющей исключить неиспользуемые модули
просто не надо рассчитывать, что можно будет отдать Qt Designer художнику, и он вам всё настроит мышкой
Ну теоретически так и предполагается, что можно разделить работу на дизайнера и погроммиста. Первый «нарисует» UI мышью, а второй, получив от первого сгенерированный QML, напишет логику. В теории. Не знаю, применяется ли это реально в живых проектах, может у кого-то есть опыт?
обещали ещё заметно улучшить с новыми QtQuick Controls 2.0
В свежайшем релизе 5.7 они уже есть (до этого также были в 5.6, как Technical Preview). Вот видео, где человек рассказывает, за счёт чего произошли улучшения в производительности, и недавний пост
для того, чтобы распространять вашу программу, всё это добро придётся таскать с собой
Но ведь если вы приобрели лицензию, то вы можете слинковать всё статически. Кстати, можно также использовать Qt Quick Compiler, чтобы и QML файлы не лежали открыто и не компилились дополнительно
если вы приобрели лицензию, то вы можете слинковать всё статически.
Об этом уже писали выше. Не известна точная экономия — надо пробовать. Ну, и без лицензии хотелось бы обойтись, в идеале :)
Кстати, можно также использовать Qt Quick Compiler, чтобы и QML файлы не лежали открыто и не компилились дополнительно
Полезно, хотя у нас вот свой формат пакета ресурсов, уже и так шифрованный.
(Если можно, поправьте форматирование комментария, чтобы была цитата цитатой)
Как минимум в размере бинарников экономия, и ощутимая, выше писали 8 метров против 40 — это вполне реальный пример. И лицензия это не только статическая линковка, но и также дополнительные компоненты, которые доступны только в коммерческой лицензии, а также тех.поддержка с доступом к RnD команде, которая разрабатывает собственно Qt.
Не могу, к сожалению, редактировать комментарий. А вообще, он у меня был с разметкой и ссылками, на превьюшке всё было красиво, но после отправки почему-то погибло.
Не могу, к сожалению, редактировать комментарий. А вообще, он у меня был с разметкой и ссылками, на превьюшке всё было красиво, но после отправки почему-то погибло.
Компоненты начиная с 5.7 стали одинаковые в платной и бесплатной версии после тотального перехода на LGPL3, как я понял (отказа от лицензирования части компонентов по LGPL2.1).
Это не совсем так. Часть компонентов (графики, виртуальная клавиатура, Qt Quick 2D renderer и другие) теперь стала доступна под GPL, но не под LGPL. А некоторые (Boot to Qt и тот же Qt Quick Compiler, например) по-прежнему есть только в коммерческой лицензии.
По поводу ресурсов. Мне однажды доводилось реализовывать генерацию и загрузку небольшого файла ресурсов в run-time — только вот подробности, к сожалению, припоминаются смутно, но вдруг кому окажется полезным…
Sign up to leave a comment.
QtQuick/QML в качестве игрового UI