Брифинг

Игра, которая научила компьютеры притворяться трёхмерными

10 декабря 1993 года маленькая техасская студия id Software выложила в сеть первый эпизод DOOM. Игроку достался морпех на базе Фобоса, а компьютерам того времени — задача, которую они, казалось, не могли решить: рисовать 35 раз в секунду лабиринт с комнатами разной высоты, лестницами, лифтами, мерцающим светом и толпами монстров. Обычный домашний ПК тогда — это процессор 386 или 486 без отдельного графического ускорителя и экран 320×200 точек в 256 цветах.

Движок написал в основном Джон Кармак. Разработка шла на рабочих станциях NeXT, там же жили редактор карт DoomEd и утилита, которая готовила карты к игре. Готовая игра собиралась для MS-DOS. В 1997 году id опубликовала исходный код версии для Linux, а в 1999 перевела его под лицензию GPL. С тех пор устройство DOOM можно изучать не по слухам, а по файлам r_bsp.c, p_enemy.c и am_map.c. Эта энциклопедия опирается именно на них.

Главная хитрость движка — он не трёхмерный. Мир DOOM — это плоская карта, как план этажа, где у каждой комнаты записаны высота пола и потолка. Стены всегда вертикальные, полы всегда горизонтальные, комнату нельзя поставить над другой комнатой, а посмотреть вверх или вниз игрок не может. Такую схему называют «2,5D». Каждое из этих ограничений — сознательная цена за скорость, и почти все приёмы движка становятся понятными, если помнить: внутри DOOM — двумерный мир, которому досталась одна лишняя координата.

WAD: «где все данные?»

