Статьи автора: Gecko

Индустрия графической разработки окончательно повернулась в сторону эксплицитных («явных») API — то есть, таких, которые не содержат в своей реализации скрытых эвристик и не пытаются что-либо оптимизировать, строго следуя инструкциям программиста. Человек, плохо знакомый с принципами работы видеокарт, может удивиться: неужели классические OpenGL или Direct3D не подчиняются вашим инструкциям? Подчиняются, но фишка в том, что абстрактный графический конвейер, реализуемый OpenGL, на стороне пользователя не соответствует тому, что на самом деле происходит на низком уровне. К примеру, когда вы вызываете скромную, на первый взгляд, glEnable, видеодрайвер делает много вещей — сначала проверяет, что переданная константа действительна, и что вызов не происходит в недопустимом режиме, затем обновляет CPU-копию состояния, проверяя, не является ли вызов избыточным. Вместо того чтобы немедленно сообщать видеокарте о необходимости изменения, драйвер помечает состояние как измененное — фактическая аппаратная конфигурация конвейера меняется только при следующем вызове отрисовки (glDraw*). Некоторые изменения состояния — например, переключение шейдеров — приводят к значительным задержкам; кроме того, glEnable может заставить драйвер перекомпилировать внутренние скрытые шейдеры для обработки новой конфигурации, что крайне медленно (почитайте о таком явлении, как комбинаторный взрыв).

Эту проблему, вкупе с потоковой небезопасностью конвейера, новые API (Vulkan, Direct3D 12, Metal) решают путем использования неизменяемых PSO (pipeline state objects). Программист создает нужные ему конвейеры при инициализации приложения, заранее предоставляя всю необходимую конфигурацию — шейдеры, формат выводного буфера, настройки растеризации — которые в дальнейшем уже не меняются от кадра к кадру. Это позволяет драйверу производить валидацию состояния, компиляцию шейдеров в машинный код GPU и прочую тяжелую работу лишь один раз. PSO хранятся в видеопамяти, поэтому переключение с одного состояния на другое — дешевая операция, это всего лишь запись инструкции в командный буфер и никакого скрытого оверхеда. В оптимизированном рендере можно сократить переключения PSO до 15-20 и даже меньше, в зависимости от логики — для современных видеокарт это практически ничто. Вот это и есть главное, на мой взгляд, преимущество Vulkan и его родственников.

В чем же главный недостаток? А в том же самом — в неизменяемости конвейера! Если вы создаете классический Forward, вы уже не можете дать пользователям вашего движка возможность менять шейдер на уровне отдельного объекта внутри прохода. Новый шейдер — новый PSO. Создавать их на лету нельзя, нужно иметь всю информацию заранее и предусмотреть специальные проходы для всех кастомных шейдеров, если они есть. Как бы вы ни любили Forward за его гибкость, для Vulkan намного эффективнее строгий Deferred с его жестко заданными шейдерами и полным отстутствием вариативности состояния в маштабах прохода (либо Clustered Forward, но это уже другая история). Мир эксплицитных API — это мир строгих правил, где исключения обходятся слишком дорого. Если у вас есть талант придумывать хорошие правила и следовать им, то вы выиграете от этого, в противном случае вам будет тяжело и больно.

C — был бы неплох, если бы не представлял собой язык + приделанный к нему суперклеем странный, неудобный, концептуально непродуманный макропроцессор, без которого сам язык неюзабелен. Отсутствие модульности заставляет городить разнообразные малочитаемые конструкции. В каждом C-проекте — свои костыли и извращения, понятные и удобные только их авторам. Нагромождения #define’ов выглядят совершенно ужасно. C++ — то же самое, только с классами. Больше сказать нечего, ни хорошего, ни плохого. C++ точно так же застрял в 90-х, как и его предшественник — в 70-х.

