Const-корректность в D

Русский перевод моей статьи «Const-correctness in D». Оригинал опубликован на Medium.

Ключевое слово const знакомо каждому программисту — оно присутствует во многих современных C-подобных языках и используется в самых разных контекстах. В общем смысле оно означает, что переменная неизменяема и может быть инициализирована только один раз. Чаще всего такой упрощенный смысл const встречается в динамических языках, однако в мире статической типизации, в том числе и в D, существует несколько видов неизменяемости, и понимание этих различий крайне важно для написания надежного ПО.

(далее…)

Dagon 0.21.0

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

  • Переход на SDL 2.32. Под Linux движок теперь предоставляет готовую библиотеку libSDL2-2.0.so, которая копируется в папку с приложением — чтобы ее использовать вместо системной, нужно собирать с флагом линкера "lflags-linux": ["-rpath=$$ORIGIN"] (либо перед запуском задавать рабочую папку в LD_LIBRARY_PATH, что, на мой взгляд, намного менее удобно)
  • Текстуры теперь загружаются через библиотеку SDL2_Image, если она присутствует. Благодаря этому появилась поддержка прогрессивных JPEG, WebP, AVIF, SVG и множества других форматов. Необходимые библиотеки также копируются в проект при сборке (для 64-битных Windows и Linux). Также можно реализовать и подключить к AssetManager кастомный загрузчик изображений
  • Поддержка текстур формата KTX. Полноценная поддержка KTX1 и KTX2. Текстуры, сжатые в Basis Universal, транскодируются в S3TC/RGTC/BPTC или распаковываются в RGBA8, в зависимости от заданной пользователем настройки. Поскольку для этого требуется дополнительная библиотека, за загрузку KTX отвечает расширение dagon:ktx
  • Расширение dagon:physfs, которое позволяет примонтировать в AssetManager виртуальную файловую систему PhysFS и загружать ассеты из архивов
  • Упрощенные тени в SimpleRenderer: дефолтный шейдер затемняет пиксели в зависимости от удаленности от указанной точки в плоскости XZ, создавая кружочек тени под объектом. Радиус затемнения можно контролировать, чтобы сделать либо мягкий кружок, либо резкий. Центр тени можно привязать, например, к позиции персонажа
  • 4-байтное выравнивание в текстурах, которые загружаются из файла вместе с mip-уровнями
  • Функция isExtensionSupported для проверки поддержки расширений OpenGL. Также maxTextureUnits и maxTextureSize — для опрашивания максимального количества текстурных блоков и максимального размера текстуры.

Полный список изменений читайте на странице релиза.

Обновления

bindbc-wgpu 0.24.0

Обновил биндинг к WebGPU, обеспечив поддержку wgpu-native 24.0. Очень рад внедрению WGPUStringView вместо null-terminated строк — теперь строки в API передаются в виде пары указатель + длина. Это дает прямую совместимость со строками D — не нужно вызывать toStringz, что всегда меня дико раздражало. В моем биндинге WGPUStringView в большинстве случаев неявно создается из string благодаря конвертирующему конструктору this(string).

https://github.com/DLangGamedev/bindbc-wgpu

bindbc-physfs

Написал биндинг к PhysFS, популярной библиотеке для абстрактного доступа к файловой системе и содержимому архивов.

https://github.com/DLangGamedev/bindbc-physfs

Сжатие текстур, часть V. ASTC и Basis Universal

Продолжение серии постов о сжатых текстурных форматах. Предыдущие части: часть I, часть II, часть III, часть IV.

Вот мы и подошли к state of the art текстурного сжатия по состоянию на 2025 год.

ASTC

Adaptive Scalable Texture Compression

Современный формат, созданный с учетом особенностей мобильных платформ. На сегодняшний день крайне мало распространен. Программно поддерживается в Vulkan и новейших версиях OpenGL ES, но аппаратно — далеко не всеми видеокартами. В десктопном OpenGL поддержки нет и, судя по всему, не предвидится (но это не проблема — см. ниже).

В отличие от S3TC, BPTC и RGTC, формат работает с блоками от 4×4 до 12×12. Размер блока ASTC всегда составляет 16 байт, поэтому чем больше блок, тем выше степень сжатия, но ниже качество. Можно выбирать формат блока (например, 5×5, 6×6, 8×8 и т.д.) в зависимости от баланса между качеством и размером. ASTC поддерживает от 1 до 4 каналов.

ASTC поддерживает HDR и является на сегодняшний день единственным универсальным решением для сжатия HDR-текстур на мобильных GPU.

Basis Universal

