Существует ли "цельный" openGL?

Я хочу создать свою игру на OpenGL, но только мне уже надоело скачивать всякие glfw, glew, glu и т. п. а потом ещё и ошибок 250 штук получить. Можно ли где-то скачать цельный openGL, в котором нет никаких таких заморочек и нет конфликтов?

0

Сообщение от 8Observer8 Вот сегодня время потратил на ответы на форуме, а в планах было сделать работу дальше.

Ну отдыхать тоже надо

Сообщение от 8Observer8 В планах объединить анимации модели и физику перемещения на Ammo.js в WebGL.

Тут дело упирается в пресловутый "character controller". В bullet он мелькал но потом исзчез. Эрвина долго уговаривали, пытались брать "на слабо", мол, у других есть. Но бесполезно, сказал "делайте сами". И, видимо, он прав. Для физика char задается капсулой что "плавает" над поверхностью (constraint). В движке к этой капсуле можно прилагать силы, она будет двигаться. Ну и лучами отслеживать контакт с полом. И на этом с физикой все. Она может дать только траекторию движения (не густо). И она необязательна, траектории можно задавать и без нее. А вот как присобачить CA под эту траекторию - та еще задача. Более сложный контакт с полом (подъем по лестнице, лазание по горам и.т.п) - тоже самому.

0

Сообщение от Igor3D Тут дело упирается в пресловутый "character controller".

Этот вопрос я решил. Управление у меня уже готово на btRigidBody: демка в браузере (переключитесь на английскую раскладку, чтобы управлять на WASD). Подпишитесь на мою тему: Управление героем стрелками в 3D, вид от 3-го лица, на WebGL. Я буду выкладывать в ней промежуточные результаты. Конечно, я ещё буду дорабатывать управление. Вместо капсулы лучше брать сферу, потому что со сферой значительно увеличивается производительность, а когда много статических коллайдеров, то капсулы и цилиндры сильно бьют по производительности. Я недавно делал на физическом движке перемещение от первого лица (WASD + стрелки для поворотов влево-вправо и в вверх-вниз): демка в браузере Самая лучшая статья для начинающих для управления персонажем от третьего лица и пример кода на Ammo.js (тоже самое что и Bullet, поэтому можно перевести на C++), и тех что я находил Moving Objects In JavaScript 3D Physics using Ammo.js and Three.js. Для первого лица я просто камеру разместил на капсулой. В этой демке статические коллайдеры на земле, домике и на ёлке (на ёлке капсула).

Миниатюры

 

0

Сообщение от 8Observer8 А посчитал общую папку, где лежат

Зачем? Какое отношение у веса твоих инструментов и конечного продукта?
Да, в библиотеках (во всех) так или иначе куча всякого в комплекте может быть. Как нужное и необходимое тебе, так и то, что возможно лично тебе никогда не пригодится. Она ведь делается для многих людей с разными потребностями. Ты можешь все это выкинуть нафиг и оставить только необходимые тебе lib, dll и headers.
Это в любом случаи никак не влияет на то, сколько будет весить твое конечное приложение, если из всех компонентов на 2,2ГБ, ты используешь (условно) в своем проекте только одну dll-ку мегабайтов на 5 из всех.

У меня программный комплекс (движок) состоит из в общей сложности 30 различных библиотек и зависимостей, исходники которого весят около 400mb, если сделать сборку всего этого, то с кучей сгенерированных технических файлов (debug+release) папка с ним разрастается в 10-ки GB, когда конечные dll-ки (release) весят всего 30mb.
Всем кто будет пользоваться приложением на нем 100GB придержать свободными, на всякий случай, что ли теперь?
Или все же это не имеет никакого значения, а имеет значение только вес конечного приложения?

Сообщение от 8Observer8 Когда вы видишь свою игрушку на Android и можешь показать своим друзьям и родственникам - это дорого стоит.

Ну так это никак не зависит от того, сколько места занимает весь комплект необходимых (или не очень) инструментов, библиотек и т. д.
И на работоспособности никак не отразится, если они не станут устанавливать какую-нибудь Visual Studio, Windows SDK и т. д. только потому, что они у тебя были установлены для того чтобы собрать эту игрушку.

Сообщение от 8Observer8 Собрал приложение с подключёнными модулями: OpenGL + QtCore + QtGUI, добавил в архив, приложил к сообщению на форум и вот пожалуйста пробуйте, это второй подсчёт

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

