Уже долгое время пишу игровой движок общего назначения (т.е. не исключительно для какого-то одного жанра). Естественно, под GPL. Естественно, онтопик – гражданин перого класса. Использую инфраструктуру Qt. Сейчас проект состоит из:

• Библиотеки libKawaii3D, предоставляющей классы для построения одной или нескольких трёхмерных сцен.

• Библиотеки, облегчающей создание различных Renderer плагинов libKawaiiRenderer.

• Renderer плагина libMisakaRenderer. Использует OpenGL 4.5 Core + ARB_bindless_texture.

• Renderer плагина libKurisuRenderer. Использует Vulkan, Glslang и SPIRV-tools.

• Плагина загрузчика ассетов libKawaiiAssimp. Загружает модели, меши и сцены из файловой системы, используя библиотеку libAssimp. Примеры передаваемых строк: "models/preCombinedCastle.fbx", "file:///usr/share/somegame/character.dae", "/home/user/models/helicopter.obj".

• Плагина загрузчика ассетов libKawaiiFigures3D. Загружает некоторые простые меши – куб, сферу, тетраэдр, октаэдр, икосаэдр, тор, квадрат и плоскость. Примеры передаваемых строк: ":/cube_x5", ":/octahedron_x0.33", ":/torus".

• Библиотеки libKawaiiWorlds. Игровой движок. Отвечает за загрузку и хранение ассетов, физику, переходы между локациями, сетевой мультиплеер, воспроизведение музыки и звуков, обработку пользовательского ввода, ландшафты с картами высот и вот это вот всё.

• Библиотеки libKawaiiWorlds_qml. Поддержка QML и JavaScript для libKawaiiWorlds. Предоставляет классы обёртки над классами и структурами движка.

• Приложения KawaiiWorldsViewer. Загружает игры, читая специальный json файл. Таким образом избавляет большинство игр от необходимости иметь собственный бинарный исполняемый файл и обеспечивает независимость от ОС и, до определённого предела, архитектуры CPU. Предполагается, что такие игры-миры будут использовать JSON файл для указания используемых моделей, текстур, шейдеров, материалов и прочего; JavaScript для игровой логики и QML для разметки GUI.

Повесточка:

• Пишу игру – пошаговую мультиплеерную стратегию. Цель сделать так, чтобы у соперника не осталось городов (либо штурмануть, либо уйти в глухую оборону и ждать пока монстры спушат супостата по самые уши). Осаду городов планирую сделать в стиле TowerDefence, драку между юнитами – исключительно на глобальной карте. В целом имеется достаточно подробная задумка и лимитированный скоуп. Слишком сильно распространяться сейчас не хочу – пока не доделаю играбельный прототип.

• Как придумать название игре? Может ли ЛОР помочь с этим? :)

• День после. С достаточно большой уверенностью, могу сказать, что до играбельного прототипа я дотолкаю игру довольно скоро. А что дальше? Работает ли краудфандинг для движков / игр? Если да, то что на него нужно предоставить? На каких площадках? Если нет, то как найти патронов / инвесторов? Понятно, что в этой стране геймдев мёртв и посыпан токсичной радиоактивной пылью мобилькерами, так что искать нужно среди интернационалов. Интересны ли энтузиасты, например Valve, или они только место в Стиме продадут? Кому бывают интересны?

• Было бы классно обрасти командой единомышленников – художников, композиторов, левел дизайнеров, программистов, девопсов и прочих. Сейчас тащу в одно, в меру отъетое, лицо :D

• Средства для локализации / интернационализации игр-миров на уровне движка – нужно ли и в каком виде?

• Позиционный звук – что для него вообще использовать? /*в игре юзаю QML-ский AudioEngine, но понятно, что это "ну такое"*/ Первым в голову приходит OpenAL, но он в последних версиях спроприетарился и скурвился. Использовать старые версии? Или есть современные решения?