Использовать ASTC напрямую непрактично, если вы хотите охватить широкий спектр платформ и конфигураций. Для этого была придумана особая система хранения сжатых текстур, которая позволяет приложениям на лету транскодировать их в формат, подходящий для каждой конкретной платформы — ASTC, BPTC, S3TC, RGTC, PVRTC и в несжатые форматы. Basis Universal охватывает как LDR, так и HDR-текстуры в рамках пяти режимов сжатия: ETC1S, UASTC LDR 4×4, UASTC HDR 4×4, UASTC HDR 6×6, UASTC HDR 6×6 intermediate.

ETC1S. Режим низкого и среднего качества, основанный на подмножестве ETC1. Поддерживает переменный баланс веса/качества (наподобие JPEG). Поддерживает альфа-канал. Этот вид текстур можно быстро транскодировать практически в любые другие сжатые форматы.

UASTC (Universal ASTC) LDR 4×4. Подмножество ASTC для стандартных LDR-текстур с 8 битами на канал. Транскодируется также очень эффективно, особенно в ASTC и BC7.

UASTC HDR 4×4. Режим для HDR-текстур, подмножество ASTC HDR 4×4 8bpp. Разработан для обеспечения высокого качества, эффективно транскодируется (с небольшими потерями) в BC6H. В ASTC HDR превращается вообще без какого-либо оверхеда и без потерь. Этот режим также можно транскодировать в различные несжатые HDR-форматы 32-64 bpp.

UASTC HDR 6×6. Режим HDR-текстур 3.56 bpp. Также на 100% эквивалентен ASTC.

UASTC HDR 6×6 Intermediate («GPU Photo»). Быстро транскодирутся в ASTC HDR 6×6, BC6H и различные несжатые HDR-форматы.

ETC1S и UASTC LDR 4×4 могут быть транскодированы в:

  • ASTC LDR 4×4 L/LA/RGB/RGBA 8bpp
  • BC1-5 RGB/RGBA/X/XY
  • BC7 RGB/RGBA
  • ETC1 RGB, ETC2 RGBA, ETC2 EAC R11/RG11
  • PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA
  • ATC RGB/RGBA, FXT1 RGB
  • Несжатые LDR-форматы.

UASTC HDR 4×4 и UASTC HDR 6×6 могут быть транскодированы в:

  • ASTC HDR 4×4 (8bpp, только UASTC HDR 4×4)
  • ASTC HDR 6×6 RGB (3.56bpp, ASTC HDR 6×6 или UASTC HDR 6×6 intermediate)
  • BC6H RGB (8bpp, UASTC HDR 4×4 или UASTC HDR 6×6)
  • Несжатые HDR-форматы.

KTX2 и суперкомпрессия

Basis Universal — это отлично, но как с ним работать и с удобством хранить? Для упрощения этой задачи Khronos Group предложили формат контейнера KTX2, развитие KTX. Если Basis Universal — это механизм сжатия, то KTX2 — чемодан, в который можно упаковать вообще все. Он поддерживает все существующие форматы сжатия, включая ASTC, UASTC, ETC1S, BC1-7, ETC, PVRTC, и сверх того позволяет сжимать текстуры при помощи lossless-алгоритмов (Zstandard, Zlib, BasisLZ). Несжатые форматы, определенные спецификацией Vulkan, также поддерживаются в полной мере. В KTX можно хранить не только 1D-, 2D- и 3D-текстуры, но и кубические карты, mip-уровни и массивы текстур.

Khronos предоставляет набор утилит KTX Software для конвертации изображений в KTX/KTX2, а также для валидации и анализа файлов. Плюс, разумеется, библиотека libktx для декодирования файлов в приложениях — она полностью берет на себя задачу по транскодированию, и на выходе вы получаете текстуру в нужном вам формате, которую остается лишь отправить в графический API.

SDL_Image и загрузчики текстур

Вслед за KTX я решил улучшить в движке ситуацию с поддержкой стандартных форматов изображений. Отныне Dagon загружает текстуры с помощью SDL_Image, если библиотека присутствует, системно или локально. В противном случае используется старый загрузчик на основе dlib.image. Преимуществом такого подхода является гарантированная под Windows поддержка огромного числа форматов, включая современные WebP и AVIF; также автоматически решается застарелая проблема с декодированием прогрессивных JPEG.

А еще одно важное нововведение — механизм расширения этой системы. Теперь, если нужно добавить новый формат текстур, вместо кастомного ассета достаточно написать и зарегистрировать в AssetManager‘е кастомный загрузчик текстур — реализацию абстрактного класса TextureLoader. Он работает почти аналогично ассету, но предназначен для прямого декодирования данных в TextureBuffer.

(далее…)

Chillwave Drive

Значительно обновлена демка физики автомобиля на Dagon, которая отныне называется Chillwave Drive. Трение колес теперь моделируется на чистых силах вместо встроенных джоинтов Newton, что сделало симуляцию более точной и стабильной. При движении используется динамическое трение (продольное и поперечное) на основе формул Pacejka ’98, при остановке — статическое, препятствующее боковому скольжению машины на склоне. Улучшено управление с контроллера, также добавлена новая модель машины и шейдер неба с облаками и сменой дня и ночи.

