Но все же, может вы посоветуете нормальный ЯП и библиотеку.
Что думаете об использовании Vulkan API для анимации?
Именно на Qt я и намекал. Превосходный фреймворк, отвечающий всем требованиям, что я написал.
Но у конечных пользователей со сборкой будут большие проблемы. Чтобы Qt не требовал зависимостей, его нужно собрать в статике. А значит, надо собирать и OpenSSL. И всё это проделать для каждой платформы.
В итоге, процесс сборки получится очень нетривиальным. Чтобы упростить, можно закинуть исходники и скрипты сборки в докер. Но, в любом случае, сборка такого лаунчера не будет простой.
Что думаете об использовании Vulkan API для анимации?
В Qt всё из коробки. Если будешь делать рендеринг вручную на DirectX/OpenGL/Vulkan, то, во-первых, лаунчер ты никогда не закончишь, а во-вторых, его станет невозможно поддерживать. Писать кастомный рендер - очень плохая идея.
При очень маленьких размерах можно забыть о модульных проектах и некоторых видах защиты
Не согласен. В первую очередь, лаунчер должен быть платформой, конструктором, а не готовым решением. В самом лаунчере функций мало: скачать и проверить файлы и запустить игру. Это не займёт много места и не загромоздит код.
Модульность? API, так или иначе, уже разделяет код на модули. Например, движок для проверки файлов, диспетчер пакетов и т.д. - независимые блоки, которые не привязаны к вызывающей их стороне.
Также поясните, пожалуйста, вы про оперативную
Про оперативную. Заготовка подобного лаунчера на Qt/QML с эффектами, 3D-скином и кастомным скейлинговым шейдером (масштабирование текстурок скинов по ближайшим соседям) у меня ест ~70 мб, оттуда и цифры. Думаю, вполне адекватный жор за предоставляемые возможности.
Я тоже о этом же думал. Но можно несколько поподробней изложить свои мысли
Пусть будет общение с сервером или по чистому TCP, или по вебсокетам (у каждого свои плюсы и свои минусы, я пока остановился на вебсокетах из-за поддержки cloudflare и из-за того, что сервер пишу на Go, используя fasthttp, равных которому по скорости пока нет). У каждого пакета будет фиксированной длины заголовок, ориентируясь на который, диспетчер пакетов сможет понять, что это за пакет и как его парсить.
Например, в своих пакетах я использую однобайтовый заголовок:
A BBB CCCC
Где A - бит, определяющий, запрос это или ответ, BBB - 3 бита типов пакета (авторизация, запрос файла, запрос инфы о серверах и т.д., включая КАСТОМНЫЙ пакет с расширенным хедером), а CCCC - 4 бита порядкового номера пакета, чтобы сопоставлять ответы запросам (таким образом, от одного клиента одновременно в обработке может находиться 2^4 = 16 пакетов, что более, чем достаточно).
А следом за хедером - тело пакета. Я делаю порядок полей фиксированным, но можно для каждого поля ввести свой хедер, и порядок полей может быть произвольным. Я решил, что мне этот оверхед не нужен (и парсить фиксированно идущие поля проще).
Примерно в таком ключе у меня сделаны все пакеты протокола.
думал о wyHash или xxHash
А подумай лучше о t1ha. wyHash чуть быстрее, но рискует потерять энтропию, а xxHash медленнее тихи.
Нужна DLE - заинклудил DLE модуль, нужен WordPress - заинклудил другой, нужна панель новостей или радио - заинклудил, а не нужно - так и нечего этому делать в конечном бинарнике
Поддерживаю. У себя думаю в сторону полной кастомизации запросов, чтобы вообще не привязываться к CMS.
но хотел бы добавить - с нормальной документацией на 2х языках (RU/ENG)
Да, разумеется.
Здесь хотелось бы почитать поподробней
Т.к. юзаю Qt, то использование QML и есть та самая простота вёрстки. Но для кого-то удобнее верстать на html/css, и здесь подойдут фреймворки, типа Ultralight. Можно и в Qt верстать на html, используя WebView на основе хромиума, но, имхо, это уже изврат. А в Qt 6.0 наконец-то сделают QML полностью нативным. Осталось подождать полтора года... Так что, для меня выбор в пользу QML очевиден.
Можно поподробней, не совсем вас понял
Запуск вебчасти в отсутствие базы.
Это больше к вопросу о поддержке бэкендов: модуль для MySQL, модуль для SQLite, модуль для какой-нибудь простейшей самописной бд (хоть сырые std::map'ы, сброшенные в бинарный файлик) - позволит без какой-либо предварительной настройки окружения поднять рабочую вебчасть.