Разные тулчейны C и C++ несовместимы между собой, что сильно затрудняет поддержку кроссплатформенных проектов. Сборка чужого кода — как правило, квест. Универсальной системы автоматизации сборки нет, есть лишь CMake, который сам не вызывает компилятор, а лишь генерирует конфиг под тот или иной тулчейн. Есть еще Make и GNU Autotools, которые безбожно устарели с точки зрения воркфлоу-дизайна, но под *nix безальтернативны.

С другой стороны, при всех недостатках и архаизмах, C до сих пор является важнейшим языком, так как его ABI — единственное, что позволяет программам и библиотекам, написанным на разных языках, худо-бедно взаимодействовать друг с другом. Другого универсального системного стандарта нет и, скорее всего, не предвидится.

Delphi — синтаксически крайне архаичный, но архитектурно неплохой. Основан на весьма толковой теоретической базе (на которую в реальном мире, к сожалению, всем плевать, ибо бизнес-логика). На Дельфях в свое время много чего классного было написано — жаль, что все это перестало развиваться и с годами сильно отстало от мейнстрима. Сейчас, конечно, признаваться, что пишешь на Delphi — только людей смешить. Всерьез писать на нем сложно из-за отсутствия реализаций всяческих нужных в быту стандартов, биндингов к актуальным библиотекам. Ну и это все-таки до сих пор платный язык со странно лицензируемой бесплатной версией, что неимоверно усложняет сопровождение своего кода и копание в чужом.

Python. Был раньше прекрасным языком, когда на нем просто писали скрипты и не замахивались на биг дату, нейросети, GPU-вычисления и прочие тяжеловесные штуки. Сейчас в него понапихали такого bloatware, таких костылищ… Плюс какая-то странная ситуация с управлением пакетами. Что-то там фундаментально сломано, иначе не стали бы придумывать всякий нонсенс вроде venv, conda и т.п. До сих пор не понимаю, зачем нужны какие-то изолированные окружения, почему нельзя просто ставить параллельно разные версии пакетов, поддерживать мультиверсионность на уровне языка? Pip, конечно, костыль, но conda — костыль в квадрате. Я из-за этого не пишу на Python ничего крупнее 5-10 модулей — поддерживать сложно.

JavaScript — вопреки распространенному мнению, архитектурно очень хорош (JS принято ругать именно за дизайн, но вы попробуйте написать свою виртуальную машину и скриптовый язык — сразу поймете, почему в JS сделали так, а не иначе). На практике, однако, писать на нем малоприятно из-за отсутствия нормальной стандартной библиотеки. JS не самостоятелен, он отражает сущность среды, в которую его встроили. А на мой вкус, что браузерный DOM — уродливый неповоротливый монстр, что стандартная либа Node.js — мерзость редкостная. И, опять же, странная и костыльная в языке модульность — вся эта многолетняя шизофрения с import и require. Но зато на JS тонны библиотек, которые отлично работают, десятилетиями не обновляясь — это, конечно, большое преимущество.

(продолжение следует)

Несколько лет назад я проектировал для Dagon систему больших миров на основе динамической загрузки/выгрузки ресурсов в ячейках прямоугольной сетки. До практической реализации тогда дело на дошло, но недавно я решил вернуться к этой теме. Итак, встречайте — dagon.openworld.

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

Есть класс OpenWorldManager, который управляет массивом чанков — объектов WorldChunk. Чанки полиморфны; предполагается, что пользователь напишет специализированную версию этого класса под свои нужды. Каждый чанк занимает известную заранее квадратную область в глобальном пространстве мира. Общий размер мира фиксирован и задается при создании OpenWorldManager.

Мир адаптируется к текущей позиции так называемого путешественника (traveler) — это Entity, который представляет игрока. В каждый момент времени активны до 9 чанков вокруг путешественника — окно 3×3. Когда путешественник пересекает границу между чанками, система перемещает окно по карте, активируя новые чанки и деактивируя старые по необходимости.