Всё содержимое игры — графика, звуки, музыка и уровни — лежит в одном файле с расширением .wad (от «Where's All the Data?»). Внутри это простой архив: заголовок, набор «лампов» (кусков данных) и каталог с их именами. Движок не знает, откуда взялась конкретная картинка или карта, он просто ищет лампы по имени. Поэтому с первых дней игроки делали свои WAD-файлы с новыми уровнями: такой файл, загруженный поверх основного, подменял лампы с совпадающими именами.

Уровень в WAD — это лампы, которые идут строго в одном порядке после маркера с именем карты, например E1M1. Порядок задан в исходнике перечислением ML_THINGS … ML_BLOCKMAP:

• VERTEXES — вершины, пары координат x, y;
• LINEDEFS — линии между двумя вершинами: стены, проходы, края ступенек;
• SIDEDEFS — стороны линий: какие на них текстуры и к какому сектору они обращены;
• SECTORS — участки пола: высота пола и потолка, их текстуры, яркость, особый тип;
• THINGS — вещи: точка старта игрока, монстры, аптечки, бочки;
• SEGS, SSECTORS, NODES — BSP-дерево, которое строят заранее (глава E1M3);
• REJECT и BLOCKMAP — таблицы-подсказки для проверки видимости и столкновений (главы E1M8 и E1M7).

Первые пять ламп рисует автор уровня в редакторе. Остальные пять за него вычисляет отдельная программа — построитель узлов (node builder). Сама игра при загрузке ничего не считает: она получает готовые таблицы, и поэтому уровень загружается почти мгновенно.

Линия и две её стороны

Самая важная запись карты — linedef. Это 14 байт: номера двух вершин, флаги, номер спецэффекта, метка и ссылки на две стороны. Если у линии одна сторона, это сплошная стена. Если две, линия разделяет два сектора, и сквозь неё можно смотреть и проходить.

На двусторонней линии могут быть три текстуры: верхняя закрывает перепад потолков, нижняя — перепад полов, средняя обычно пуста или служит решёткой. Так получаются ступеньки, окна и дверные проёмы, хотя в данных нет ни «двери», ни «окна» — только два сектора с разными высотами.

• 1196вершин в E1M1 Freedoom
• 1175линий
• 182сектора
• 292вещи

Сектор — это не комната

Сектор — набор линий, ограничивающих участок с одинаковыми полом, потолком и светом. Он не обязан быть выпуклым и даже связным: колонна посреди зала — это дырка в секторе, обведённая односторонними линиями. Дверь в DOOM — отдельный крошечный сектор, у которого потолок опущен до пола. Когда игрок нажимает «использовать», движок заводит «мыслителя», который каждый такт поднимает этот потолок, пока проём не откроется. Лифт делает то же самое с полом.

Высоты хранятся в целых единицах карты. Морпех имеет радиус 16 единиц и рост 56, глаза у него на высоте 41, а ступенька выше 24 единиц для него уже стена. Комнаты на картах обычно занимают от нескольких сотен до пары тысяч единиц. На этом сайте один CSS-пиксель равен одной единице карты.

35 тактов в секунду

Игровой мир DOOM живёт тактами — «тиками». Константа TICRATE равна 35: ровно столько раз в секунду движок опрашивает клавиатуру и мышь, двигает игрока и монстров, открывает двери и мигает лампами. Отрисовка подстраивается: если компьютер медленный, кадров меньше, но за один кадр прогоняется несколько тактов, и мир движется с той же скоростью. Больше 35 кадров в секунду оригинальная игра не рисует — новых тактов просто нет.

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

typedef struct {
    char  forwardmove;  // вперёд/назад
    char  sidemove;     // шаг вбок
    short angleturn;    // поворот
    short consistancy;  // проверка сети
    byte  chatchar;
    byte  buttons;      // огонь, «использовать»
} ticcmd_t;

Дробные числа без дробей

У процессора 386 не было быстрой арифметики с плавающей точкой, а у многих машин её не было вовсе. Поэтому все координаты, скорости и масштабы в DOOM — 32-битные целые числа с фиксированной точкой 16.16: старшие 16 бит — целая часть, младшие — дробная. Константа FRACUNIT = 65536 означает единицу. Сложение остаётся обычным сложением, а умножение — это умножение с последующим сдвигом на 16 бит (функция FixedMul). Так 1,5 единицы хранится как 98304, а 0x00018000 в шестнадцатеричном виде сразу показывает целую и дробную части.

Круг из 2³² частей

Углы хранятся так же хитро: тип angle_t — беззнаковое 32-битное число, и полный оборот равен 2³². Тогда ANG90 = 0x40000000, ANG180 = 0x80000000, а переход через 360° происходит сам собой при переполнении. Такая запись называется BAM (binary angle measure). Для синусов движок сдвигает угол на 19 бит вправо и получает номер одного из 8192 «тонких углов» в таблице finesine. Косинус берётся из той же таблицы со сдвигом на четверть круга.

• 35тактов в секунду
• 16.16формат координат
• 8192тонких углов на круг

Задача художника

Чтобы нарисовать сцену, надо знать, какая стена ближе. Самый прямолинейный способ — «алгоритм художника»: отсортировать стены по расстоянию и рисовать от дальних к ближним, затирая лишнее. Но сортировать сотни стен каждый кадр дорого, а многое при этом рисуется зря. Весной 1993 года ранние версии DOOM ещё работали без BSP и тормозили на сложных участках.

Решение Кармак нашёл в научных статьях о двоичном разбиении пространства (binary space partitioning). Идею BSP-деревьев описали Генри Фукс, Цви Кедем и Брюс Нейлор в 1980 году. До DOOM Кармак уже пробовал её при переносе Wolfenstein 3D на Super Nintendo. Суть: один раз заранее разрезать уровень прямыми на выпуклые куски и записать разрезы в дерево. После этого порядок «от ближнего к дальнему» для любой точки обзора получается простым обходом дерева, без всякой сортировки.

Построитель узлов выбирает одну из линий карты и продлевает её в бесконечную разделяющую прямую. Всё, что лежит справа, уходит в «переднее» поддерево, всё, что слева, — в «заднее». Линии, которые прямая пересекает, режутся надвое — так из linedef получаются сегменты (segs). Потом процесс повторяется для каждой половины, пока кусочки не станут выпуклыми. Такие выпуклые кусочки называются подсекторами (subsectors). В выпуклом многоугольнике стены не могут загораживать друг друга, поэтому внутри подсектора порядок отрисовки уже не важен.

Узел дерева

Каждый узел в ламбе NODES — это 28 байт: начало прямой и её направление, два прямоугольника-границы (для переднего и заднего поддерева) и два номера детей. Если в номере ребёнка установлен старший бит NF_SUBSECTOR (0x8000), это не узел, а лист — подсектор.

void R_RenderBSPNode (int bspnum)
{
    if (bspnum & NF_SUBSECTOR) {
        R_Subsector (bspnum & ~NF_SUBSECTOR);
        return;
    }
    bsp = &nodes[bspnum];
    // с какой стороны прямой игрок?
    side = R_PointOnSide (viewx, viewy, bsp);
    // сначала ближняя половина
    R_RenderBSPNode (bsp->children[side]);
    // дальняя — только если видна
    if (R_CheckBBox (bsp->bbox[side^1]))
        R_RenderBSPNode (bsp->children[side^1]);
}

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

Девяносто градусов

Обход дерева выдаёт сегменты спереди назад, но большинство из них игрок всё равно не видит. Функция R_AddLine отсеивает их за несколько целочисленных операций. Сначала она считает углы от глаз игрока до обоих концов сегмента. Если угловой размах больше или равен 180°, сегмент повёрнут к игроку спиной, и его можно забыть: у сплошной стены видна только одна сторона. Затем углы поворачиваются на угол взгляда и обрезаются по краям поля зрения. Константа FIELDOFVIEW = 2048 «тонких углов» — это ровно 90°.

Обрезанные углы через таблицу viewangletox превращаются в номера столбцов экрана — от 0 до 319. С этого момента сегмент для движка — просто отрезок [x1, x2] на одномерной полосе экрана. Вся дальнейшая работа идёт с этой полосой, и это вторая главная идея движка после BSP.

Список закрытых столбцов

Массив solidsegs (не больше 32 элементов) хранит диапазоны столбцов, которые уже закрыты сплошными стенами. В начале кадра в нём только два «стража» — всё левее нуля и всё правее 319. Когда приходит новая сплошная стена, R_ClipSolidWallSegment находит в её отрезке ещё не закрытые куски, отправляет на отрисовку только их и объединяет диапазоны. Двусторонняя линия-«окно» (например, край ступеньки) рисуется в свободных кусках, но столбцы не закрывает — сквозь неё видно дальше. Это делает R_ClipPassWallSegment.

Ранний выход

Когда вся полоса от 0 до 319 закрыта, дальние ветви дерева можно не обходить. Перед тем как спуститься в дальнюю половину узла, R_CheckBBox проецирует на экран её прямоугольник-границу и проверяет, остался ли в нём хоть один открытый столбец. Если нет, пропускается целая половина уровня.

Закрытая дверь для отсечения — тоже сплошная стена: если потолок сектора за линией опустился до пола, R_AddLine отправляет её в R_ClipSolidWallSegment. А пустая линия, у которой по обе стороны одинаковые пол, потолок и свет, не рисуется вовсе: такие линии ставят как невидимые «спусковые крючки» для скриптов уровня.

Карта открывается взглядом

У отсечения есть неожиданный побочный эффект. В r_segs.c при каждой отрисовке стены выполняется linedef->flags |= ML_MAPPED. Автокарта показывает только линии с этим флагом. Поэтому карта уровня открывается не там, где вы прошли, а там, куда вы посмотрели.

256 цветов на всё

Экран DOOM работает в режиме с палитрой: каждый пиксель — один байт, номер цвета из 256. Палитру хранит ламп PLAYPAL. Как сделать стену темнее, если нельзя просто умножить цвет на коэффициент? Заранее приготовить таблицу. Ламп COLORMAP — это 34 таблицы по 256 байт. Таблица номер N отвечает на вопрос: «Каким номером палитры нарисовать цвет X на уровне темноты N?» Таблица 0 — полная яркость, 31 — почти чернота, 32-я делает картинку инверсно-серой для неуязвимости, 33-я полностью чёрная.

Затемнение пикселя стоит одно обращение к памяти: colormap[texel]. Внутренний цикл рисования колонки так и выглядит: взять байт текстуры, пропустить через таблицу света, записать на экран. Никакой арифметики с цветом.

У каждого сектора есть яркость от 0 до 255. Движок делит её на 16 и получает один из 16 уровней LIGHTLEVELS. Чтобы прямоугольные комнаты не выглядели плоскими, есть «ложный контраст»: стены, идущие строго с запада на восток, рисуются на уровень темнее, а с севера на юг — на уровень светлее.

Тьма растёт с расстоянием

Самый узнаваемый эффект DOOM — дальние стены уходят в темноту, даже если комната ярко освещена. Для стен движок использует таблицу scalelight[16][48]: чем меньше масштаб стены на экране (то есть чем дальше она), тем темнее выбранная таблица COLORMAP. Для полов и потолков — таблицу zlight[16][128] по расстоянию до строки пола. Обе считаются один раз при запуске, по формуле из R_InitLightTables.

Таблиц света всего 32, поэтому затемнение идёт ступенями — на полу видны полосы-«кольца». Это не ошибка, а характерный вид DOOM, который в современных портах иногда воспроизводят нарочно.

Мигающий свет — это мыслитель

Особые типы секторов оживают при загрузке уровня: P_SpawnSpecials заводит для них маленьких «мыслителей». T_LightFlash случайно гасит свет, T_StrobeFlash мигает с периодом 15 или 35 тактов, T_Glow плавно меняет яркость на 8 единиц за такт, T_FireFlicker дрожит, как огонь. Вспышку выстрела делает переменная extralight: на пару тактов весь мир становится на одну-две ступени светлее.

Стена — это пачка вертикальных полосок

Каждый видимый кусок сегмента попадает в R_StoreWallRange. Для каждого столбца экрана движок считает масштаб (насколько близко стена), верх и низ стены и номер столбца текстуры, после чего рисует вертикальную полоску функцией R_DrawColumn. Ключевое свойство: вдоль вертикальной полоски стены расстояние до глаз не меняется. Значит, шаг по текстуре постоянный, и внутренний цикл — это несколько сложений без единого деления. Поэтому у DOOM нельзя наклонить голову: стены перестали бы быть вертикальными на экране, и трюк бы сломался.

Ради того же трюка текстуры стен хранятся по столбцам. Текстура собирается из «патчей» — картинок, описанных в лампах TEXTURE1 и PNAMES. Сами патчи записаны как наборы вертикальных «столбиков» с прозрачными промежутками, и рисовать их по столбцам удобнее всего.

Пол рисуется строками

С полами и потолками всё наоборот: у них постоянна глубина вдоль горизонтальной строки экрана. Пока рисуются стены, движок только запоминает, какие пиксели каждого столбца остались над стеной (потолок) и под ней (пол). Эти отметки собираются в визплейны (visplanes): у визплейна одна высота, одна текстура, одна яркость и два массива top[320] и bottom[320]. После стен R_DrawPlanes превращает столбцы визплейна в горизонтальные отрезки — спаны — и рисует их функцией R_DrawSpan.

Знаменитые лимиты

Все массивы рендера в DOOM статические, размеры выбраны раз и навсегда:

• 128визплейнов (MAXVISPLANES)
• 256отрисованных сегментов (MAXDRAWSEGS)
• 128спрайтов в кадре (MAXVISSPRITES)
• 32диапазона в solidsegs

Если на экране больше 128 разных участков пола и потолка, игра падает с ошибкой «R_FindPlane: no more visplanes». Авторы карт годами учились её обходить: упрощали узоры пола, уменьшали число разноцветных секторов. Порты вроде Boom сняли ограничение, заменив массив хеш-таблицей списков.

Спрайты — последними

Монстры, бочки и пули — плоские картинки. Пока обходится дерево, видимые вещи попадают в список vissprites. После стен и полов список сортируется по масштабу, и спрайты рисуются от дальних к ближним. Каждый столбец спрайта обрезается по сохранённым drawsegs, чтобы монстр за краем стены не вылезал поверх неё. Картинку выбирают из восьми поворотов — по углу между монстром и игроком.

Сетка 128 × 128

Чтобы понять, может ли игрок шагнуть в новую точку, нужно проверить все линии рядом с ним. Перебирать каждый такт тысячу линий уровня для каждого монстра слишком дорого. Поэтому построитель узлов накрывает карту сеткой из квадратов 128×128 единиц (MAPBLOCKUNITS) и для каждого квадрата записывает в ламп BLOCKMAP список линий, которые его задевают. Вещи тоже «прописываются» в квадраты, в которых стоят их центры.

Когда вещь хочет сдвинуться, P_TryMove вызывает P_CheckPosition. Та строит вокруг новой точки квадрат со стороной в два радиуса (у морпеха радиус 16 — квадрат 32×32) и смотрит только клетки, которые он задевает. Каждая линия из их списков проверяется на пересечение с квадратом: сплошная стена останавливает сразу, двусторонняя — если за ней ступенька выше 24 единиц или слишком низкий потолок. Вещи из тех же клеток проверяются на перекрытие квадратов. Клетки берутся с запасом MAXRADIUS = 32, ведь центр соседа может лежать в соседней клетке.

Скольжение

Если упереться в стену под углом, морпех не застревает, а скользит вдоль неё. Это работа P_SlideMove: она ищет ближайшую линию, в которую упёрлось движение, и оставляет от вектора скорости только часть, параллельную стене. Если найти линию не удаётся, срабатывает запасной вариант «ступенька»: сначала попробовать сдвинуться только по X, потом только по Y.

Бесконечно высокие монстры

Столкновения в оригинальном DOOM почти двумерные. Высота вещей учитывается только при проверке пола и потолка, а друг для друга вещи бесконечно высокие. Поэтому нельзя пройти над головой монстра или запрыгнуть на него: в плане они просто квадраты. Это тоже экономия — и ещё одно напоминание, что мир DOOM плоский.

Квадрат вместо круга даёт забавный эффект: по диагонали морпех «толще», чем по прямой, и в узкий диагональный коридор пролезает хуже.

Всё живое — в одном списке

Всё, что меняется со временем, — монстр, летящий шар огня, открывающаяся дверь, мигающая лампа — в DOOM называется «мыслителем» (thinker). Это структура с двумя указателями (на соседей по двусвязному списку) и указателем на функцию. Каждый такт P_RunThinkers проходит по списку и вызывает у каждого его функцию. Чтобы удалить мыслителя, ему ставят функцию -1, и на следующем проходе он выбрасывается из списка.

Монстры поведение не программируют. Каждый живёт по таблице состояний states[] из info.c. Состояние — это кадр спрайта, длительность в тактах, функция-действие и номер следующего состояния. Бес, например, стоит в состояниях S_TROO_STND и S_TROO_STND2 по 10 тактов, вызывая A_Look. Проснувшись, он бежит по кругу из восьми состояний по 3 такта с A_Chase. Атака — два раза по 8 тактов A_FaceTarget и бросок A_TroopAttack.

Как монстр слышит

Выстрел игрока вызывает P_NoiseAlert. Та запускает P_RecursiveSound — заливку по секторам: из сектора игрока звук переходит в соседние через двусторонние линии, если проём между ними открыт (закрытая дверь звук глушит). Линия с флагом ML_SOUNDBLOCK пропускает звук один раз, а через вторую такую линию он уже не пройдёт. Каждый сектор, куда дошёл звук, запоминает источник в поле soundtarget. Спящий монстр в A_Look первым делом смотрит, не записан ли там игрок.

Как монстр видит

Если не услышал, монстр ищет игрока глазами (P_LookForPlayers): смотрит только вперёд, в полукруге 180°, если игрок не подошёл вплотную. Сама проверка видимости P_CheckSight сначала заглядывает в таблицу REJECT — битовую матрицу «сектор на сектор». Бит говорит, что из одного сектора другой не виден никогда, и тогда считать ничего не надо. Иначе по BSP-дереву трассируется луч от глаз монстра к игроку.

Восемь направлений

Бегает монстр не к игроку напрямую, а по одному из восьми направлений, выбирая в P_NewChaseDir то, что ближе к цели. Скорости по диагонали записаны в таблице как 47000 — это 65536 × cos 45°. Каждые несколько шагов (счётчик movecount берётся из P_Random) направление пересчитывается. Если путь закрыт, монстр пробует соседние направления и даже разворот. Отсюда «дёрганая» походка и умение монстров застревать за колоннами.

Что осталось за кадром

Мини-движок этого сайта — упрощение. Его BSP строится из прямоугольников страницы, сектора здесь только трёх видов, а монстры видят только один поворот спрайта. Но порядок работы в нём тот же, что в DOOM: обход дерева спереди назад, отсечение по столбцам, таблицы света, сетка столкновений и мыслители, которые 35 раз в секунду делают свой шаг.

Остальные работы курса — в меню «Работы» вверху страницы и в слотах «Задания» на статус-баре.

Источники и лицензии

• Исходный код DOOM (linuxdoom-1.10), id Software, 1997; лицензия GNU GPL — github.com/id-Software/DOOM. Файлы r_bsp.c, r_segs.c, r_plane.c, r_main.c, p_enemy.c, p_map.c, p_sight.c, p_lights.c, m_random.c, f_wipe.c, am_map.c. Таблица rndtable на этом сайте взята оттуда.
• Fabien Sanglard. Game Engine Black Book: DOOM. 2018.
• David Kushner. Masters of Doom. 2003 — история id Software.
• H. Fuchs, Z. Kedem, B. Naylor. On Visible Surface Generation by A Priori Tree Structures. SIGGRAPH, 1980.
• DoomWiki.org — статьи «Doom rendering engine», «Visplane overflow», «Reject», «Blockmap».
• Графика, палитра, текстуры и данные карты E1M1: Freedoom 0.13.0, © 2001–2024 Contributors to the Freedoom project, лицензия BSD 3-Clause — freedoom.github.io. Картинки извлечены из freedoom1.wad собственным скриптом, схемы и кадры отрисованы мини-движком сайта.