Скачать готовую сборку демки под Windows можно тут.

Dagon 0.20.0

Вышло небольшое, но важное обновление Dagon. Добавлена поддержка кастомных шейдеров для текстурирующих слоев материала ландшафта — это делает систему невероятно гибкой, так как вы можете рисовать на ландшафте все, что захотите. В качестве примера в движок добавлен шейдер луж (dagon.extra.puddle) с эффектом кругов от дождевых капель. Также появилась поддержка Matcap для фейковых отражений (особенно полезная фича в в SimpleRenderer, где нет честных отражений), поддержка glTF-расширения KHR_materials_emissive_strength, доступ к материалам glTF по именам. Обновлена библиотека Newton под Linux.

В репозитории проекта открыты обсуждения: https://github.com/gecko0307/dagon/discussions

KTX в Dagon

Наконец-то реализовал давнюю идею поддержки текстур в формате KTX (Khronos Texture). Это контейнер, специально созданный для OpenGL и Vulkan и поддерживающий большое количество форматов текстур, включая сжатые. Особенно интересен KTX2, который позволяет хранить текстуры в формате Basis Universal — он хорош тем, что позволяет при создании игровых ресурсов не волноваться, что сжатие не будет поддерживаться на системах каких-то пользователей. Формат сжатия выбирается движком игры на основе информации от видеодрайвера, а затем текстура на лету транскодируется в этот формат. Эта фича нужна главным образом на мобильных платформах, но и в десктопном движке не помешает — Basis Universal сжимает очень эффективно и транскодируется в S3TC или BPTC за считанные мгновения.

Текстура KTX1/KTX2 загружается в объект KTXAsset, при его создании необходимо указать приоритет транскодирования. Если это TranscodePriority.Size, то загрузчик отдает предпочтение S3TC, если TranscodePriority.Quality — BPTC (при наличии поддержки). Также можно использовать TranscodePriority.Uncompressed, чтобы получить наилучшее качество — текстура будет распакована в RGBA8.

Пример:

TextureAsset aTextureBox;
TextureAsset aTextureEnvmap;

// В конструкторе сцены:

registerKTXLoader(assetManager);

// На стадии запроса ассетов:

aTextureBox = addTextureAsset("data/box.ktx2");
aTextureBox.conversion.hint = TranscodeHint.Size;

aTextureEnvmap = addTextureAsset("data/cubemap.ktx2");
aTextureEnvmap.conversion.hint = TranscodeHint.Quality;

// При создании материалов:

material.baseColorTexture = aTextureBox.texture;
environment.ambientMap = aTextureEnvmap.texture;

Обновления

dlib 1.3.1

Вышло небольшое обновление dlib 1.3, в котором исправлена совместимость с отличными от x86 платформами.

BindBC-SPIRVCross

Написал D-биндинг к SPIRV-Cross, тулкиту для работы со SPIR-V. Теперь потенциально можно создать продвинутый фреймвок компиляции шейдеров — например, систему автоматической адаптации шейдеров к разным графическим API в одном приложении. Пригодится, когда я буду переходить на WebGPU.

dcore

Библиотека dcore, на основе которой я собираюсь писать вторую версию dlib, будет развиваться в качестве самостоятельного проекта: https://github.com/DLangGamedev/dcore. В связи с этим я решил создать организацию DLangGamedev, в которую перевел все BindBC-биндинги библиотек для разработки игр:

LDC поддерживает SPIR-V!

Не секрет, что компилятор LDC, благодаря бэкенду на LLVM, поддерживает множество разных целевых платформ — и в их числе, оказывается, есть SPIR-V. Мне удалось собрать вот такое минимальное вычислительное ядро (которое, правда, ничего не делает):

module main;

import ldc.attributes;

@callingConvention("spir_kernel")
@llvmAttr("hlsl.shader", "compute")
extern(C) void compute_main() nothrow @nogc
{
    //
}
ldc2 -betterC -vgc -c --output-o -of=main.spv --mtriple=spirv-unknown-vulkan -mattr=+spirv1.0 source/main.d

Если вывести ассемблерный листинг, получается следующее:

OpCapability Shader
OpMemoryModel Logical GLSL450
OpEntryPoint GLCompute %3 "compute_main"
OpSource Unknown 0
OpName %3 "compute_main"
%1 = OpTypeVoid
%2 = OpTypeFunction %1
%3 = OpFunction %1 None %2
%4 = OpLabel
OpReturn
OpFunctionEnd

Как видно, можно использовать этот SPIR-V модуль как вычислительный шейдер в Vulkan и OpenGL 4.6. Поддержки других видов шейдеров пока нет, но кто знает — может быть в один прекрасный день получится использовать D в качестве полноценного шейдерного языка! Я лично в это верю.