Я не понимаю, зачем вес того или иного SDK, притягивать к тому, какой вес приложения будет у конечного продукта.
Если запихаешь все dll-ки QT, когда используются только несколько из них, то это именно твой косяк, а не QT.
Разве нет?

0

Сообщение от Mc X Зачем? Какое отношение у веса твоих инструментов и конечного продукта?

Это два разных критерия. Я их сравниваю отдельно. У меня ноутбук. Я должен учитывать, что места у меня мало:

Я сравниваю инструменты между собой по критерию - сколько инструмент займёт места на моём жёстком. У меня нет пока возможности купить жёсткий побольше. Например, Unity, скорее всего, займёт 5 ГБайт. Нужна IDE, но можно сэкономить на VS и использовать VSCode (309 МБайт). Godot занимает на жёстком всего 74 МБайта и имеет встроенный редактор кода. Правда, плюс ещё пакет для создания сборок под все основные ОС и этот пакет занимает 685 МБайт, но это всего около 800 МБайт.
Если заниматься браузерными играми на WebGL, то нужны:

• браузер Chrome, который и так есть
• среда VSCode - 309 МБайт
• редактор текстур GIMP - 1 ГБайт
• редактор анимаций и моделей Blender 2.67b - 197 МБайт
• Node.js и npm-пакеты. Необходимые npm-пакеты можно поставить в одну общую папку в корне. Все проекты на этом уровне и уровнем ниже будут находить папку "node_modules"

Это просто, как пример сравнения по критерию "вес инструментов для разработки инди-игр".

0

Mc X, скорее всего, у вас много свободного места на жёстком, поэтому критерий "вес инструментов" у вас в пренебрежимо малом приоритете. Критериев выборов инструментов много. Для одного человека один набор критериев в высоком приоритете, а у другого другая комбинация критериев в приоритете. Например, есть такой критерий, как "наличие вакансий". Например, человек мечтает учувствовать в разработке игр в коллективе, в офисе. Допустим, он живёт в немаленьком городе населением 1 млн. человек. Он не хочет переезжать в Москву. Он выбирает себе движок для разработки. Вот как примерно он воспользуется критерием "наличие вакансий". Он станет искать по вакансиям, какие в его городе есть фирмы по разработки игр. Например, в Саратове я знаю, как минимум 4 фирмы на движке Unity. Человек посмотрит, что у него в городе 5 фирм на Unity, одна фирма на Unreal и ни одной на Godot. Это наиболее вероятный расклад. Человек сразу отбрасывает Godot. Чтобы выбрать Unity или Unreal человек может воспользоваться разными критериями. Один хорошо знает C# и ему по каким-то причинам не нравится C++. Другой наоборот - обожает C++ и скажет себе, что несмотря, что всего одна фирма, но я поставлю себе цель попасть в неё. Третий человек может хочет работать удалённо и ему понравился Godot, он любит Python, а GDScript очень похож на Python, либо это человек хочет переехать в другой город или страну, где есть фирмы на Godot. У всех разные приоритеты критериев.

0

Сообщение от 8Observer8 Этот вопрос я решил.

И как-то возникают сомнения - а стоит ли чего-то рассказывать? Человеку и так все ясно, он уже все решил

Ну char сферой аппроксимировать "не очень". И char "ходит", т.е. он может перешагивать через неровности, подниматься по лестнице и.т.п. А сфера контактирует с полом, начинает крутиться, прыгать на каждой кочке, или наоборот, упрется в ступеньку. Поэтому, насколько мне известно, все делают капсулу подвешенную на constraint.

Вообще collision (грубо говоря чтобы "не проходил сквозь стены") движок решает хорошо. И даже dynamicBody необязательно, можно отслеживать коллизии лучами (они в движке есть). Но сам по себе шарик/лошарик не очень интересен, вот char - другое дело. Но char должен по крайней мере переставлять ноги. А вот с этим движок никак не поможет.

Сообщение от 8Observer8 сильно бьют по производительности

Здесь уместно вспомнить избитую "преждевременную оптимизацию". Сначала ф-ционал, потом производительность

0

Сообщение от Igor3D А сфера контактирует с полом, начинает крутиться

Либо вы не запускали мою демку, либо вы запускали, но не поняли, что означают зелёные линии:



Я забыл написать, что debugDraw можно отключить на клавишу B. Нужна чтобы раскладка клавиатуры была на английском. Клавиша B включает и отключает debugDraw:



Исходники этого примера на GitHub и в этой теме. Так вот. В составе Bullet Physics (и, конечно, в порте Ammo.js) есть вспомогательный интерфейс btIDebugDraw. В этом интерфейсе есть метод drawLine(). Этот метод будет автоматически вызываться. Он получает параметры:

То есть получает он: вектор начала линии, вектор конца линии и цвет. Все эти линии в моей демке я и рисую. Из сферы торчат три отрезка - это локальные оси физического объекта. Если вы двигаете объект на WASD, то вы можете видеть, что оси не крутятся. Да, то что объект не крутится можно видеть по надписи на объекте. Я запретил вращение сферы вокруг осей X и Z, но разрешил вращение вокруг оси Y командой:

Сообщение от Igor3D он может перешагивать через неровности

Если вы играли в Resident Evil на PlayStation, или смотрели прохождения, то могли заметить, что там нет неровностей. Даже на лежащем зомби можно отключить коллайдер после его смерти. Пусть Jill проходит сквозь него, в оригинале, по-моему, так и было. Если и не было, то пусть у меня будет. Ничего страшного. Некоторые мелочи можно пока пропустить. У таких мелочей низкий приоритет, а времени они могут съесть колоссальное.

Сообщение от Igor3D подниматься по лестнице и.т.п.

Делать BoxCollider для каждой ступеньки - это очень дорого для браузерной игры. Надо делать один BoxCollider под углом. У персонажей есть анимация ходьбы по ступеням. Я точно не хочу тратить время, чтобы герой прямо ставил ровно ноги на каждую ступеньку. В игре два виде лестниц - показ от первого лица и от третьего. В нескольких секундах следующего видео показано хождение по этим видам лестниц (time_code: t=10m23s):



В видео выше прохождение на Chris Redfield. Второй персонаж, который можно выбрать для игры - это Jill Valentine. Есть момент, когда она двигает стремянку, а потом поднимается по ней. Там она ставит ноги на каждую ступеньку. Наверное, сложная задача добиться такого же поведения, как на видео ниже (time_code: t=11m14s). Она ещё двигает стремянку перед тем, как на неё подняться. Я пока отложу эту задачу. По приоритету есть более важные задачи.

Сообщение от Igor3D прыгать на каждой кочке

Я убрал ""restitution". Этот параметр отвечает за отскакивание.

Сообщение от Igor3D Поэтому, насколько мне известно, все делают капсулу

Можно сделать btRigidBody с коллайдером "Капсула", но она будет требовать больше ресурсов. Я тестировал с большим количеством статических BoxCollider, где управляешь капсулой, то при определённом числе, не помню, может 20 штук статических коллайдеров, то начинало подтормаживать, а сфера даёт ещё большой запас по количеству статических BoxCollider. Я пока будут использовать сферу, а если упрусь в проблемы, то заменю на капсулу.

Сообщение от Igor3D Но char должен по крайней мере переставлять ноги.

В этой игре просто анимация болтания ног для ходьбы.

Сообщение от Igor3D Здесь уместно вспомнить избитую "преждевременную оптимизацию". Сначала ф-ционал, потом производительность

Исправить за секунду можно. Просто исправлю "btSphereShape" на "btCapsuleShape". Я пока не понимаю зачем мне нужна будет капсула. Может когда зомби будут кусать. Но там будет у зомби "btSphereShape" и у героя "btSphereShape", а при касании будет урон. Я не продумывал ещё, как сделать "кусание зомби". Я пока до этого не дошёл. Вот может быть проблема возникнет при стрельбе, потому что сфера зомби находится у земли. Но я могу направлять луч при выстреле от сферы героя параллельно земле, на уровне сферы зомби. Я не считаю, что на это нужно отвлекаться на данном этапе. Есть более важные вещи, как многим мелочам можно обратиться позже.

0

Сообщение от 8Observer8 я могу направлять луч при выстреле от сферы героя параллельно земле, на уровне сферы зомби

Я сейчас подумал, а были ли в игр моменты, когда зомби и герой находились на разных высотах? Например, зомби спускается по лестнице, а герой стоит на полу. По-моему, было, но я могу сделать, чтобы пока такого не было, а вернуться к этому позже. Ещё один момент, который точно был в игре, это стрельба в голову. Здесь можно сделать составной объект из двух сфер. В физических движках можно делать составные объекты, состоящие из комбинации простых объектов. Пусть будет одна сфера у ног для ходьбы и непрохождения сквозь препятствия и стрельбы по прямой, а вторая сфера для поднятого оружия для стрельбы в голову. Всё что надо реализовать я записывают в Trello. Кстати, Trello - очень удобный инструмент, если кто не пробовал - попробуйте: https://trello.com/

