Статус dlib2

В последнее время редко пишу о dlib, но хочу заверить: разработка библиотеки на месте не стоит, в данный момент я разрабатываю dlib2, а точнее – ее низкоуровневый компонент dcore. dcore – это процедурный API, совместимый с betterC и минимально заменяющий стандартную библиотеку. Он полностью автономный, не зависит от Phobos, поддерживает компиляцию в машинный код под bare metal (то есть, без операционной системы) и в WebAssembly. Он предназначен для создания компактных приложений в стиле C, а также для написания высокоуровневых частей библиотеки на его основе.

Может возникнуть вопрос – для чего это нужно, если есть libc? dcore, конечно, использует стандартные функции C при компиляции в таргеты, которые поддерживают libc. Но все упирается в WebAssembly: своего Emscripten на D не существует. Поэтому, для упрощения написания WASM-модулей, я решил сделать минимальный набор абстракций, которые скрывают платформозависимые реализации самых важных компонентов приложения под универсальным низкоуровневым API. dcore элементарно позволяет использовать printf, malloc и т.д., не задумываясь, доступны ли они на целевой платформе.

Еще один важный момент – математика. Я уже публиковал пост о бенчмарках различных реализаций синуса и косинуса – dcore поддерживает все стандартные математические функции (sin, cos, tan, asin, acos, sqrt, cbrt и др.), предоставляя на каждой платформе оптимальные реализации: LLVM-интринсики, функции C, функции Phobos и кастомные, без зависимостей, предназначенные для нестандартных таргетов.

Из нового:

  • dcore.time – удобный враппер над C-шными localtime и gmtime. Позволяет получать текущую системную время-дату, в текущем часовом поясе или по Гринвичу;
  • dcore.sys – информация о системе: архитектура CPU, количество ядер, объем памяти, название и версия ОС. Модуль поддерживает x86/x64, ARM, ARM64, IA64, MIPS, SPARC, PPC. Информация об ОС поддерживается для всех версий Windows и двух больших семейств Unix – Linux/Solaris/AIX (через sysconf) и BSD/OSX (через sysctl);
  • dcore.process – позволяет кроссплатформенно получить PID.

Мини-проект: радиоуправляемая платформа на Arduino

Пост не имеет отношения к D, но я решил опубликовать его тут, так как тематика относительно близкая.

Arduino я начал изучать год назад. Для непосвященных: это созданный итальянскими инженерами недорогой 8-битный микроконтроллер с распиновкой, очень простой для понимания начинающими, в комплекте с работающим из коробки C-тулчейном, юзер-френдли IDE и инструментарием для прошивки платы по COM-порту. Вообще электрическими схемами я увлекаюсь с самого раннего детства – всегда любил что-то делать своими руками из железного конструктора, проводов и лампочек =) С появлением компьютера это хобби не угасло, хотя до недавних пор и отошло на второй план. Мечту сделать игрушечный радиоуправляемый аппарат я не оставлял много лет – и вот, наконец, сумел воплотить ее в жизнь!

За основу я взял китайский клон Arduino Uno R3 (благо они очень дешевые, можно не жалеть для экспериментов). Я использовал, в основном, прилагавшиеся к плате детали, но пришлось также докупить электромоторы и драйвер L298N. Что удобно, моторы можно купить сразу с колесом – таким образом, остается только укрепить ходовую часть на шасси.

Шасси, за неимением лучшего материала, я сделал из Лего. На этом этапе, как ни странно, я застрял надолго, так как электронные компоненты оказалось очень непросто надежно прикрепить к лего-деталям. Для удобства я докупил лего-совместимый корпус для Arduino, однако толкового способа закрепить моторы я так, к сожалению, и не придумал – в итоге ходовая часть получилась немного расхлябанная, но тем не менее работоспособная.

Отдельной проблемой стало питание. Сначала я думал запитать плату от USB-пауэрбанка, но ничего не вышло: Ардуино работает пару секунд и выключается. Пришлось добавить батарейный отсек на 6 элементов AA (9В). Драйвер моторов запитал параллельно с платой, от разъема VIN (который, в отличие от обычных 5-вольтных разъемов питания, напрямую отдает 9В от адаптера, что очень удобно). Теоретически, для большей надежности можно было бы запитать драйвер полностью независимо от Ардуино, добавив клемму между DC-штекером и платой, но я не стал так заморачиваться.

