Cook 1.9.1

Небольшое обновление Cook до версии 1.9.1. Доступны бинарные пакеты для Windows и Linux.

http://code.google.com/p/cook-build-automation-tool/downloads/list

Сборка Atrium из исходников стала проще

Исходный код в репозитории Atrium на GitHub теперь сопровождается инструментарием для сборки: программой Cook и файлами конфигурации для использования DMD (по умолчанию) и LDC. Для сборки проекта необходимо лишь изменить под себя пути к исполняемым файлам компилятора в файлах конфигурации (default.conf или ldc-linux.conf). Подробнее об этом читайте в файле INSTALL.

Atrium на GitHub

Открыл для исходников Atrium репозиторий на GitHub:
https://github.com/gecko0307/atrium.

Atrium: сборка для Linux

Прошу тестировать движок Atrium на Linux. Бинарник, кстати, собран LDC 0.10.0.

atrium-testbuild2-linux-glibc28-x86.tar.bz2 (4.0 МБ)

Эффект затенения

«Честные» динамические тени в аркадных 3D-играх не всегда бывают уместны. Как правило, разработчики ограничиваются статическими предрассчитанными тенями от неподвижных объектов и простым темным кружочком на земле под персонажем – дешево и сердито =) 

Я решил дополнить этот нехитрый метод одной простой, но важной деталью: изменение яркости персонажа в зависимости от его местоположения – в тени или на свету. 

Цвет для яркости будет считываться из карты освещения, в которой «запечены» все статические тени на карте.

Допустим, у вас есть некий блок кода, в котором вы находите точку на поверхности полигона под ногами персонажа:

// Проверяем факт пересечения
IntrStatus istatus = character.downRay.intersectTriangle(tri);
if (istatus.hit)
{
  // Извлекаем точку пересечения
  Vector3f ipt = istatus.intersectionPoint;  
  
  if (ipt.y > currentFloorHeight)
  {
    currentFloorHeight = ipt.y;
    
    // Берем материал полигона
    Material mat = materialByIndex[tri.matIndex];
    
    // Если нет карты освещения (текстура 1), то ничего не делаем
    if (mat.textures[1])
    {
      // Берем изображение карты освещения
      Image lightmap = imageByIndex[mat.textures[1].imgIndex];
      
      // Находим текстурные координаты точки пересечения
      Vector2f tc = triObjSpaceToTexSpace(tri.vertices, tri.texCoords2, ipt);
      
      // Конвертируем текстурные координаты в дискретные
      uint imgX = cast(uint)(tc.x * lightmap.width - 0.5f);
      uint imgY = cast(uint)(tc.y * lightmap.height - 0.5f);
      
      // Считываем цвет пикселя c карты освещения
      Color lumel = lightmap[imgX, imgY];
      
      // Применяем полученный цвет к материалу персонажа
      chMaterial.ambientColor = lumel;
      chMaterial.diffuseColor = lumel;
      chMaterial.specularColor = lumel;
    }
  }
}

Осталось определить функцию triObjSpaceToTexSpace. Она будет использовать барицентрические координаты:

Vector2f triObjSpaceToTexSpace(
  Vector3f[3] vertices, 
  Vector2f[3] texCoords, 
  Vector3f point)
{ 
  Vector3f v0 = vertices[2] - vertices[0];
  Vector3f v1 = vertices[1] - vertices[0];
  Vector3f v2 = point - vertices[0];

  float dot00 = dot(v0, v0);
  float dot01 = dot(v0, v1);
  float dot02 = dot(v0, v2);
  float dot11 = dot(v1, v1);
  float dot12 = dot(v1, v2);

  float invDenom = 1.0f / (dot00 * dot11 - dot01 * dot01);
  float u = (dot11 * dot02 - dot01 * dot12) * invDenom;
  float v = (dot00 * dot12 - dot01 * dot02) * invDenom;
      
  Vector2f t2 = texCoords[1] - texCoords[0];
  Vector2f t1 = texCoords[2] - texCoords[0];

  return texCoords[0] + t1 * u + t2 * v;
}

Atrium собирается последней версией LDC

Совсем недавно вышла бета-версия готовящегося к релизу LDC 0.10.0 - компилятора D, использующего LLVM для генерации машинного кода.

Решив проверить LDC на практике, я только что собрал им Atrium. Результат очень обрадовал, при компиляции в релизном режиме и с уровнем оптимизаций -O3, LDC выдал весьма шустрый код: ~100 FPS против ~80 у DMD 2.060! При этом я всего один раз столкнулся с необходимостью поправить исходники - при использовании ассоциативного массива указателей.

Как вывод: LDC вполне созрел для использовании в качестве основного компилятора D под Linux - во всяком случае, для работы с OpenGL и графикой реального времени. К сожалению, я не в курсе, как у него обстоят дела c поддержкой Windows - надеюсь, со временем этот вопрос устаканится. 