Активация и деактивация — это виртуальные вызовы, семантика которых полностью определяется реализацией чанка. Типовой сценарий — загрузить/выгрузить статическую геометрию и другие ресурсы, включить/выключить логику динамических объектов. Я предусмотрел небольшой гистерезис на случай, если игрок часто пересекает границу — можно отложить активацию/деактивацию на несколько секунд, до момента, когда текущий чанк перестанет меняться. Таким образом, оверхед на управление системой получается минимальный — весь тяжелый код будет в пользовательских onActivate и onDeactivate.

Для того, чтобы точность float-вычислений не падала по мере отдаления от начала координат, я, как и планировал, реализовал заворачивание позиций. Суть его в том, что при достижении игроком определенного расстояния от центра все объекты мира синхронно переносятся на противоположную сторону координатной плоскости, «из плюса в минус». Сохраняется иллюзия бесконечного пространства при ограниченном координатном охвате. Эта фича полностью опциональная — система лишь сообщает о возможности врапить координаты в те или иные моменты (через виртуальный вызов WorldChunk.onWrap и коллбек onTravelerWrap а делать это фактически или нет, решает пользователь.

В новой версии движка дебютирует физический движок Jolt Physics, в виде расширения dagon:jolt. Он предоставляет примерно тот же набор возможностей, что и Newton, при этом он лучше оптимизирован под многоядерные процессоры, а также имеет встроенный контроллер персонажа, который работает более стабильно, чем старый NewtonCharacterController. Newton, однако, в обозримом будущем никуда не денется, оба расширения будут развиваться параллельно. Я планирую также добавить поддержку встроенного симулятора автомобиля Jolt — об экспериментах с ним напишу как-нибудь в отдельном посте.

Исправлен микростаттеринг, связанный с неверной работой главного таймера. Визуально это проявлялось в виде периодических скачков изображения, заметных при движении камеры. Свойство stepFrequency переименовано в updatesPerSecond, в классе Application и в settings.conf.

Добавлены новые цветовые профили вывода: линейный (gl.outputColorProfile = "Linear") и Gamma 2.4 (gl.outputColorProfile = "Gamma24").

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

Реализована поддержка кинематических тел в dagon:newton. С их помощью можно реализовать, например, движущиеся платформы. Также добавлены новые свойства NewtonRigidBody: bodyType, collisionShape, angularVelocity, acceleration, linearDamping, angularDamping, simulationState, collidable, sleepState, autoSleep, freezeState, gyroscopicTorque и новые методы setMassMatrix, setMassProperties. В контроллере персонажа исправлено застревание в стенах при прыжке.

В dagon:audio добавлены новый метод AudioManager.setPlaySpeed и опциональный параметр громкости в методах SoundComponent.play.

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

Стоит сначала оговориться, что я имею в виду под автосимом. Традиционно все гонки делятся на два поджанра — аркадные гонки и автосимуляторы. В аркадных не используется реалистичная динамика, вместо нее — различные формы кинематики и визуальные эффекты, имитирующие физику автомобиля: например, видимость управляемого заноса — машина «смотрит» в одну сторону, но едет в другую, и игрок может управлять этим поведением при помощи какого-то простого механизма ввода (например, мобильный NFS: No Limits позволяет войти в дрифт свайпом по экрану в нужную сторону). Симулятор же в обязательном порядке использует настоящий физический движок — динамику твердых тел. В нем все честно: силы, моменты, ускорение, моделирование подвесок и трения в шинах. Как следствие, управлять симулируемым транспортом заметно сложнее, но мы получаем невероятное преимущество — практически все феномены, наблюдаемые на дороге в реальности, возникают как следствие модели, и их не нужно специально имитировать. Классический пример симулятора — Assetto Corsa.

Где-то в промежутке между чистой аркадой и строгой симуляцией затесались так называемые симкейды (simcade). Этим термином называют упрощенные симуляторы, где параметров меньше, и вождение не требует понимания автомобильной механики — при этом они настолько физичны, насколько это важно для сохранения реализма. Типичные примеры — франшизы Gran Turismo и Forza Motorsport, но, по моему мнению, любые «физичные» гонки, для которых необязателен руль и достаточно контроллера с аналоговыми стиками, можно считать симкейдом. В эпоху первой PlayStation мне дико нравилась TOCA World Touring Cars — хрестоматийный симкейд, причем, по тем временам, на удивление реалистичный: у машин правдоподобно деформировались любые части кузова, отваливался бампер, можно было даже потерять колесо. Создавая свой автомобильный движок, я держал в голове стиль именно таких игр. Следуя этой статье, конкурент Assetto Corsa вы, конечно, вряд ли сделаете, но, тем не менее, физика получится очень близкая к реальности — не хуже (а может быть, где-то даже лучше), чем во многих коммерческих играх.

Мир эксплицитных графических API переживает бурный период фрагментации. Это похоже на 90-е, когда одновременно были Glide, Direct3D 5-6, OpenGL 1.x и программные рендеры, только сейчас все куда сложнее, потому что и железо намного сложнее.

Есть Vulkan, который де-юре является современной заменой OpenGL — в том смысле, что работает на тех же платформах. Де-факто, я считаю, не является, так как далеко не каждое существующее приложение OpenGL реально перенести на Vulkan без тотальной переделки. На macOS его нет, как, собственно, и актуальных версий OpenGL. Я считаю, что на чистом Vulkan писать опасно для ментального здоровья — поверх него обязательно нужна абстракция.

Есть Direct3D 12, который работает только под Windows и на XBox. Я его традиционно в расчет не беру, поскольку писать windows-онли приложения в наши дни уже моветон. Как минимум, поддержка Linux нужна обязательно.

Есть Metal, который аналогично существует только в экосистеме Apple. Писать на нем напрямую тоже не надо, если только вы не создаете мак-эксклюзивы.

Есть WebGPU, который, казалось, должен был исправить ситуацию, объединив предыдущую троицу под единым API. С точки зрения дизайна эта задача с грехом пополам продвигается, хотя и медленно, но вот реализации пока оставляют желать лучшего. wgpu от Mozilla написан на Rust и работает как-то не очень стабильно — до сих пор утечки памяти в простейших приложениях. Ну и WGSL поделил сообщество графических разработчиков на два лагеря — одним ок, другие не признают ничего, кроме SPIR-V. Язык и правда слишком специфический, с сильным уклоном в Rust, да и в целом от WebGPU ощущение такое, что это чисто растоманский проект, не учитывающий другие языки и парадигмы программирования. И мне лично жутко не нравится его модель биндинга ресурсов. Все эти bind group layout’ы неудобные… API пилят уже пять лет, а на нем все еще страшно писать реальный код — то и дело что-то ломается непредсказуемым образом.

Наконец, появился GPU API в SDL3. Надо сказать, библиотека вообще замечательная, она уже много лет делает возможной поддержку единой кодовой базы в играх (да и не только в играх) под Windows и Linux. То, что в третьей версии появился аж целый графический API — это нехилый такой аргумент перейти на нее как можно быстрее. Мне, конечно, было очень интересно сравнить этот API с WebGPU, и данный пост я пишу как раз с этой целью.

Но прежде — небольшое резюме. Что вся эта ситуация означает для инди-разработчика? К сожалению, ничего хорошего. Сегодня уже как минимум пять мейнстримных графических API, а завтра будет сколько? Изобретут еще пять, или в результате конкуренции останутся два, как в нулевые? Кто кому уступит? Непонятно, что выбрать, потому что не хочется вкладываться в технологию, которая может сгинуть. Корпорации, разрабатывающие AAA-игры и движки, обладают ресурсами для поддержки всех технологий, с них не убудет. Но для пет-проектов и альтернативных движков, таких, как мой, это недостижимо — приходится выбирать что-то одно.

SDL3 GPU vs WebGPU

Главное, чем подкупает SDL3 GPU — минималистичность. Инициалирующие структуры не выглядят, как монстры а ля объекты JavaScript. Привязка рендера к окну — это всего лишь один вызов функции SDL_ClaimWindowForGPUDevice, а не целая эпопея с платформоспецифичными функциями, как в WebGPU. Сказывается, что SDL полностью берет управление окном и контекстом на себя. Также тут нет управления очередью и почти не нужно беспокоиться о синхронизации: вы просто создаете командные буферы под ваши задачи и отправляете их на исполнение функцией SDL_SubmitGPUCommandBuffer. Командный буфер, как и в других низкоуровневых API, — это список команд видеопроцессору выполнить какую-либо операцию (создать ресурс, скопировать данные, нарисовать примитив).

Передача данных в видеопамять осуществляется при помощи так называемых трансфер-буферов (SDL_GPUTransferBuffer). Они отображаются в системную память, так что вы можете копировать в них данные вызовом memcpy или любого другого удобного вам способа. Когда трансфер-буфер готов, он используется как источник данных для прохода копирования (SDL_GPUCopyPass), который заносится в командный буфер. В общем, основная идея эксплицитных API — сократить частоту синхронизаций CPU и GPU до необходимого минимума — тут постарались сохранить, и это чувствуется.

Отдельная головная боль WebGPU — управление свопчейном, и тут SDL3 GPU снова устраняет все сложности. Вы просто получаете текущий задний буфер функцией SDL_WaitAndAcquireGPUSwapchainTexture, обновляете ваш color target и используете его для вызова SDL_BeginGPURenderPass — и все!

Единого шейдерного языка в SDL3 GPU нет — он зависит от выбранного бэкенда. Если вы выбрали Vulkan, то это SPIR-V, если Direct3D 12 — DXIL, если Metal — MSL. Так что для мультитаргетного движка вам обязательно понадобится тулчейн трансляции шейдеров, например SPIRV-Cross. Это, пожалуй, единственная сложность, в особенности если вы не используете C/C++. Но для D я уже решил эту проблему, написав биндинги bindbc-glslang и bindbc-spirvcross. Процесс ручной компиляции шейдеров может показаться немного мудреным, но на самом деле это вещь из разряда «написал и забыл». Использование SPIR-V в качестве внутреннего промежуточного представления дает невиданную свободу — можно писать на привычном GLSL, а можно попробовать что-то новое.

Отдельная песня — привязка ресурсов к шейдерам. В SDL эту задачу решили элегантно, все 4 дескриптор-сета жестко распределены:

• Сет 0 — текстуры/сэмплеры и SSBO вершинной стадии
• Сет 1 — UBO вершинной стадии
• Сет 2 — текстуры/сэмплеры и SSBO фрагментной стадии
• Сет 3 — UBO фрагментной стадии

Биндинг-поинты вы задаете сами (в шейдере и программном коде). Единственное, что важно знать перед созданием шейдера — сколько именно сэмплеров, SSBO и UBO в нем используется. Это может поставить в тупик, так как усложняет абстракцию в движке, но даю лайфхак: эту информацию дает все тот же SPIRV-Cross (см. spvc_resources_get_resource_list_for_type). Я считаю, по сравнению с WebGPU это просто рай.

Для рендеринга используются объекты SDL_GPUGraphicsPipeline (которые задают параметры растеризатора) и SDL_GPURenderPass (к которому биндятся ресурсы). В deferred-движке их удобно объединить в одну абстракцию RenderPass. Пайплайны традиционно неизменяемые, так что после OpenGL придется привыкать к новым реалиям и оптимизировать рендер.

Вот, вроде бы, и все. Я пока не затронул compute, это тема для отдельной статьи. Разработчики SDL приятно удивили, выкатив отличный API за сравнительно короткие сроки — уже сейчас на нем вполне можно делать серьезные проекты. Хочется верить, что он не заглохнет и будет развиваться.

Как я уже не раз отмечал, игровая физика — это крайне недооцененный вид софта. Люди много говорят о графике, обыватель в играх вообще ничего, кроме графона, не замечает. А между тем, проверка столкновений и физика — вот что по-настоящему важно. Устаревший визуал и любительский уровень моделей игре можно простить, но проваливание персонажа сквозь пол и стены — нет. Я видел множество инди-проектов, потенциал которых был загублен именно плохой физикой (и, как следствие, неудобным управлением), а не графической или геймплейной составляющими. В мире инди и СПО вообще редко связываются с «физичными» жанрами типа экшнов, гонок, симуляторов и т.д. Свободные игры — это в основном стратегии, песочницы, 2D-аркады, рогалики. Физика довольно устойчиво ассоциируется с AAA и колоссальными бюджетами крупных издателей. Причина, конечно, в том, что она непредсказуема и плохо программируется. Она хороша в «чистом» виде — скажем, в симуляторе бильярда, где простая геометрия и нет вычислительно сложных ситуаций. Но если физика должна быть подчинена игровой логике, а не наоборот, то решения «по учебнику» резко перестают работать, приходится изобретать невиданные хаки и решать дичайшие корнер-кейсы. Это и отличает AAA от любительского геймдева — там коммерческие секреты, ноу-хау, огромный опыт. Я вот давно уже пишу контроллеры персонажа и не понаслышке знаю, как это непросто. А ведь хочется получить этот священный Грааль — чтобы персонаж свободно двигался по карте, не застревал, правильно сталкивался с препятствиями, поднимался по склонам и лестницам. Сегодня это необходимая база для 3D-игр любого жанра, кроме совсем уж простеньких.

Этот релиз ознаменовался серьезным рефакторингом постпроцессинга в движке: внесено множество оптимизаций и новых возможностей, а также появилась поддержка пользовательских фильтров (PostProcRenderer.addFilterPass). Возвращена поддержка автоэкспозиции, которая когда-то уже была реализована, но впоследствии удалена из-за архитектурных изменений в движке. Управляется параметрами hdr.autoexposure, hdr.keyValue, hdr.exposureAdaptationSpeed в render.conf. Добавлены эффекты виньетирования (vignette.enabled, vignette.strength, vignette.size, vignette.roundness, vignette.feathering) и film grain (filmGrain.enabled, filmGrain.colored). Реализован высококачественный фильтр повышения резкости с алгоритмом на основе FidelityFX CAS (sharpening.enabled, sharpening.strength). Добавлены новый тонмаппер Lottes (hdr.tonemapper: "Lottes"), новые параметры фильтра Depth of Field (dof.circleOfConfusion, dof.pentagonBokeh, dof.pentagonBokehFeather), улучшен фильтр шумоподавления SSAO — добавлена поддержка взвешивания на основе глубины, что устраняет гало-артефакты на близких расстояниях. Фильтр цветокоррекции теперь поддерживает изменение яркости, контраста и насыщенности (cc.brightness, cc.contrast, cc.saturation). Также можно напрямую задать 4×4 матрицу цветокоррекции (cc.colorMatrix). Если используется LUT, эти параметры игнорируются.

Улучшен воркфлоу таблиц цветокоррекции (LUT). Добавлено новое свойство TextureAsset.lutFormat, посредством которого загрузчик текстур понимает, что нужно конвертировать двумерную таблицу в 3D-текстуру. Поддерживаются два формата — LUTFormat.Hald и LUTFormat.GPUImage. Свойство TextureAsset.loadAs3D удалено, вместо него теперь надо задавать TextureAsset.lutFormat = LUTFormat.Hald;. Дефолтная таблица формата GPUImage (загружаемая опцией lut.file) теперь автоматически конвертируется в 3D-текстуру. Если вы загружаете GPUImage LUT вручную, то можно ее не конвертировать, но отныне рекомендуется делать это для более эффективного сэмплинга в шейдере.

Добавлен опциональный вывод в честный sRGB вместо обычного Gamma 2.2. Теперь можно задать цветовой профиль вывода при помощи опции gl.outputColorProfile в settings.conf. Возможные значения (строковые): "Gamma22", "sRGB".

Реализована поддержка глобальных определений макропроцессора GLSL (функция globalShaderDefine в dagon.graphics.shader). Чтобы их использовать в шейдерах, нужно добавить виртуальный инклюд #include <dagon>.

Добавлена поддержка сохранения в DDS кубических карт, 3D-текстур и RGTC-текстур. Появилась новая функция downloadTexture для выгрузки текстур любого формата из видеопамяти.

Появился новый тип событий EventType.KeyboardLayoutChange и соответствующий метод-обработчик onKeyboardLayoutChange. Это событие возникает, когда пользователь переключает раскладку клавиатуры.

Новая версия движка. Добавил возможность загружать кастомные курсоры и заменять ими системные курсоры в приложении (методы Application.loadCursor, Application.replaceCursor). Появилась поддержка многомониторных конфигураций — теперь можно задать индекс монитора для создания игрового окна (опция window.display в settings.conf). Добавлены новые свойства класса Application: displayCount, displayIndex, displayWidth, displayHeight, desktopWidth, desktopHeight, refreshRate, framebufferFormat.

В модуль dagon.graphics.shape добавлены новые геометрические тела: ShapeCapsule (капсула), ShapeTorus (тор).

Появилась Поддержка uniform-массивов — шаблонный класс ShaderParameterArray и метод Shader.createParameterArray. Методы Shader.setParameter, Shader.setParameterRef, Shader.setParameterCallback, Shader.setParameterSubroutine, Shader.getParameterValue помечены как deprecated. Рекомендуется работать с объектами параметров напрямую.

Добавлена поддержка несжатых текстур RGB8 и RGBA8 в экспортер DDS, а также несжатых RGB8 в загрузчик DDS. Реализована перегрузка функции loadImageViaSDLImage, которая возвращает SDL_Surface*.

К Vulkan я испытываю если не неприязнь, то во всяком случае изрядный скепсис. Это API для машин, а не для людей. Писать на нем напрямую — это ад, и веских причин пытать себя вулкановскими ужасами (во всяком случае, в инди-разработке) я за эти десять лет так и не увидел. Оптимизация CPU-bound частей рендера? Вы не Epic Games, чтобы этим заниматься — ресурсов не хватит. DLSS, трассировка лучей? В реальности все эти навороты в играх отключают первым делом, чтобы играть, а не смотреть слайдшоу, ибо видеокарты у большинства далеко не топовые.

Но вот что забавно: вулканисты сами признают, что использовать Vulkan необязательно! Если не верите, откройте Reddit. Вот что я там нашел:

pls use vk-bootstrap, dynamic rendering, VMA in big 2026. Don’t do raw vulkan. You will lose motivation sooner.

То есть, без разнообразных обвязок и прибамбасов писать на Vulkan принципиально не рекомендуется! Это прям классно — напомнило времена GLU, GLUT и тому подобного. Я и сам пробовал много всяких компромиссных вариантов — вкатывался в WebGPU, щупал LLGL и GPU API в SDL3, но везде одна и та же жопа в разных ракурсах: нужны дополнительные инструменты, как минимум для компиляции шейдеров и SPIR-V рефлексии. Оверхед по расходу памяти от всех этих обвязок немаленький, в WebGPU вообще память течет — привет растоманам. И я уж молчу про то, что обвязки систематически ломают обратную совместимость, так что писать на них — то еще удовольствие.

А вот это вообще анекдот:

Your options are basically:
— Learn Vulkan, but use AI to fill in the boilerplate.
— Use CUDA instead of Vulkan.

Без ИИ сегодня, конечно, вообще никуда 😂 А графическая разработка — такая уж область, ChatGPT ногу сломит. Ну и наконец:

OpenGL is perfectly viable in 2026 for hobby programmers and you’ll probably even get better performance out of it than not knowing how to use Vulkan and using it anyway. Hardware support is also completely fine. If you want to learn Vulkan, go do it. If you don’t, there’s better alternatives.

Занавес. Directed by Robert B. Weide.