Драйвер L298N – это ключевой компонент двухмоторной ходовой части. Пара моторов нужна для того, чтобы не делать рулевое управление: для поворота аппарата влево-вправо нужно просто вращать моторы в противположных направлениях. L298N нужен именно для этого. Управление этой штукой осуществляется путем подачи сигналов на командные входы. В качестве remote-контроллера я использовал инфракрасный приемник в паре с комплектным пультом – соответствующая программа получилась очень простой:

#include "IRremote.h"

#define IR_RECEIVE_PIN 7

// IN1, IN2 - motor A
// IN3, IN4 - motor B
#define IN1 2
#define IN2 3
#define IN3 4
#define IN4 5

#define ENA A0
#define ENB A1

int receivedValue;
int buttonPressed = 0;

void setup()
{
    pinMode(IN1, OUTPUT);  //motor A
    pinMode(IN2, OUTPUT);  //motor A
    pinMode(IN3, OUTPUT);  //motor B
    pinMode(IN4, OUTPUT);  //motor B
  
    IrReceiver.begin(IR_RECEIVE_PIN, ENABLE_LED_FEEDBACK);
  
    buttonPressed = 0;
}

void loop()
{
    receivedValue = 0;
    
    if (IrReceiver.decode())
    {
        receivedValue = IrReceiver.decodedIRData.command;
        IrReceiver.resume();
    }
  
    if (receivedValue == 28) // forward
    {
        digitalWrite(IN1, HIGH);
        digitalWrite(IN2, LOW);
        digitalWrite(IN3, LOW);
        digitalWrite(IN4, HIGH);
    }
    else if (receivedValue == 82) // back
    {
        digitalWrite(IN1, LOW);
        digitalWrite(IN2, HIGH);
        digitalWrite(IN3, HIGH);
        digitalWrite(IN4, LOW);
    }
    else if (receivedValue == 8) // left
    {
        digitalWrite(IN1, HIGH);
        digitalWrite(IN2, LOW);
        digitalWrite(IN3, HIGH);
        digitalWrite(IN4, LOW);
    }
    else if (receivedValue == 90) // right
    {
        digitalWrite(IN1, LOW);
        digitalWrite(IN2, HIGH);
        digitalWrite(IN3, LOW);
        digitalWrite(IN4, HIGH);
    }
    else // stop
    {
        digitalWrite(IN1, LOW);
        digitalWrite(IN2, LOW);
        digitalWrite(IN3, LOW);
        digitalWrite(IN4, LOW);
    }
    
    delay(100);
}

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

Dagon 0.19.0

Вышла новая версия движка! Релиз очень большой, все изменения детально описывать в этом посте не буду, перечислю только самое основное. Подробности – на странице релиза.

  • Добавлен модуль dagon.core.persistent – простая БД типа “ключ-значение”, которую можно использовать для управления пользовательскими данными игры, такими как настройки и сохранения;
  • InputManager теперь поддерживает разделенные пробелами имена кодов клавиш в привязках. Вместо пробела используется символ плюса, например, kb_left+ctrl для левого Ctrl;
  • Dagon-приложение теперь устанавливает кодировку консоли на UTF-8 в Windows, чтобы нормально выводился нелатинский текст;
  • Добавлен SimpleRenderer, о котором я уже писал ранее – облегченный рендерер для казуальной и стилизованной графики;
  • Добавлена поддержка бокс-проекции для световых зондов. Ее можно включить с помощью свойства Entity.probeUseBoxProjection. Зонды теперь используют альфа-спад для плавного смешивания с данными в G-буфере – благодаря этой фиче сглаживается граница между интерьерным и уличным освещением. Для управления этим эффектом введено свойство Entity.probeFalloffMargin;
  • Добавлена поддержка ортогональных проекций: свойство RenderView.projection теперь принимает константы Perspective, Ortho и OrthoScreen. RenderView.orthoScale управляет масштабом проекции в режиме Ortho;
  • Добавлен новый примитив – цилиндр ShapeCylinder, а также Billboard (прямоугольник, который всегда направлен в сторону камеры);
  • Материалы теперь поддерживают произвольные преобразования текстур (аффинные матрицы 3×3) благодаря свойству Material.textureTransformation. Метод Material.setSprite(Vector2f uvSize, Vector2f uvPosition) можно использовать для наложения на квады фрагментов текстуры – полезно для рендеринга спрайтов и покадровой анимации;
  • Добавлен новый пакет dagon.collision – базовая система обнаружения столкновений;
  • В контроллере персонажей NewtonCharacterComponent появилась поддержка приседания (метод crouch) и улучшенная проверка земли.