• Поддержка языков кроме C++ и JavaScript – на сколько нужно? Сейчас поддерживается C++, так как сам движок написан на нём, так что достаточно было не превращать его в монолитное монструозное. А JavaScript, так как Qt имеет всю необходимую инфраструктуру для этого, ну и сам язык довольно простой, да. Пока склоняюсь к тому, не особо приоритет, а всякие пайтоны, lua и прочие расты могут подождать.

• Сейчас есть PKGBUID-ы под этот наш Арч и они хороши. Но что бы придумать с поддержкой других десктопных дистров? Есть скрипты и даже CMakeLists.txt, чтобы скачать все модули движка в уютный хомячок и там же собрать. Нужно ли подобное? Стоит ли их поддерживать / обновлять и т.д. или лучше сделать разбиение на пакеты также как для Арча, с использованием, например CPack?

Скриншотики: https://imgur.com/a/zhHhcnw

Исходники: https://gitlab.com/KawaiiGraphics

Подразумевается именно связка железо + установленный драйвер на основном девайсе с Linux на борту. Посмотреть версию OpenGL можно командой glxinfo -B, а версию Vulkan – vulkaninfo --summary. OpenGL и Vulkan обладают обратной совместимостью (т.е. если поддерживается, например OpenGL 4.5, это значит что и все предыдущие версии поддерживаются). Если поддерживается, например, Vulkan 1.2.145, то и все предыдущие – тоже. Vulkan и OpenGL – разные графические API, так что в системе может поддерживаться один и не поддерживаться другой.

По аналогии с QOpenGLPaintDevice.

Чтобы скормить ему в конструктор VkDevice, VkFramebuffer, VkCommandBuffer и рисовать QPainter-ом спокойно. А потом просто отправить этот командный буфер на счёт и изображение бы в VkImage отрендерилось. А внутри САБЖ бы сам менеджил необходимые ему буферы, текстуры, шейдеры, и т.д.

А может и вовсе система QPainter-ов устарела? Если так, то какой современный API agnostic способ рисовать в Qt двумерное что-то?

Примерно за пол-года вроде как разобрался с Vulkan.

Пишу сейчас рендерер плагин для своего графического движка

https://gitlab.com/KawaiiGraphics/KurisuRenderer

После OpenGL, для которого всё есть GLint либо GLuint, очень порадовала типизация. Также командные буферы – действительно крутая вещь – в них мало того, что можно писать из нескольких потоков (хотя и с ограничениями), так ещё и записанные однажды, они могут использоваться многократно! Возможность обеспечить более полную загрузку железа с меньшим временем на ожидание вертикальной синхронизации, например, через явное управление очередями тоже впечатляет.

В общем Vulkan в целом мне зашёл. Но есть несколько «но».

Во-первых непонятно зачем перекорёжили гомогенные координаты – ось y зачем-то направили вниз, а глубину и вовсе загнали в интервал от 0 до 1, вместо -1 до 1. Насколько я понимаю, то как направлены оси, в общем-то, ни от чего не зависит. Просто решили, что они направлены вот так и всё. А потому не ясно зачем было менять их – если бы оси были направлены как в OpenGL, можно было бы кормить Vulkan теми же матрицами и мешами, что и OpenGL без всяких плясок с бубном в шейдерах. Ну да ладно, направили оси иначе и направили.

