Демки Dagon переместились в отдельный репозиторий: https://github.com/gecko0307/dagon-demo. Теперь это всего одно приложение, включающее несколько сцен и меню для переключения между ними. Появилась новая демка с реализацией системы частиц, которая, надеюсь, скоро станет частью движка. Система включает очень быстрый отрисовщик биллбордов для частиц, поддерживает стандартные векторные поля (аттрактор, дефлектор, «черная дыра», вихрь) и позволяет добавлять новые.
d
Идеальный язык — это миф
Прошло семь лет с тех пор, как я опубликовал свою первую статью о языке D в журнале «FPS» (№12 за 2010 г.). Первоначальный восторг и энтузиазм за это время, конечно, поугас, но в целом мое отношение к языку не поменялось, я все еще остаюсь убежденным дишником — ничего лучше D я пока не вижу. Но я отнюдь не считаю D идеальным языком. За эти годы у меня накопилось много соображений по этому поводу, которыми сейчас и хочу поделиться.
Есть популярное мнение, что программисты СПО не должны распылять усилия на персональные проекты и разрабатывать только один, чтобы получился идеальный инструмент. Отчасти это мнение распространяется и на языки — кого-то раздражает «зоопарк» языков, среди которых, мол, нет однозначно лучшего. Так вот, идеальный язык программирования — это нонсенс, он не может существовать. По той простой причине, что языки — это инструменты, предназначенные для решения определенных задач. Немыслим такой инструмент, который решал бы все возможные задачи. Более того, по мере развития информационных технологий появляются новые задачи, для решения которых создаются новые инструменты. И это нормально, так было всегда. Чем больше языков, тем лучше — те, кто считает иначе, гонятся за иллюзией.
Можно выразить это через биологическую аналогию. Языки (и вообще все свободные программы) существуют в некоем подобии экосистемы, и к ним отчасти применимы законы естественного отбора. Выживают наиболее приспособленные — в данном случае, приспособленные к решению определенного набора задач. Схожие задачи объединяют языки в «ареалы обитания», где они конкурируют друг с другом. Подобно живым организмам, языки в принципе не способны охватить все ареалы — нет существ, которые были бы одинаково хорошо приспособлены к жизни в пустыне, в тропиках, в арктических льдах и в океане.
Поэтому мне всегда казалась нелепой тенденция учить один-единственный язык, чтобы затем использовать его для любых целей. Если язык пригоден для решения вашей задачи — используйте, если нет — берите более подходящий.
Когда люди спрашивают что-то вроде: «Почему D непопулярен несмотря на то, что он такой идеальный?» — некорректна сама постановка вопроса. D — неидеальный язык. И C++ неидеальный, и Java, и Python, и все остальные. D спроектирован лучше, чем C++, Java или Python — но этот факт сам по себе не означает, что D решает все задачи однозначно лучше, чем C++, Java или Python.
Практическая ценность языка вообще мало коррелирует с его дизайнерскими достоинствами. D — очень красивый язык, вобравший в себя множество потрясающих архитектурных решений. На D можно писать образцово эффективный и читаемый код. Но это дизайнерское достоинство, которое сделало бы D идеальным языком только в идеальном мире, где нет необходимости линковаться с библиотеками на C++, взаимодействовать с морально устаревшими API типа Win32, писать клиентский код под браузеры, разрабатывать мобильные приложения под Android с его урезанным libc и отсутствием полной поддержки Posix. Список можно продолжать бесконечно: мир IT — это архитектурный хаос. Есть хорошо продуманные стандарты, ставшие популярными, но они теряются на фоне нагромождения разнородных поделок, «склеенных скотчем», наспех написанных по принципу «лишь бы работало».
Популярными становятся те инструменты, которые помогают уживаться со всем этим, не стремясь быть «вещью в себе». Есть инструменты, безупречные с точки зрения дизайна, но совершенно бесполезные на практике — например, язык Haskell или ОС Plan 9. Это классические примеры «вещей в себе», интересные лишь в эстетическом отношении. На практике никто не использует красивые языки и красивые операционные системы только из-за их красоты. В этом причина популярности Windows и C++. Никто не говорит, что они идеальны, но все ими пользуются — потому что они решают задачи большинства.
Но вернемся к D. Решает ли он какие-то задачи лучше, чем C++? Если да, то почему непопулярен? Это непростой вопрос, на который, наверное, нельзя ответить однозначно, но я попробую.
Я не раз сталкивался с необходимостью написать небольшую утилиту, эффективно выполняющую одну-единственную задачу. Например, сортировщик файлов, переименовывающий их в определенной последовательности. На D без дополнительных библиотек написать такое намного проще, чем на C++ без дополнительных библиотек. И работать оно будет значительно быстрее, чем, скажем, вариант на Python или Bash (и я бы еще поспорил, что проще — Bash или D).
D позволяет без особых телодвижений взять и реализовать с нуля любую идею — в этом его главная практическая ценность. Конечно, без библиотек это не всегда так просто, поэтому я и начал проект dlib — это, в первую очередь, именно библиотека для прототипирования. Суть в том, что D как язык располагает к быстрому воплощению идей, при этом предоставляя нужную производительность — с D не требуется переписывать прототип на язык с более низким уровнем абстракции, прототип с минимальными трудозатратами превращается в законченный продукт.
Может ли D конкурировать с C++ на вышеупомянутом хаотическом поприще? Да, но только при создании нового. Нет смысла писать на нем, если ваш код будет мешаниной из библиотечных вызовов, C-шных идиом и разных костылей типа toStringz. В таком случае вы просто усложните себе жизнь — намного проще использовать C++. D — это язык не для рутины, а для творчества. И в этом у него нет конкурентов.
Вопрос в том, насколько много программистов сейчас занимаются чистым творчеством. По моим впечатлениям, большинство pet-проектов на GitHub — это какие-то мелкие веб-приложения, разного рода «хеллоуворлды», бессмысленные порты с одного языка на другой, какие-то врапперы и биндинги. Серьезные открытые проекты давно переросли стадию чьего-то хобби — творчеством там, конечно, и не пахнет. Даже на D чего-то нового и интересного не так уж много, и это меня искренне расстраивает. Был легендарный h3r3tic с его потрясающими программными растеризаторами и трассировщиками лучей времени компиляции. Была Higgs, JavaScript-машина с JIT-компиляцией. Был игровой движок Dash. Была пара-тройка мини-игр. И это, по большому счету, все. Сейчас репозиторий DUB забит какими-то унылыми библиотеками для веба, драйверами СУБД и реализациями малоизвестных протоколов. Скучно, ребята, скучно. На D можно писать удивительные штуки — почему никто этого не делает?
DMD полностью свободен!
Долгое время бэкенд распространялся по несвободной лицензии, оставляя исключительное право на распространение кода за правообладателем (компанией Symantec) — для распространения кода лицензиатом требовалось получить явное разрешение, что формально делало бэкенд прориетарным при открытых исходниках. Данный нелицеприятный факт долгое время служил еще одной антирекламой D, и, хотя де-факто все игнорировали лицензию бэкенда и спокойно форкали DMD на Гитхабе, несвободная лицензия ограничивала возможность включения бинарников DMD в стандартные репозитории Linux-дистрибутивов. Наверное, в некоторой степени это и сделало язык менее популярным, чем Go, Rust и другие новинки последних лет (да, есть изначально свободные LDC и GDC, но они всегда отставали на несколько релизов, к тому же играет роль психологический фактор — к референсной реализации всегда больше доверия). Надеюсь, теперь ситуация начнет меняться, если еще не слишком поздно — из реальных, ненадуманных недостатков D остается только сборщик мусора.
Фокусы с Compound
Недавно столкнулся с интересной задачей: описанием класса, который инкапсулирует неизвестный заранее набор объектов. Типы этих объектов задаются через variadic template – то есть, шаблон с переменным количеством параметров. Статические массивы для этой задачи, ясное дело, не годятся, но тут идеально подошел Compound из dlib.core.compound. Это своеобразный “гибрид” кортежа и структуры – составной тип данных, который можно создавать в шаблонах. Ему можно передавать кортеж параметров variadic-шаблона, и это позволяет проделывать замечательные вещи.
class Collection(C...)
{
protected Compound!C _components;
this(C comps)
{
_components = comps;
}
}
auto inc = new Collection!(int, char, bool)(10, 'a', false);
Проблема с обычными кортежами (Tuple) в том, что их нельзя возвращать из функции. Но Compound – можно. Таким образом, для ридонли-доступа к _components мы можем объявить следующий метод:
auto components() @property
{
return _components;
}
А еще мы можем заполнять Compound в цикле, читая значения, например, из массива:
this(int[] arr)
{
foreach(i, T; C)
{
_components[i] = cast(T)arr[i];
}
}
auto inc = new Collection!(int, char, bool)([5, 40, 0]);
Пример бессмысленный, но наглядный – мы проходим по всем типам кортежа C и записываем входное значение в наш Compound, конвертируя в нужный тип. Без дополнительных проверок это небезопасно, но если вы знаете, что делаете – очень полезно.
Dagon
Те, кто следит за моей активностью на GitHub, могли заметить, что у меня появился новый репозиторий dagon — проект, который позиционируется как новая эволюционная ступень DGL. В процессе работы над Atrium я пришел к выводу, что в движке не хватает средств автоматизации некоторых рутинных задач. Например, управление памятью в типичном игровом приложении может быть почти полностью автоматизировано, поскольку выделение и высвобождение памяти происходит в специально задуманных паузах, таких как переключение между локациями (это не относится к играм с открытым миром с фоновой подгрузкой, но это уже специфический случай). Кроме того, в обсуждении на Reddit звучал вопрос, почему DGL не использует SDL2. Так родилась новая ветка движка, которую я решил сделать отдельным экспериментальным проектом.
На сегодняшний день Dagon включает следующие возможности:
- Использование SDL2
- Новая модель памяти на основе концепции владельца (owner), позаимствованной из Delphi
- Модель образцов и компонентов (entity-component), позволяющая расширять функциональность объектов динамически, без наследования классов
- Динамическая перезагрузка ресурсов при их модификации сторонним приложением без перезапуска игры
- Поддержка форматов OBJ и IQM
- Поддержка текстур PNG, JPG, TGA, BMP
- Поддержка контейнера Box для ресурсов
- Новая система материалов с разделением на фронтенд (набор параметров) и бэкенд (передатчик параметров графическому конвейеру — фиксированному или шейдерному, в зависимости от выбранной реализации бэкенда). Система позволяет использовать как стандартные материалы с известным набором параметров, так и создавать свои, специализированные
- Некоторые компоненты, напрямую портированные из DGL — например, система событий, система освещения, рендеринг текста.
Анимация в dlib
Меня внезапно осенило, как можно добавить в dlib.image поддержку анимации без существенного рефакторинга библиотеки. Классы анимированных изображений (SuperAnimatedImage) могут быть простым расширением базового класса SuperImage с возможностью хранить несколько кадров и переключаться между ними. Такие изображения полностью совместимы с любым кодом, работающим с SuperImage – чтению и записи через привычный интерфейс SuperImage подлежит срез данных, относящийся к текущему кадру.
Также естественным образом вводится класс-фабрика для создания анимированных изображений, и в результате стало возможным расширить декодер PNG до поддержки APNG:
AnimatedImageFactory imgFac = new AnimatedImageFactory;
auto res = loadPNG(openForInput("animation.apng"), imgFac);
if (res[0])
{
SuperAnimatedImage animImg = cast(SuperAnimatedImage)res[0];
}
Компиляторы D в Travis
Итоги 2016 года
- Графический движок DGL был значительно отрефакторен и улучшен, был создан более эффективный формат для хранения сцен и реализованы различные новые техники рендеринга, самой интересной из которых является PBR. Движок стал работать намного быстрее, а картинка стала заметно современнее.
- Вышли подряд две новые версии коллекции библиотек dlib — 0.8 и 0.9.
- Вышло 6 номеров электронного журнала «FPS» (№№ 40, 41, 42, 43, 44, 45). В 2017 году журналу исполняется 9 лет.
- На сайте LightHouse Software вышли две мои статьи по D — «Стеганография в dlib» и «dlib.image и OpenCL». Также Atrium и сопутствующие проекты привлекли внимание авторов Блога D, где был опубликован соответствующий отчет на английском.
- Я довел до ума и выложил трассировщик лучей и программный растеризатор, написанные на D, а, кроме того, все-таки доделал свой старый проект — Xtreme3D 3.0.
- Выход LunarG SDK, комплекта разработки под Vulkan. Одновременно появились и Vulkan-биндинги для разных языков, в числе которых и D. Поддержкой нового API постепенно обрастают и ведущие игровые движки.
- Открытие исходников CryEngine 5.
- Выход Krita 3.0 с поддержкой анимации.
- Переход Blender на OpenGL 2.1 для отрисовки интерфейса. Запускать последние версии Blender на своих старых ноутбуках я теперь не могу — а жаль…
- Появление Armory3D, альтернативного игрового движка для Blender — очень перспективный проект, картинкой и списком поддерживаемых платформ оставляет BGE далеко позади.
- Выход Doom 4. Покупать, правда, не стал, скачал на Steam бесплатную демо-версию. Чтобы запустить, пришлось немного пошаманить с настройками, но, в целом, остался доволен. Особенно порадовала пасхалка в виде комнаты с текстурами из классического Дума =)
Трассировщик лучей на D
Рендерит не очень быстро, код не слишком оптимизирован (упор делался, в основном, на простоту и наглядность исходников). Основная оптимизация заключается в распараллеливании трассировки на несколько потоков, что дает заметный прирост производительности на многоядерных процессорах.
Проект написан на D, для работы с изображениями и математических вычислений использует библиотеку dlib. Исходники умещаются в 400 строк. Лицензия — public domain или CC0, на ваш выбор.