Обновления

Улучшения в Dagon

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

dmech, мой старый физический движок, включает продвинутые алгоритмы проверки столкновений, которые до недавнего времени пропадали зря (в частности, Minkowski Portal Refinement и солвер Джонсона) – я решил исправить этот недочет и добавить их в Dagon в качестве пакета dagon.collision. В данный момент он поддерживает обнаружение пересечений между любыми выпуклыми телами и проверку пересечения выпуклого тела с лучом.

Продолжаю работу над упрощенным рендером, о котором уже писал ранее. Появились билборды и универсальная ортографическая проекция: теперь можно, к примеру, легко сделать изометрическое 3D со спрайтовой графикой, как на скриншоте. Среди прочих улучшений – рефакторинг компонента FreeviewComponent и улучшенный контроллер персонажа Newton (появилась поддержка приседания). Оптимизирован deferred-рендер, сокращено количество переключений кадровых буферов. Добавлен новый встроенный примитив – цилиндр.

BindBC-GLSLang

Написал биндинг к glslang, референсному компилятору GLSL от Khronos – можно генерировать модули SPIR-V для WebGPU-приложений прямо в D, без использования внешнего ПО.

https://github.com/gecko0307/bindbc-glslang

Раздел со статьями

Добавил раздел “Статьи” для быстрого доступа к ним. Там, в основном, написанное за последние 10 лет и доступное онлайн, так как более ранние мои материалы публиковались еще в PDF-версии журнала “FPS” и бумажных изданиях – ссылки на них поставить затруднительно.

std140: статическая валидация структур

std140 – самый платформонезависимый лейаут uniform-блоков. Если вы передаете параметры в шейдер структурами, а не по одному, то лучше использовать именно его. Конечно, у переносимости есть своя цена: стандарт предусматривает несколько ограничений, самое известное из которых – выравнивание по 16 байтам. То есть, все поля структуры должны быть по размеру кратны 16 байтам. Например, если это вектор – то vec4, если матрица – то mat4. Некратные 16 байтам типы (float, int и др.) также можно использовать, но их необходимо выравнивать вручную – то есть, одиночный float пойдет все равно как vec4. Использование невыровненных данных приводит к тому, что в шейдере считываются неправильные значения, и это вызывает недоумение у начинающих.

Благодаря CTFE и статической интроспекции в D можно проверять структуры на соответствие этому правилу на этапе компиляции – все необходимое есть в std.traits:

import std.traits;

bool fieldsAligned(T, alias numBytes)()
{
    static if (is(T == struct))
    {
        alias FieldTypes = Fields!T;
        
        static foreach(FT; FieldTypes)
        {
            static if (FT.sizeof % numBytes != 0)
                return false;
        }
        
        return true;
    }
    else return false;
}

alias Std140Compliant(T) = fieldsAligned!(T, 16);

Теперь можно делать так:

import dlib.math.vector;
import dlib.math.matrix;

struct Uniforms
{
    Matrix4x4f modelViewMatrix;
    Matrix4x4f normalMatrix;
    Vector4f worldPosition;
    float someParameter; // Will not compile, use Vector4f instead
}

static assert(Std140Compliant!Uniforms,
    Uniforms.stringof ~ " does not conform to std140 layout");

Возникает вопрос, почему бы просто не делать align(16)? Можно!

struct AlignedUniforms
{
  align(16):
    float a;
    Vector3f b;
    Matrix4x4f c;
}

Преимуществом такого подхода является право использовать любые типы для полей, но это неэффктивно: например, вместо того, чтобы впустую расходовать три байта после a, можно было бы упаковать a вместе с b в один 16-байтный вектор. Поэтому я лично не фанат автоматического компиляторного выравнивания – лучше это делать вручную, защитившись от ошибок необходимыми статическими проверками.