0

8Observer8, Хм... критерии это хорошо, но речь не об этом.
Меня возмущают...
1. Когда проводят параллели между весом SDK и конечным приложением.
2. Когда модульная архитектура представляется, как необходимость таскать за приложением всех модулей (dll-ок), независимо от того, используются они или нет в конечном приложении.
3. Когда собственную невозможность отделить необходимую часть SDK, выставляют, как проблему этого SDK.
В остальном, безусловно, выбор того или иного инструмента зависит от задач, но это не делает сам инструмент хуже.

Добавлено через 5 минут

Сообщение от 8Observer8 Я сейчас подумал, а были ли в игр моменты, когда зомби и герой находились на разных высотах?

Если ты про резидента, то там автонаводка прицела, поэтому плоскость никогда не имела значения.

0

	Комментарий модератора
	Прекращаем оффтоп. Демонстрация своих проектов, а так же обсуждение размеров к теме автора не имеет никакого отношения

0

Сообщение от alecss131 а так же обсуждение размеров к теме автора не имеет никакого отношения

Вообще-то вы спровоцировали оффтоп, написав, что Qt весит огромное количество МБайт и поэтому лучше взять Unreal Engine. Написав, что Qt не подходит для разработки игр вы тем самым, на самом деле, написали что OpenGL не подходит для разработки игр, а это вообще противоречит теме, потому что автор хочет делать игру именно на OpenGL. Поэтому ваши намёки в мой адрес не обоснованы. Я только лишь развенчал ваши заблуждения или ваши намеренные попытки ввести других в заблуждение. Если вы намеренно провоцируете и вводите в заблуждение, то вы нарушили правило 5.22:

Запрещено намеренно вводить других пользователей форума в заблуждение.

Добавлено через 10 минут

Сообщение от alecss131 Демонстрация своих проектов

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

0

Именно брать анреал я не говорил, я просто посоветовал взять любой игровой движок, именно игровой, а не неподходящий для игр Qt (он позиционируется как ui фреймворк), то что где-то есть раздел по созданию игр на нем ни о чем ни говорит, игры можно создавать на чем угодно, тут вопрос здравого смысла и скорости разработки/написания велосипедов.

0

Сообщение от alecss131 взять любой игровой движок, именно игровой

Ну, скажем прямо... нет такой сертификации "игровой движок".
Игровым движком может быть любой программный комплекс, как полностью собственного API, так и связка различных фреймворков\библиотек и их зависимостей
Это может быть узкоспециализированным движком, скажем исключительно на SDL (если память не изменяет - Visionaire Adventure Game Engine) или более внежанровым (UE, Unity).

0

Сообщение от Mc X 3. Когда собственную невозможность отделить необходимую часть SDK, выставляют, как проблему этого SDK.

Я наоборот говорил о преимуществе Qt, что можно удалить VS, а вместо него использовать Qt Creator и что в этом случае мы получаем ряд огромных преимуществ. Даже весь фреймворк Qt вместе с Qt Creator и в месте с MinGW занимает меньше, чем одна Visual Studio. Тут же прям яростно много раз писали, что Qt весит "100500 мб", при этом не писали сколько весит Unreal Engine. Я на это отвечал, что Qt меньше весит в сравнении с VS. При этом для игр Qt OpenGL нисколько не уступает SFML, а наоборот его превосходит его. Например, потратив время на SFML вы не найдёте по нему работу. Зато если вы будете работать в экосистеме Qt ты вы неизбежно многое о нём узнаете. Даже если вы не будете инди-разработчиком мобильных игр на Qt OpenGL, но зато вы легко найдёте вакансии по Qt. Здесь вообще очень серьёзные вещи скрыты или находятся на поверхности. Это вопросы судеб людей. Человек может как хобби увлекаться разработкой игр на Qt OpenGL, а основную работу делать тоже на Qt OpenGL, но с неигровыми приложениями с интерактивной графикой в 3D. Может даже удалённо/фрилансем на зарубежных для науки, промышленности, медицины, торговли, транспорта, нефте и газовой добычи, графики, диаграммы, блок-схемы, UML-диаграммы и много другое. Игры вполне можно делать для Android и iOS. Всё что может OpenGL ES может и Qt, но Qt может сделать намного больше прямо из коробки, чем, напрмер, SFML. Например, в Qt есть парсинг JSON/XML, есть встроенная база данных SQLite, есть поддержка WebSockets (а не просто TCP).