Atrium Project

Доступна первая играбельная сборка моего текущего проекта под кодовым названием Atrium. На данный момент идет отладка графического движка игры, а также работа над экспортером контента для Blender. Данная сборка демонстрирует не столько геймплей, сколько возможности движка в его текущем состоянии, как то: скелетная анимация персонажа, обнаружение столкновений с картой и игровыми объектами, камера от третьего лица, вывод текста,  мультитекстурирование (для реализации лайтмаппинга), а также элементы игровой логики и несложные спецэффекты (свечение объектов, затемнение персонажа, когда он находится в тени).

Управление: 

- клавиши-стрелки = движение вперед/назад и поворот;

- пробел = прыжок

- F11 = переключение привязки камеры к персонажу (в "свободном" режиме камера управляется при помощи мыши: левая кнопка = вращение, средняя = перемещение, колесико = приближение/отдаление).

Скачать:

Для Win32 (3.5 МБ)

Мои старые игры

Решил вспомнить былое и централизованно выложить в открытый доступ свои старые игры. Возможно, кого-то они заинтересуют - сейчас мода на ретро =)
Все ресурсы и исходники - под Public Domain, за исключением чужого контента (лицензионные оговорки - в тексте COPYING.txt)

Crematorium
Игра была сделана мной для II конкурса портала GameCreating.ru (сам сайт давно уже прекратил существование, но сообщество еще живо: http://gamecreating.borda.ru). Конкурс проводился в 2005 году. Кому интересно - тред с голосованием.
Представляет собой несложный шутер от первого лица в стиле первых Doom и Quake. Спрайтовые враги и оружие на фоне трехмерных одноэтажных локаций - подземных лабиринтов. В игре всего 5 уровней, (в начале каждого выводится краткий инструктаж с миссией), 3 типа оружия (пистолет, автомат, гранаты), 2 вида врагов + 1 финальный босс.
Скачать (Google Диск) - 8.3 МБ.

City Builder
Симулятор градостроительства. Каждый построенный жилой дом увеличивает население вашего города, которое ежемесячно платит налог в казну. Размер налога зависит от степени развития городской инфраструктуры: количества магазинов, ресторанов, банков, отелей, садово-парковых зон и т.д. Можно строить заводы, которые ухудшают условия жизни в городе, но зато приносят высокий доход, а также сажать деревья, прокладывать асфальт, газон, песок и воду.
Есть возможность сохранять и загружать города, а также выбирать фоновую музыку.
Скачать (Google Диск) - 1.3 МБ. 

Croggler
Простенький платформер из 15 уровней, на каждом из которых вы должны победить черного призрака, летающего под потолком. Ваше единственное оружие - бомбы, которые призрак время от времени скидывает. Если бомбу вовремя не подобрать, она взрывается. На некоторых уровнях есть также второстепенные враги - их уничтожить невозможно, остается только уворачиваться...
Скачать (Google Диск) - 1.4 МБ.

Blender 2.65 test build

Сегодня стала доступна первая тестовая сборка ожидаемого релиза Blender 2.65. В данной версии пакета пользователей ждет значительное число серьезных нововведений:

•  Наконец-то появилась долгожданная поддержка Open Shading Language (OSL) - нового языка программирования шейдеров от Sony Pictures. Теперь рендер-движок Cycles является полностью программируемым в прямом смысле этого слова: материалы можно описывать не только в виде графа узлов, но и шейдерных программ в духе традиционных GLSL или RSL. К сожалению, OSL-шейдеры пока не компилируются для GPU и работают только в CPU-режиме - однако скорость исполнения байт-кода OSL и без того поражает воображение...
• Для Cycles также добавлена поддержка анизотропных материалов и размытия при движении (Motion Blur).
• Подвергся серьезному обновлению симулятор дыма: теперь он "из коробки" поддерживает симуляцию огня. Объект Domain работает на порядок быстрее. Дым теперь можно выпускать с поверхности мешей без использования системы частиц.
• Новинки в сфере моделирования: улучшенный инструмент "Фаска" (Bevel) и невероятно полезный новый инструмент "Симметризация" (Symmetrize), позволяющий, как ясно из названия, симметризировать топологию относительно координатных осей. Кроме того, был улучшен модификатор Decimate, позволяющий уменьшить количество полигонов в меше - появились новые алгоритмы редуцирования. Также был добавлен новый модификатор Triangulate, "на лету" упрощающий N-гоны до треугольников.

Более подробный обзор новинок ждите в следующем номере журнала "FPS".
Скачать сборку Blender 2.65 для Windows, Linux и Mac OS X можно здесь.

Генеалогическое древо языков

Схема, иллюстрирующая развитие языков программирования:

Журнал "FPS" №21

Вышел 21 номер электронного PDF-журнала "FPS", посвященного разработке игр, программированию, компьютерной графике и звуку. В этом номере можно отметить следующие материалы:

> Blender: обзор дополнений (выпуск 3)
> Tears of Steel: роботы тоже плачут...
> Эффект "старинного фото" в GIMP
> Журнал GIMP Magazine
> Язык D: новости
> Семь мифов о D
> Сборщик мусора - враг или друг?
> Юникод в OpenGL. Раз и навсегда
> Почему я выбираю Linux?
> Патентные войны

Номер доступен для онлайн-чтения и загрузки на сервисе Issuu.com и Документах Google. Последние новости по проекту вы можете узнать в публичной странице журнала в социальной сети Google+.

Почему я выбираю Linux?

Последние два года часто приходится слышать о том, что Linux на десктопах «не выстрелил». И что место его – в нише серверов, суперкомпьютеров, встраиваемых систем и мобильных устройств (в качестве Android, MeeGo и др). Не хочется сейчас касаться бессмысленных холиваров а ля «под Линукс нету Фотошопа» – я не буду оправдывать систему перед геймерами, домохозяйками, «офисным планктоном» и прочим подобным контингентом, равно как и агитировать кого-либо переходить на нее. Я просто намерен объяснить, что именно в Linux привлекает среднестатистического хакера – компьютерного энтузиаста-«кулибина», которого, как это ни парадоксально, интересует не наличие прикладного софта, а именно его отсутствие – чтобы был стимул написать свой! В моем случае – отсутствие игр (малый ассортимент, если быть точным). Именно этот факт послужил первой причиной выбора Linux в качестве основной целевой платформы разработки.

Под Linux мало игр – следовательно, высока вероятность, что ваш проект будет оценен по достоинству и получит свою долю популярности. Сравните это с рынком Windows, который настолько перенасыщен, что у «новоприбывших» практически нет никаких шансов – конкуренция слишком высока. Это, конечно, не значит что качественные инди-проекты остаются совсем незамеченными (вспомните историю той же Portal), но факт остается фактом: мир Windows диктует свои правила, и не все в нем способны выжить. Кстати, это относится не только к играм...

В то же время, было бы некорректно утверждать, что мир Linux не диктует никаких правил. Диктует, и еще как. Это вселенная OpenSource, и вам придется так или иначе отдать дань сообществу СПО за то, что пользуетесь свободными программами в своей работе. Неважно, каким именно способом – открытием своих исходников, вкладом в другие открытые проекты, материальным пожертвованием и т. д. Разумеется, это правило неписанное, оно не значится в лицензионных соглашениях. Это скорее этический принцип. Всякий, кто приходит в этот мир, впечатлившись идеалами свободы, горит желанием стать частью движения, чтобы выразить свою благодарность сообществу. И, на мой взгляд, создание свободного игрового проекта – один из лучших способов сделать это.

Поскольку Linux создавался «программистами для программистов», в нем все ориентировано, в первую очередь, на разработку новых и совершенствование существующих инструментов. К примеру, почти все дистрибутивы идут в комлекте с компилятором GCC и рантаймом языка Python – пользователь может запросто, сразу после установки, начать программировать. Сравните это с Windows, где для написания даже простейшего «Hello, World» нужно устанавливать навороченные IDE – часто платные и весьма требовательные к ресурсам. Конечно, можно и в Windows обустроить себе уютное linux-like окружение: установить MinGW или другой набор свободных компиляторов, Posix-утилиты, все необходимые библиотеки – многие так и делают, особенно если нужен кроссплатформенный toolchain. Суть в том, что в Linux этот набор инструментов присутствует изначально. Linux дружественен к разработчику: это заметно везде, в любых мелочах. Вплоть до того, что все линуксовые текстовые редакторы, даже самые простые, поддерживают подсветку синтаксиса.

Есть еще один момент: по очевидным причинам, в Linux доступен только один трехмерный API – OpenGL. В среде программистов бытует устойчивое «суеверие», касающееся интерфейсов разработки 3D-приложений: о том, что для игр больше подходит DirectX, а ниша OpenGL – САПР, промышленная визуализация и научно-исследовательское моделирование. Это происходит из-за дилетантской попытки сравнивать OpenGL именно с DirectX, а не Direct3D. Как известно, DirectX – это не только трехмерная и двумерная графика, но и звук, сеть, взаимодействие с устройствами ввода, библиотеки вспомогательных функций и многое другое. Более корректное сравнение выглядит следующим образом: DirectX vs OpenGL+OpenAL+SDL+FreeType. А это уже, согласитесь, внушительный «арсенал». Причем, доступный не только под Windows и Linux, но и ряд других платформ. А кто станет спорить с тем, что кроссплатформеность – это хорошо?OpenGL в наши дни не просто идеально подходит для разработки игр – на мобильных платформах это и вовсе единственный выбор. Хотите поддержки Android или iOS? Можете забыть о Direct3D. OpenGL – ваш лучший друг.

Разумеется, нельзя забывать о том, что на программировании свет клином не сошелся. Нужны еще средства подготовки контента. Здесь опять на ум приходит вопрос «фотошопов» и «3ds max'ов», но, положа руку на сердце, скажите – неужели для создания моделей, текстур и спрайтов вам недостаточно Blender, GIMP, Inkscape и MyPaint? Photoshop всегда был и остается инструментом фотографов и специалистов по печати, а 3ds max – архитекторов и дизайнеров по интерьерам. Использование этих дорогих и тяжеловесных «монстров» для работы с маленькими изображениями и низкополигональными моделями явно неоправдано. Выходит, в миграции на оупенсорс художникам мешает только консерватизм и сила привычки.

Было бы несправедливо обойти стороной объективные недостатки Linux как десктопной игровой платформы. Если отставить в сторону всякие мифы, суеверия, психологические барьеры, тролль-аргументы вроде «1 процента», остается, на мой взгляд, всего два пункта:

1. Пресловутый «зоопарк дистрибутивов». Даже в рамках одного дистрибутива не так-то просто добиться идеальной совместимости бинарных релизов со всеми версиями ОС – что и говорить о десятках (!) разных операционок... Можно, конечно, нацелиться только на один популярный дистрибутив – скажем, на ту же Ubuntu – и говорить, что все остальное официально не поддерживается. Но это не в духе Linux, за такое пользователи вас добрым словом не помянут. Если ваша игра распространяется по свободной лицензии, можно посылать всех самостоятельно компилировать ее из исходников. Есть и третий вариант – как мне кажется, наиболее вменяемый: официально выпускать один универсальный бинарный релиз, собранный для старой версии Glibc (скажем, 2.7) и имеющий минимум зависимостей, а индивидуальные пакеты для всех популярных дистров поддерживать на базе сообщества. Так делают, например, разработчики Blender. И на протяжении 10 лет у них это успешно получается.

2. Ситуация с видеодрайверами. Производители видеокарт все еще ориентируются, в основном, на Windows. Драйверы для всего остального обычно запаздывают с выходом и уступают по качеству. Но поддержка Linuх не так плоха, как могла бы быть. Если у вас видеокарта от NVIDIA или Intel, можно радоваться, но ситуация с AMD значительно хуже...

Как видите, оба пункта отнюдь не смертельны и для большинства линуксоидов совершенно не критичны. Думаю, излишне упоминать о стабильности, надежности и безопасности Linux-систем, и в качестве хост-системы для различных разработок и экспериментов они не имеют равных.

Передискретизация в dlib.image

Передискретизация (ресэмплинг) изображения - это всего-навсего изменение его разрешения в пикселях. Такую функцию должна включать любая уважающая себя библиотека обработки изображений, и с сегодняшнего дня dlib - не исключение. В пакете dlib.image.resampling доступны четыре алгоритма ресэмплинга, которые часто встречаются в графических редакторах: линейная интерполяция (Linear или Nearest Neighbor), билинейная (Bilinear), бикубическая (Bicubic) и фильтр Ланцоша (Lanczos). Ниже представлены результаты их работы на примере увеличения разрешения картинки с 64х64 до 256х256.

Оригинал







Linear
Самый простой и, следовательно, самый быстрый способ изменить размеры изображения. Известен также как интерполяция методом ближайшего соседа (Nearest Neighbor). Для промежуточных пикселей выбирается ближайшее известное значение.

Bilinear
Для получения промежуточного значения производится линейная интерполяция между четырьмя ближайшими пикселями. Это позволяет несколько сгладить переходы. Билинейный фильтр - неплохой компромисс между скоростью и качеством результата.

Bicubic
Промежуточные значения вычисляются путем свертки ядра 4x4 специальной бикубической функцией. Достаточно медленный алгоритм, но зато дает наименее пикселизированный результат.

Lanczos
У бикубической интерполяции есть недостаток - изображение получается несколько размытым. Чтобы сохранить четкость, можно воспользоваться фильтром Ланцоша. Он немного увеличивает пикселизацию, но создает контрастные области вдоль контуров для повышения четкости. В моей реализации я использовал ядро 7х7. Очень медленно, зато качественно.

Существуют и другие алгоритмы - постепенно они тоже будут добавлены в библиотеку.
Изменения доступны в dlib ревизии r5 и выше.

Начать - наполовину сделать

В этом блоге я буду публиковать свой прогресс в области разработки 3D-игр на языке программирования D с использованием OpenGL. Хочу предупредить - ничего определенного я не обещаю, геймдев для меня - всего лишь хобби. Я не из тех, кто ставит перед собой заведомо недостижимые цели - мне нравится сам процесс =)