Хорошие новости: мне удалось восстановить большую часть постов 2026 года (правда, без картинок) из локального архива и сохранившихся копий Wayback Machine. В архивах сохранилось многое, но, к сожалению, все это практически невозможно импортировать в WordPress без ручной правки. В ближайшее время я восстановлю материалы за 2025 год, а остальным буду заниматься по мере сил.
Вскоре напишу подробный пост о том, что произошло с сервером.
Из-за серьезных проблем с датацентром, на котором в последнее время был размещен блог, мне пришлось мигрировать на новый VPS. К сожалению, восстановить базу постов не удалось. Все, что я пока смог воссоздать — тема и некоторые страницы в меню (их версии по состоянию на май 2025 года).
Я не оставляю надежду, что еще удастся вернуться на старый сервер, где сохранились все данные, но большого оптимизма по этому поводу нет. Вероятнее всего, придется начать все с нуля.
В предыдущем посте я уже писал о том, почему glTF нельзя использовать в качестве полноценного формата игровых ассетов, и вот альтернатива, которую я специально проектирую для Dagon 2.0 — Dagon Asset Format, сокращенно DAF.
DAF хранит, в первую очередь, вершинные буферы для прямой передачи в VRAM. Формат бинарный, архитектурно соответствующий API Dagon 2.0 и расширяемый: в нем могут быть объявлены любые дополнительные структуры данных и даже динамические свойства, не ломая обратную совместимость.
Основные задачи формата:
Спецификация DAF находится здесь.
В Dagon 1.0 я очень много времени потратил на поддержку этого монструозного формата моделей, и спустя пять лет работы с ним у меня не осталось ничего, кроме разочарования. Главный вывод: glTF — не для игровых ассетов (т.е. карт и отдельных переиспользуемых моделей). Это формат, предназначенный исключительно для просмотра, причем в основном в браузере, на WebGL, при помощи вьюверов типа Sketchfab. В этом он свою задачу выполняет, хотя и тоже неидеально. Но то, что его все начали использовать как формат обмена данными между программами моделирования и игровыми движками — это фундаментальная ошибка. Ниже мой личный список недостатков glTF, актуальных, прежде всего, в контексте игрового рендеринга.
В общем, в Dagon 2.0 я обязательно буду пилить собственный формат ассетов, учитывая весь этот опыт. Поддержка glTF сохранится благодаря библиотеке Assimp, но формат больше не будет позиционироваться как основной.
Разработка Dagon 2.0 началась в весьма бодром темпе. Deferred-рендер уже почти готов — остались только тени PSM и DPSM, поддержка локальных зондов освещения и forward-проход. Я добавил систему кэширования ресурсов, сжатие в BC7 (на основе компрессора bc7enc Рича Гелдриха) и проделал еще множество мелких улучшений на разных стадиях формирования кадра. Особое внимание я уделил тому, чтобы картинка соответствовала Eevee в Blender 5.
Что еще нового? Часть функциональности, которая в Dagon 1.0 существует в качестве расширений, теперь войдет в ядро — это физика на базе Jolt и загрузчик текстур в формате KTX/KTX2. Такое решение я принял исходя из полезности этих фич, простоты сборки Jolt и libktx из исходников и их автономности: они не имеют собственных зависимостей и отлично работают на всех платформах (в противовес тому же Newton, который имеет проблемы с работой некоторых функций под Linux). Наличие libktx «из коробки» дает серьезные преимущества и ставит Dagon 2 в авангард движкостроения; в будущем не исключен перевод текстурного кэша с DDS на KTX2.
Еще одним нововведением будет встроенная VM GScript3, которую я разработал в прошлом году. Движок при старте загружает скомпилированный байт-код скрипта и выполняет его, а скрипт, в свою очередь, навешивает обработчики событий, позволяя, таким образом, выполнять внешнюю логику без пересборки игры. Игра может экспонировать скриптовой системе свои данные и методы, что полезно для создания модов. Некоторые встроенные классы Dagon уже реализуют интерфейс GsObject и напрямую совместимы с GScript: это Entity, Scene, World, BaseGame.
Зарегистрирован пакет dagon2 в реестре DUB, так что начать пользоваться можно уже сейчас.
В связи с тем, что в России для владельцев доменов в зонах ru/su/рф ввели обязательное подтверждение через Госуслуги, я решил отказаться от timurgafarov.ru и перенести все свои персональные ресурсы на pixperfect.online. Это касается следующих сайтов и страниц:
Я пишу графику на OpenGL много лет (с 2009 года) и считаю, что этот классический API — до сих пор самый очевидный выбор, если вам нужно кроссплатформенно вывести что-то на экран. В сочетании с SDL это еще и очень просто — код приложения со всеми его ключевыми компонентами (окно, графика, ввод) получается на 99% независимый от операционной системы. Для 2D-проектов этой связки более чем достаточно, но в играх с продвинутой 3D-графикой, которая выжимает максимум из видеокарты, теперь, к сожалению, все сложнее.
Я выделяю три главные архитектурные проблемы OpenGL: однопоточность, частая синхронизация CPU и GPU и сложность управления глобальным состоянием конвейера. Новые низкоуровневые API решают все это, особенно последнее, жертвуя удобством написания приложений и вообще входным порогом в профессию графического разработчика (я не представляю, как можно изучить концепции и идиомы Vulkan с полного нуля — я бы рвал на себе волосы, если бы пришлось объяснять начинающим, что такое дескриптор-сеты, PSO и барьеры памяти). Долгое время между OpenGL и Vulkan была совершенно непреодолимая стена концептуальной несовместимости, мешающая портировать игры. OpenGL, между тем, хоть никуда и не делся, развиваться перестал. Под macOS — старая версия, под Windows — довольно серьезная проблема с вертикальной синхронизацией в оконном режиме, приводящая к статтерингу (это полноценно решается только путем работы поверх свопчейна DXGI, что требует нетривиального бойлерплейта в приложении, либо поддержки со стороны видеодрайвера). Ну и до кучи в OpenGL нет поддержки HDR-режима Windows, что некритично, но не круто.
Все это подводит к мысли, что OpenGL, каким бы он комфортным ни был, уже отжил свое. Но и на Vulkan переходить совершенно не хочется. Познакомившись с SDL GPU, я решил попробовать портировать на него некоторые ключевые части Dagon и быстро понял, что этот API — именно то, чего мне и не хватало в последние годы. WebGPU стал разочарованием из-за громоздкости интерфейсов и спорного синтаксиса WGSL, а здесь с этим проблем нет.
Исходники Dagon 2.0 доступны в отдельном репозитории на GitHub: https://github.com/gecko0307/dagon2. На данный момент перенесен dagon.core, реализованы G-буфер, базовый deferred-рендеринг, тонмаппинг и анти-алиасинг. Движок загружает модели OBJ и текстуры в стандартных форматах, поддерживает кубические карты и DDS. Судя по всему, большая часть возможностей Dagon будет перенесена без серьезных изменений, картинка движка останется прежней, но не исключены архитектурные улучшения и CPU-оптимизации. Также изменится шейдерный API — на днях напишу отдельный пост об этом. Переход на Vulkan-бэкенд должен заметно ускорить рендер, а также позволит использовать HDR-свопчейн, если дисплей позволяет выводить в extended linear.
Я не уверен, что процесс портирования будет быстрым, но впечатления от работы пока весьма положительные, код для SDL GPU компактный и читаемый. Самая нетривиальная часть — воркфлоу компиляции шейдеров, но я уже смирился с тем, что от GLSLang в современных условиях никуда не денешься. Есть вероятность, что Dagon 1.0 я выпущу уже в ближайшее время, чтобы полностью сосредоточиться на порте.
Рад сообщить, что наконец-то выпустил Dagon 1.0.0, первый стабильный релиз моего игрового движка! Это в основном исправляющий релиз, который подытоживает огромную работу над Dagon, которую я проделал за последние два года. Набор основных фич заморожен, дальше будут только багфиксы и развитие расширений (которые все пока экспериментальные и нестабильные). Также у меня в долгосрочных планах написать редактор сцен, концептуально близкий к редактору Unity.
Индустрия графической разработки окончательно повернулась в сторону эксплицитных («явных») 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 тонны библиотек, которые отлично работают, десятилетиями не обновляясь — это, конечно, большое преимущество.
(продолжение следует)