0

Зачем что-то вручную скачивать, если этим должен заниматься менеджер репозитория? И решение конфликтов тоже он должен выполнять. Если мне захочется поставить glfw, то и все зависимости будут тоже установлены.

Вы, батенька, явно какой-то неправильный подход к программированию выбрали.

0

8Observer8, Значит мы друг друга изначально не поняли Потому что меня напрягли именно теже инсинуации, что и тебя)))

Что касается Qt в играх...
Конкретные примеры с ходу не скажу, но периодически встречаю его следы в играх из обширной библиотеки Steam.
Хотя сам, возможно и не стал бы его использовать в чистом виде для игры. С другой стороны, если в составе игры предполагается наличие редактора (который использует QT), то при определенных условиях, вполне можно использовать и API QT для самой игры.

0

Сообщение от alecss131 Именно брать анреал я не говорил, я просто посоветовал взять любой игровой движок, именно игровой

Давайте в всех темах, где человек хочет написать игру писать ему, чтобы он взял игровой движок. Человек пришёл на форум с желанием изучать OpenGL для написания своих игр без движков. Посмотрите темы автор и вы увидите, что он уже знает о существовании игровых движков. Он уже изучал Unity. Но от всё равно хочет писать игры на OpenGL без игровых движков. Я его понимаю. Я сам пробовал кучу игровых движков на C++ и кучу на JavaScript. Я понял, что мне интереснее всего писать игры с нуля на голом API на WebGL и Qt OpenGL, иметь полный контроль и понимать, что происходит, изучать через игры нужные мне части графического API. Вы теперь в каждой теме, где человек решил писать игры на OpenGL, Vulkan, DirectX будете заходить отговаривать его не писать игры на OpenGL и т.д.? Самая большая ошибка начинающих, что они начинают копать API вглубь и забывают свою основную цель - написание игры. Они просто слышали, что нужно писать сначала кучу маленьких игр и улучшать их, но они, в большинстве случаев, этого не делают, а напишут 1-3 мелких прототипа, а дальше бросают писать игры и начинают углубляться в API, хотя им минимум из API нужно для тренировки в программировании игр. С этим подходом никакой даже самый крутой движок не научит писать игры, если их не писать.

Сообщение от alecss131 а не неподходящий для игр Qt (он позиционируется как ui фреймворк)

Так может писать человек, который не знает, что в Qt можно рисовать с помощью OpenGL, а думает, что там только можно выводить кнопочки, чекбоксы и т.д. По вашей логике Qt не подходит для работы с сетью, базами данных и многим другим, потому что "он позиционируется как ui фреймворк". Вы так и не написали, что конкретно мне может помещать в Qt, чтобы делать мобильные игры на Qt OpenGL. В Qt всё тоже самое есть для OpenGL, что есть в GLFW. Есть куча игр для мобильных написанных на чистом OpenGL ES. Я не могу понять, что в Qt есть такого, что не позволит мне писать игры на OpenGL ES для мобильных. Почему вы не пишите, что бессмысленно тратить время инди-разработчику на закапывание в OpenGL 4.6 и Vulkan, а можно просто взять OpenGL ES и этой функциональности с головой хватит, чтобы писать инди-игры для смартфонов, планшетов, Windows, Linux и macSO.

Сообщение от alecss131 тут вопрос здравого смысла.

Тут нет никакого здравого смысла. Человек сидел на Unity и решил изучать OpenGL, чтобы писать игры. Он написал, что лучше выбрать для использования OpenGL без сборки/подключения кучи библиотек. Вывод очевиден - Qt. Вы ему зачем-то SFML предлагаете. SFML намного хуже, чем Qt OpenGL. Мало применений у SFML, нет вакансий, нет официальной поддержки Android и iOS. Тем более человек хочет изучать OpenGL, как тут ему SFML поможет. Очевидно, что человек нужно советовать начинать писать кучу маленьких игры в 2D и 3D. Ему минимум графики нужно для первых игр. Ему нужно выводить квадраты и прямоугольники для Змейки, Арканоид, Тетрис и т.д. Без написания простых игр он не научится программировать игры. Он поставит Qt и сразу начнёт писать Pong, Аканоид, Змейку и т.д. на OpenGL. А вы ему первым по списку подсовываете Unreal Engine. Именно UE, а не Unity, потому что сами недавно начали его изучать. Ну вот он откроет UE и решит начать тренироваться программировать простые игры на C++. Вы скажете, что нужно начинать писать простые игры в UE на Blueprint. Вы сами сделали хоть одну простую игру на UE на Blueprint? А если он именно хочет на C++ и вы думаете ему легко будет написать Змейку? Но он явно написал, что хочет писать на OpenGL. И кто здесь занимается оффтопами и провокациями?