Во-вторых и в главных – SPIRV. В OpenGL замечательная система шейдерных модулей, для которых компиляция отделена от линковки, которая позволяет приложению конструировать шейдерные программы (а в последних версиях OpenGL стадии) из функциональных взаимозаменяемых блоков. Совершенно не ясно, зачем было её херить :( В Vulkan стадии стали неделимыми, так ещё и бинарными. У нас всё ещё графический API и ли какой-нибудь уродский .NET с промежуточным байт кодом? Видимо разработчикам движков так ненавязчиво предлагается иметь некоторый набор заданных заранее семейств материалов и не давать пользователям в руки шейдеры в принципе? Но это же дно-о-о. Мы так в 90-е – 00-е вернёмся, когда был только фиксированный графический конвейер – и всё. В 20-х у нас будет чуть больше моделей освещения/затенения, парочка интересных эффектов водной поверхности, огня и т.д. Но всё так же никакой гибкости.

В общем будущее светло, но не безоблачно. Многопоточный рендеринг, кеширование сцен и возможность безбубенной многооконности, сияют, превращая ночь в день, а днём затмевая Солнце; а маячащая на горизонте возможность multi GPU через DMABUF звучит как гимн разума и изобретательности :D Но отношение Khronos к шейдерам, как минимум, настораживает..

Кто уже тоже успел повулканить? Что думаете о наступившем будущем?

На ура декодирует 4K VP9, запросто играет банальные FullHD h264, но сыпется и резко притворяется шлангом с лапками при одном взгляде на устаревший MPEG4.

В документации написано, что в шейдерах допускается использование только резидентных хендлов, так как «Conceptually, image data being resident means that it lives within GPU-accessible memory directly», а нерезидентные хэндлы текстур, мол, не доступны ГПУ-шке напрямую. Однако на AMD Raven, AMD Carrizo, AMD Iceland (и я полагаю, что на любых поддерживаемых драйвером radeonsi) при использовании в шейдерах нет разницы является хендл резидентным или нет. За одним исключением — на AMD Raven при попытке вне-экранного рендеринга (с использованием FBO) в резидентную текстуру сцены, эту текстуру использующей (есть подозрение, что даже если эту текстуру не использовать, поведение не изменится — проверю завтра (6 октября)) случается GPU Hang. В случае, если перед рендерингом в текстуру отобрать у последней резидентность и вернуть лишь после завершения вне-экранного рендеринга, хэнга не случится.

У «зелёных» всё ещё интереснее — на GT 650M при попытке чтения в шейдерах текстуры через нерезидентный хендл, возвращается vec4(0.0). При этом всё работает корректно, если хендлы резидентные. При попытке устроить «Уроборос» — рисовать в текстуру сцену, использующую эту текстуру через резидентный хендл, она (текстура) будет мерцать (flickering). Если перед отрисовкой отбирать резидентность у хендла, фликеринг пропадает.

Вопросы к спецам 3D графики ЛОР-а — Хэнг при «Уроборосе» на Raven — это баг? Фликеринг при уроборосе на GT 650M — это баг? Является ли рендеринг сцены в текстуру с резидентным хендлом корректным поведением для программы? А использование этого хендла в процессе рендеринга сцены? Что значит резидентность хендла для radeonsi? А для NVIDIA? И в конце концов, какого чёрта происходит?

UPD: Хэнг на Raven происходит даже если хэндл текстуры цели вне-экранного рендеринга нигде не используется, а просто есть.

UPD2: Главные вопросы: Является ли рендеринг сцены в текстуру с резидентным хендлом корректным поведением для программы? А использование этого хендла в процессе рендеринга сцены? Что значит резидентность хендла для radeonsi? А для NVIDIA?

Фикс проблем вне-экранного рендеринга я уже запилил в двигло. Сейчас хочется разобраться, почему с ним всё оки, а без него — раком.

Играюсь с аутентификацией и шифрованием сообщений на Kerberos5 через GSSAPI. Если и клиент и сервер на GNU/Linux, всё работает юзеры аутентифицируются, сообщения ходят. Однако на Windows (насколько я знаю) GSSAPI отсутствует. При этом имплементация Kerberos есть и там. Отсюда вопрос — «нафига им чемодан (Kerberos) без ручки (GSSAPI)?» «Как происходит взаимодействие приложения с Kerberos на Windows?». И, если способ есть, сильно ли он отличается от GSSAPI?

P.S. Пишу сюда, так как winfaq здесь (http://winfaq.org.ru/forum/development/14412561)

Делаю графический/игровой 3D движок Kawaii3D. Параллельно с этим пишу первую серьёзную технодемку к нему — геймплей что-то вроде трёхмерной версии hedgewars. Управляемые игроками модельки закидывают друг-друга гранатами. Требуется модель разрушений (после взрывов остаются кратеры и дыры в статических объектах, при этом висящие в воздухе куски ландшафта — норма). Вопрос: как лучше представить ландшафт: вокселями (ака minetest), картой высот, или чем ещё?

Что из себя будет представлять: библиотека на C++ для работы с real-time 3D графикой. Часть будущего игрового движка, который пока только в мечтах (вероятнее всего будет состоять из 3D графического движка, движка позиционного звука, движка физики, движка скриптов и фасада над этим всем).

Основная архитектурная задумка: есть parent-child дерево объектов, состояние которых не зависит от используемого api рендеринга (OpenGL 3.3 Core, OpenGL 4.5+ Core, Vulkan, DirectX, ...) или операционной системы. Узел 'A' является дочерним по отношению к узлу 'B', если без узла 'B' узел 'A' не имеет смысла (например инстанс меша без сцены). Некоторые типы узлов могут менять своё состояние в зависимости от родительских или дочерних узлов, которые при могут не быть непосредственными parent/child конкретного узла. По этому дереву «модели» строятся деревья «контроллеров» — в основном рендеры, но можно и что-нибудь ещё туда прикрутить (мутаторы от пользовательского ввода, например).

Уже есть: «основа» движка — меши; шейдеры; (квази)статичные 2д текстуры (aka картинки, меняться могут, но редко); 2д текстуры, в которые выполняется внеэкранный рендеринг; OpenGL 4.5+ Core (требует ARB_bindless_texture) рендер; плагин со статичной геометрией; плагин для загрузки сцен с помощью библиотеки libassimp.

Запланировано: поддержка арматуры/скелетной анимации; модели освещения; Vulkan рендер.

Ядро движка: https://gitlab.com/KawaiiGraphics/Kawaii3D

OpenGL рендер: https://gitlab.com/KawaiiGraphics/Misaka3D

Assimp плагин: https://gitlab.com/KawaiiGraphics/KawaiiAssimp

Плагин со статичной геометрией: https://gitlab.com/KawaiiGraphics/KawaiiFigures3D

Сэмплы: https://gitlab.com/KawaiiGraphics/Kawaii3D-Samples

Скриптики для простой компиляции и запуска самлов, без необходимости ставить что-либо из моего софта в систему: https://gitlab.com/KawaiiGraphics/KawaiiEnvironment

Зависимости: Qt5, glm, libassimp (только для плагина KawaiiAssimp, https://github.com/assimp/assimp), sib_utils (https://gitlab.com/VadikLeshy/sib_utils).

Гну/Линукс при том, что это, вероятно, единственная ОС, где сие поделие работает как надо. В дальнейшем я добавлю полноценную поддержку, и форточек, и бздей, но сейчас хотя бы под линухом завезти всё, что запланировано.

upd: Сделал рефакторинг — теперь связи с родительскими (возможно не нпрямую) узлами, влияющими на поведение вычисляются в самом движке, а не в рендерах. Запустил одну из демок на Raven Ridge (вторая всё так же вызывает на нём GPU hang из-за фреймбуффера).

Скриншоты: AMD Raven Ridge: 1, 2.

AMD Radeon R7 M440: 1, 2, 3.

upd2: Решены некоторые проблемы со сборкой при использовании скриптов из репозитория KawaiiEnvironment.

Собственно сабж. Существует какой-либо метод, вызывающийся до/после изменения, событие определённого типа, сигнал.. Да хоть что-нибудь, чтобы узнать об изменении родителя.

А ещё почему-то для QWidget есть события об изменении родителя, а для остальных объектов — нет.

Настроил бар на показ при удержании Meta+Grave, как описано здесь. Получил мигающий (исчезающий и появляющийся вновь) трей при удержании комбинации. Трей мигает не зависимо от того, на каком баре он расположен.

Грешу на autorepeat событий клавиатуры.

Вопрос - возможно ли сказать i3, чтобы он игнорировал события autorepeat, или заставить трей работать как надо каким-либо другим способом?

Пишу велосипед грузящий wavefront, md5 (модельки из дума 3 - не чексуммы :D). Умеет модели освещения, псевдоотражения (на фреймбуфферах), скелетную анимацию и нескучный препроцессинг шейдеров.

Через пару месяцев собираюсь выкладывать на github. Будет документация в виде текста и UML.

По лицензии хотелось бы, чтобы его можно было использовать в свободных/открытых проектах (обязательно) и может быть в коммерческих (кроссплатформенная индюшатинка в 3D).

Хочу сохранить право называть себя автором проекта (и защитить его в качестве дипломной).

Какую лицензию посоветуют знатоки?

В стародавние времена, когда видеокарты были VLIW любые мало-мальски сложные ветвления убивали производительность шейдеров наповал. В частности, если был цикл for(int i = 0; i < count; ++i), то гуру рекомендовали count сделать константой времени компиляции, если это возможно.

Однако сейчас миром правят CUDA, GCN и прочие GPGPU. Для них ветвления не так ужасны. Хотелось бы услышать рекомендации по оптимизации шейдеров под это новьё - чем профайлить (а то сейчас у меня всё на глаз - лагает - не лагает), какими конструкциями лучше пользоваться как можно реже, какие обходятся практически «бесплатно». В гугле не забанили, но он подсказывает, как оптимизировать для мамонтов.

И ещё один чисто практический вопрос - что лучше 3 for-а без if-ов внутри них, или 1 for с 3 ветвлениями внутри тела? Ветки достаточно крупные - обработка разных типов светильников (направленный, точечный и прожектор). count для всех случаев переменный.

Пишу Just for lulz графический движок - библиотеку классов для построения сцены(включая загрузку моделек) и её отрисовки на OpenGL. Через какое-то время проект разросся и на данный момент состоит из 59 классов, выполняющих самые разные функции. Ада зависимостей нет и поэтому библиотека спокойно разрезается на несколько частей - core и различные надстройки (поддержка текстурирования, освещения, ввода, графа сцены, форматов моделек и пр.). Разрезание на модули позволит приложениям-пользователям не тащить в зависимости то, что им не нужно (зачем, например, вьюверу моделей поддержка fbo и ввода с джойстика), а самое главное упростит изучение API и кода (планирую GPL-ить).

Собственно, какое количество классов оптимальное для разделяемой библиотеки c++? Нормально ли, когда в библиотеке лежит 1-3 маленьких класса и больше ничего?

После того как вызван

ctx0->setShareContext(ctx1);

ctx1->setShareContext(ctx0);

В документации написано, что после этого ctx0 должен быть пересоздан, по логике должен быть пересоздан также ctx1, так?

Если есть несколько экземпляров потомков QOpenGLWindow, которые отображают одну и ту же сцену и QOpenGLContext с QOffscreenSurface для инициализации ресурсов, то можно ли использовать context()->setShareContext(..) или обязательно нужно использовать параметр конструктора?

Для работы с ресурсами нужно использовать QOpenGLFunctions, полученный из текущего контекста, или сойдёт из любого контекста, находящегося в разделяемой группе?

Сабж не даёт начать новую игру в wine. Видео - Intel Ivy Bridge. На оптимусовской NVIDIA GT 650M выдаёт серый экран и больше ничего.

Версия wine - staging 1.9.7; Версия mesa - 11.2.0;

Только-только научился писать простенькие 3D игрушки на OGL 3.3, а тут такое. А раз Vulkan - замена OpenGL, то последнему недолго осталось перед тем, как его поддержку дропнут в драйверах. Сколько времени можно ещё отсиживаться на OpenGL?

Для менюшки приложений Openbox 3.6 на локалхосте использую xdg-menu, однако он использует тему иконок gnome. Мне хотелось бы чтобы он использовал другую тему иконок (используемую GTK и Qt приложениями). Возможно ли это? И если возможно, то как реализовать?

Поиск на http://qt-project.org ничего не дал, только демки. Значит ли это, что описания всех c++ классов и qml типов этого модуля нет в природе? Если оно всё же есть, то где?