Добавлено через 12 минут

Сообщение от Mc X Хотя сам, возможно и не стал бы его использовать в чистом виде для игры.

Там будут только приятные плюшки от Qt. Всё остальное это чистый OpenGL. Человеку не надо тратить кучу времени на неигровые моменты. Надо на первых парах брать GUI на Qt. Как рисовать и перемещать квадрат он быстро найдёт. Потом он добавит жизни и очки на Qt GUI. Да это смотрится не очень. Но он же только начинает учиться. Пусть на десятки другом мини-игр у него будет такое GUI. Он может тут же сделать хранение рекордов в SQLite. Легко сделать сетевую игру по локальной сети. Пригласить друга и на двух компах зарубиться в Крестики-Нолики. Это же так приятно, что твоя игра работает по сети. А вообще даже сделать игру Крестики-нолики по глобальной сети на бесплатном хостинге, у меня есть пошаговая инструкция в блоге: Инструкция по развёртыванию Node.js сервера с WebSockets на бесплатном хостинге Heroku. Веб-клиент и Desktop-клиент (Qt). Это же представляете какая мотивация, чтобы делать простые игры по глобальной сети. Тут ещё немного можно затронуть смежные технологии, а именно Node.js и JavaScript на сервере. Нет на Qt OpenGL ничего такого, что помешало бы делать игры на OpenGL.

1

Сообщение от 8Observer8 По вашей логике Qt не подходит для работы с сетью, базами данных и многим другим, потому что "он позиционируется как ui фреймворк".

Все гораздо проще: Qt — жирное неповоротливое УГ. Поэтому оно вообще ни для чего не подходит! GUI намного веселей будет на том же Nuklear сделать с бэкендом OpenGL.

0

Сообщение от Eddy_Em намного веселей будет на том же Nuklear сделать с бэкендом OpenGL.

Я впервые в жизни слышу про Nuklear. Заглянул для интереса в репозиторий: https://github.com/vurtun/nuklear

В репозитории написано, что:

This repository has been archived by the owner. It is now read-only.

Это значит, что проект прекратил развиваться, возможно на некоторое время, а возможно навсегда.

Сообщение от Eddy_Em Поэтому оно вообще ни для чего не подходит!

Надо обязательно учитывать насколько популярный фреймворк в РФ. Вы можете подставить человека и испортить ему жизнь. Например, он выберет что-то очень мало популярное в его городе. Очень много времени потратит на этот инструмент. Овладеет им на достаточном уровне, узнает какие-то его тонкости, а потом захочет найти работу, съехать от родителей и обнаружит, что по этому инструменту нет вакансий в его городе. Он поймёт, что конторы в его городе только на Qt C++. Ему срочно нужно будет изучать Qt с нуля. Лучше, чтобы он сразу "варился" в атмосфере Qt. При желании он может стать инде-разработчиком мобильных игр на Qt OpenGL. Это вполне реально. Либо, если ему нравится программировать неигровую интерактивную 3D графику на OpenGL с панелями c GUI, то Qt OpenGL тут вообще идеален. Как я писал на Qt OpenGL можно делать интерактивные 3D-приложения для науки, промышленности, медицины, торговли, транспорта, нефте и газовой добычи, графики, диаграммы, блок-схемы, UML-диаграммы и много другое.

0

Сообщение от 8Observer8 проект прекратил развиваться, возможно на некоторое время, а возможно навсегда.

На его основе есть другие проекты. Лично мне он нравится. Header-only библиотечка, позволяющая создавать GUI без всякого убожества вроде Qt или GTK!

Сообщение от 8Observer8 Он поймёт, что конторы в его городе только на Qt C++.

Если человек хочет быть тупым кнопкодавом без собственного мнения - пусть хоть питон изучает. Но таки Qt — это жуткая дрянь. Как, собственно, и питон…
P.S. GUI на самом деле нужны настолько в редких случаях, что можно сказать, не нужны практически!

0