Движок Doom

Движок Doom (Doom engine, позднее названный id Tech 1) — один из двух легендарных псевдотрёхмерных движков для стрелялок от первого лица. До появления конкурента, Build, он был самым продвинутым движком и образцом для подражания. И ранним образцом игрового middleware: несколько игр сделаны сторонними фирмами.

Перестрелка Doom превосходила таковую у Duke Nukem 3D (основная тактика «Дюка» — обложиться чем-то взрывчатым и кемперить), а редакторов было много и все они очень просты — так что движок точно остался в сердцах геймеров.

Сравнение с Build

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

	Id Tech 1	Build
Автор	Джон Кармак (id Software)	Кен Сильверман (инди → 3D Realms)
Язык программирования	Написан на С, игровая логика пишется на нём же. В Hexen часть логики уровня может писаться специальным байт-кодом BEHAVIOR, реконструирован хакерами.	Написан на C, но изрядная часть игровой логики записана во внешних скриптах с расширением CON. Кроме того, с клиентами Сильверман исходниками не делился, отправляя им только собранные OBJ-файлы.
Системные требования	Для картинки 320×200 — старшие модели Intel 80356, 4 МБ оперативной памяти, что гораздо лучше Build. Современная версия с переменным разрешением экрана — Pentium Pro и 32 МБ оперативной памяти, что уже гораздо хуже.	Для картинки 320×200 — младшие модели Intel 80486, 8 МБ оперативной памяти. Для 640×480 — Pentium 133. В отличие от DOOM, поддержка видеодрайвером VESA 2.0 желательна, но не обязательна.
Графика	256-цветная; разрешение картинки изначально жёстко фиксированное 320×200, переделка потребовала много работы как над отрисовкой, так и над интерфейсом.	256-цветная, переменного разрешения. Были глюки с высокими разрешениями, но в современных версиях движка они большей частью закрыты.
Камера	В первой версии обзора вверх-вниз не было, позже — в двухточечной проекции (не полноценное 3D). Несмотря на это, трёхмерная физика стрельбы была всегда.	Обзор вверх-вниз в двухточечной проекции. В современных версиях — полноценное 3D.
Звук	Сложный звук со стерео и приоритетом одних звуков над другими. Реализован через внешнюю библиотеку — DMX в оригинале и Allegro в большинстве DOS-портов.	Сложный звук со стерео и приоритетом одних звуков над другими.
Геометрия уровня	Полы и потолки строго горизонтальные, стены строго вертикальные.	Полы и потолки могут быть наклонными, стены всё так же вертикальные.
	Многоэтажности нет (секторы не могут пересекаться из-за ограничений алгоритма отрисовки).	Есть зачатки многоэтажности — секторы могут быть расположены друг над другом, если они не видны оба сразу. Кроме того, потолок одного сектора может служить полом другого — в Duke Nukem 3D так реализованы лифты, трубы, подводный мир.
	Динамически может меняться только высота пола или потолка — именно поэтому в Doom двери открываются вверх. В Hexen добавили поддержку полиобъектов, которые могут ограниченно двигаться по горизонтали.	Поддерживается динамическое изменение высоты пола и потолка, а также произвольное движение сектора внутри другого, лишь бы пересечений не было — это позволило реализовать распахивающиеся двери, горизонтальные лифты, огромные крутящиеся шестерни из полов/потолков и даже подобие машинок.
	Разнообразные и красивые секторные эффекты: сектор может утонуть в лаве (или, наоборот, подняться из лавы), могут построиться ступеньки.	Сравнительно бедный набор секторных эффектов. Нужна конкретика. Не исправили до 21 ноября 2025, можно снимать.
	Масштаб текстур постоянный. Поворот текстур пола/потолка невозможен; в Heretic и Hexen реализовали сдвиг. С текстурами стен всё значительно свободнее.	Поддерживается переменный масштаб текстур: например, на менее детальной стене можно расположить детализированный плакат.
	—	Как развитие предыдущего пункта — поддерживаются декали на стенах, в том числе динамически появляющиеся. Через них можно реализовать, помимо прочего, следы крови и пуль на стенах; в Doom их нет.
Объекты	Спрайты, для каждого объекта задаются 1 или 8 поворотов.	Спрайты, для каждого объекта задаются 1 или 5 поворотов (остальные три — симметрично отражённые версии).
	Поддерживается перемещение по всем трём осям. Хитбокс каждого — параллелепипед со сторонами, параллельными осям X/Y/Z. В Doom в некоторых ситуациях хитбокс имеет бесконечную высоту.	Поддерживается перемещение по всем трём осям.
	Полупрозрачность реализована с помощью специальных цветовых таблиц, в которых записано, как будет выглядеть объект один цвет за полупрозрачным объектом другого цвета. Для нескольких уровней прозрачности нужно несколько таблиц — в некоторых портах Doom их число доходило до 5.
Освещение	Постоянное для каждого сектора. Чтобы сделать световое пятно, нужно создать несколько вложенных друг в друга секторов.
Рендеринг	Программный, от ближних секторов к дальним, с помощью двоичного разбиения пространства. Одновременно находит видимые объекты и рисует 64 ближайших от дальних к ближним. Это требует предварительной обработки перед построением геометрии, что делает редактирование в визуальном режиме (WYSIWYG, сделал изменение — сразу увидел результат) невозможным.	Программный, от ближних к дальним, с помощью порталов. Поэтому редактор там WYSIWYG, и одна стена — это всегда одна стена и никогда не разбивается на части (но дважды, трижды и т. д. рисуется, если смотрим на неё из-за колонны). В современных версиях движка есть поддержка аппаратного рендера через OpenGL.
Скорость игры	35 тактов в секунду (половина штатной частоты VGA). В портах для приставок пришлось снижать до 30 и пересчитывать скорости.	30 тактов в секунду.
Редактор уровней	Множество сторонних редакторов уровней, в том числе крайне дружественных пользователю.	Единственный и жутко неудобный редактор уровней — несмотря на этот самый WYSIWYG.
Лицензия	Изначально коммерческая, ныне — GNU GPL v2

Что на нём написано

• Doom (1993) — id Software. Аддоны и продолжения:
  • Doom II: Hell on Earth (1994)
  • Ultimate Doom (1995)
  • Master levels for Doom II (1995)
  • Final Doom (1996)
• Heretic (1994) — Raven Software. Единственный аддон:
  • Heretic: Shadow of Serpent Riders (1996)
• Hexen: Beyond Heretic (1995) — Raven Software. Единственное продолжение:
  • Hexen: Deathkings of the Dark Citadel (1996)
• Strife: Quest for the Sigil (1996) — Rogue Entertainment

Технические подробности

Поскольку в конце 1998 года Doom (в версии Final Doom, слегка несовместимой по демо-роликам и с Hell on Earth, и с Ultimate Doom) был выпущен в открытый доступ (сначала под образовательной лицензией, а потом, после потери исходников одним из моддеров, и под GPL), технические подробности хорошо известны.

WAD

Формат архива WAD представляет собой простейшую файловую систему с короткими 8-символьными именами без расширений и каталогов. Никакого сжатия нет, однако если вдруг в игре оказываются несколько одинаковых файлов, несколько имён могут указывать на один отрезок данных. В Doom действительно были одинаковые файлы (повторяющиеся мелодии Doom II, часть символов шрифта), но с повторами не справлялись никак, они просто занимали лишнее место.

Однако, в отличие от нормальной файловой системы, порядок файлов в архиве иногда играет роль — для уровней, спрайтов, текстур пола/потолка и другого.

Сборка мелких файлов в большие архивы приветствовалась задолго до Doom (например, Dune II) — небольшой спрайт мог отнимать 1 или 2 килобайта. При 2-килобайтном кластере диска «хвосты» кластеров могут занимать столько же, сколько сама игра! Игры вроде Ecstatica, где тысячи мелких файлов никак не собирались в архив, геймеры недолюбливали.

Точная расшифровка аббревиатуры WAD неизвестна. Наиболее правдоподобная — Where’s All Data, а любимая фанатская — Where’re All Demons. По-русски никакая расшифровка не требуется: да-да, именно туда.

Зонная память

Зонная память (zone memory) — примитивный менеджер памяти/дисковый кэш/подкачка данных, оптимизированный под нужды игры. Он умел всего две вещи.

1. Загрузить файл в память и сказать: больше не выгружай.
2. Загрузить файл в память и отметить, что при желании его можно выгрузить.

Несмотря на примитивность, эта штука оказалась настолько эффективной, что авторы рекомендовали выключить дисковые кэши вроде SmartDrive в пользу DPMI-памяти: зонная память работает лучше.

Уровень

Уровень (в Doom) состоит из одиннадцати файлов примитивной файловой системы. Вот они все, не по порядку:

• Маркер уровня (E1M1 или MAP01). Изначально пуст, в портах в него могут поместить свойства уровня.
• Пять файлов, которые редактируются редактором: THINGS, LINEDEFS, SIDEDEFS, SECTORS, VERTEXES.
• Пять файлов, строящихся автоматически при компиляции уровня: SEGS, SSECTORS, NODES, REJECT, BLOCKMAP.

Идеология уровня субтрактивная: пространство заполнено непроходимой материей, и конструктор уровня прорубает в этой материи туннели.

Уровень представляет собой двухмерную карту из вершин (VERTEXES) и отрезков (LINEDEFS). Отрезки бывают односторонними и двусторонними, информация о сторонах хранилась в отдельном файле SIDEDEFS. Замкнутый многоугольник из сторон, не обязательно связный или выпуклый, назывался сектором (SECTORS). THINGS — это разбросанные по уровню точки, которые могут быть как техническими маркерами (одиночный, кооперативный или deathmatch-старт), так и командами для создания настоящих игровых объектов (mobjs = map objects).

Можно связать отрезок с сектором, используя тэги: если у отрезка эффект «открыть дверь многократно при нажатии» и тэг 42, то его активация откроет сектор-дверь, чей тэг 42. Отдельным эффектам не требовался тэг: например, эффект «дверь многократная» говорит, что дверь рядом, со второй стороны отрезка. В отдельных уровнях используются зарезервированные тэги 666 и 667 — условие активации и эффект прописаны в коде игры и привязаны к конкретным уровням.

Вся информация хранится в файлах уровня с точностью до текселя (грубо 3 см). Точность координат в игре значительно выше — ¹⁄₆₅₅₃₆ текселя. Стандартные дробные числа с плавающей запятой не используются: например, тригонометрия была по таблице.

Углы ориентации объектов хранятся в файлах уровня с точностью до градуса, но при загрузке огрубляются до 45°. В игре — 1 оборот = 2³², но многие расчёты идут грубее: например, в тригонометрических таблицах всего 8192 цифры.

Оптимизации

Чтобы это чудо ухитрялось как-то работать на старших 386, существует множество оптимизаций. И простейшая из них — BLOCKMAP: уровень делится на блоки 128×128 текселей (2×2 телепорта, грубо 4×4 метра). Для каждого блока указывается, какие отрезки через него проходят, это сокращает проверку столкновений.

REJECT — битовая матрица n×n, где n — количество секторов. Если в матрице 0 — монстр в секторе X, возможно, видит игрока в секторе Y, и нужно делать более сложную проверку видимости. Если 1 — точно не видит. Очень немногие программы строили хоть какой-то REJECT, наиболее известные — ZenNode и RMB (Reject Map Builder). Для перестрелки REJECT не нужен — монстров нет.

Главное же происходит, когда рисуется геометрия уровня. Уровень разбит прямой линией на две части, для каждой указан охватывающий прямоугольник. Каждая часть также разбита на две, и так пока в каждой из частей не окажется один выпуклый подсектор — это и есть двоичное разбиение пространства (NODES, SEGS, SSECTORS).

1. Поскольку поле зрения не превышает 90°, можно найти гарантированно невидимую полуплоскость. Например, если камера смотрит от северо-запада до северо-востока — это будет южная полуплоскость. Если охватывающий прямоугольник целиком в этой полуплоскости — не рисовать!
2. После этого происходит более точная проверка, попадает ли кусок уровня в сектор обзора. Если не пересекается — не рисовать!
3. Если кусок уровня — это один подсектор…
   • Проверяем ориентацию каждой его стороны, и если она смотрит на камеру, рисуем, обходя уже зарисованные части экрана.
     • Если подсектор небесный, он рисуется чуть по-другому, но также по столбцам.
     • Если сторона является глухой стеной, или проход выше/ниже поля зрения, или проход схлопнулся до нуля, объявляем столбец полностью зарисованным (стены в нём рисоваться больше не будут). Если окажется, что все столбцы зарисованы, рендеринг прекращается.
4. Если кусок уровня — это две меньших части…
   • Находим, в какой из них камера. Рисуем рекурсивно сначала эту, потом другую. Другими словами, рисование геометрии идёт приблизительно от ближних к дальним.

Во время этого прохода запоминаются участки пола и потолка (visplanes), объекты и решётки. Если геометрия уровня была слишком сложной, Doom мог вылететь с ошибкой not enough visplanes (порты обычно имеют более крупный массив, или даже расширяют, если заполнится). Они рисуются после.

Графика

Doom имел два формата графики: текстуры пола/потолка (flats) и всё остальное.

Текстура пола/потолка — простой массив 64×64 текселя.

«Всё остальное» — специальный формат графики с хранением по столбцам. Прозрачные тексели не хранятся совсем: взамен указывается, что столбец идёт, например, от Y=2 до Y=20.

Текстуры стен сборные, то есть могут состоять из нескольких графических файлов: например, стена, а поверх неё выключатель. Или световая стена получена размножением одного прямоугольного светильника. Долгий (больше минуты на 5×86) init Doom refresh daemon… в начале игры именно что создавал базу сборных текстур: какие столбцы берутся прямо из текстуры, какие вычисляются на лету и кэшируются. Текстуры глухих стен размножаются только с шагом 128, текстуры решёток (а также фальшивых стен, которые те же решётки) не размножаются и не могут содержать два разных файла в одной строке — потому есть четыре вида текстур, и это надо помнить новоиспечённому конструктору.

• Высота 128, без дыр, в каждой колонке ровно один графический файл (несколько бок о бок стоять могут). Это самая универсальная текстура; её можно ставить куда угодно — и на глухие стены, и на решётки.
• Высота 128, без дыр, хоть в одной колонке несколько графических файлов. Их можно ставить только на глухие стены. Если ставить на решётки, будет так называемый эффект Медузы — «кругом змеи, и игра превращается в камень» (начинает жестоко тормозить).
• С дырами, в каждой колонке ровно один графический файл. Их можно ставить только на решётки, иначе будет эффект тутти-фрутти — рисуются случайные тексели, игра работает быстро. (Из-за зонной памяти и ограничений DPMI ничего не вылетает.) Решётки не размножаются по вертикали.
• Высота менее 128, без дыр. Их можно ставить только на стены соответствующей высоты и чётко выравнивать, иначе будет то самое «тутти-фрутти». Ну или вместо решёток, если в каждой колонке ровно один файл — так можно сделать ограждение ленточкой.

Многие из портов давно избавлены от эффекта Медузы и тутти-фрутти.

Ещё один знаменитый артефакт Doom — зеркальный зал (в кадровом буфере остаются следы предыдущих кадров), но это просто нет текстуры там, где должна быть (реже — глюк двоичного разбиения). Настоящий Doom для DOS (в отличие от большинства портов, основанных на Linux-версии) использует 4-страничный X-режим, и там «зеркальный зал» ещё и мигает.

Текстура неба имеет разрешение 256×128 и покрывает угол в 90°, но ничего не мешает сделать текстуру 1024×128 на все 360°.

Затемнение происходит командой «нарисовать затемнённый столбец/строку», простой таблицей преобразования, коих в Doom больше десятка от самой светлой до совсем тёмной.

• 
  Эффект тутти-фрутти
• 
  Эффект Медузы
• 
  Эффект зеркального зала

SVGA

У Doom были такие проблемы касательно SVGA:

1. Код рисования столбцов содержал жёстко закодированную ширину экрана. Doom Legacy использовал самомодифицирующийся код, Smack My Marine Up — две версии под 320 и 640.
2. Рисование текстур пола и потолка быстро пробивало точность фиксированной запятой и уже на 800×600 смотрелось дрянь.
3. Метод рисования через двоичное разбиение был значительно менее масштабируемый, чем портальный у Build. Если под 320×200 Doom работает лучше Duke, то под 640×480 нужен минимум Pentium II.
4. Код меню вообще не рассчитывался под SVGA и требовал полного переписывания.
5. Перевод освещения в true color требует серьёзной переработки движка.

Демо-запись и мультиплеер

Демо-запись и мультиплеер основаны на простой идее: одна и та же программа с одними и теми же данными даст один и тот же результат. Вообще-то сделать повторяемый движок очень сложно — обратился к переменной раньше, чем записал в неё что-то, и вот уже имеем дело со случайной величиной, рассинхронизация. Написал что-то в машинных дробных — очень коварная рассинхронизация, если играешь на машинах разной архитектуры. И в любой игре есть рендерер, звук и другие части, которые заведомо не повторяемы, и данные рендерера нужно изолировать от данных физики. Рассинхронизации в игре всё же есть, наиболее известная — при заходе в меню одиночная игра останавливается, а демо-ролик продолжает писаться.

Демо-ролик в Doom пишется в заранее выделенный буфер памяти со скоростью 4 байта/такт, 8400 байт/минуту. Как только буфер заполнится, игра вылетает — разумеется, записав результат в файл. Для экономии памяти повороты в режиме демо-записи сделали более грубыми (256 позиций/оборот). Метки для перемотки отсутствуют; чтобы посмотреть ролик ещё раз, надо запустить его с начала. С другой стороны, из-за такого формата демо-роликов легко обнаруживается TAS — пользование «роботами» для быстрого прохождения, сплайсинг — объединение двух пробегов, когда модифицированная игра сначала повторяет старый пробег, а потом отдаёт управление игроку.

Мультиплеер происходит так: игра посылает управление всем остальным машинам. Как только управление от всех машин придёт, игра проделывает такт. При этом единственная разница между «ведущим» (первым игроком) и «ведомым» — ведомые подстраиваются под тактовую частоту ведущего (пропускают или ускоряют такты).

У такого мультиплеера очень низкие задержки, можно без вопросов играть по телефонному модему даже через все США. Зато есть три неустранимых недостатка:

1. Каждый связывается с каждым, что в интернете и в игре более чем ввосьмером очень нехорошо.
2. Отсутствует авторитарный ведущий, с которым можно посоветоваться, если что. Потому невозможно войти в начатую игру. Единственный способ выйти одному игроку — оставить неподвижного персонажа. Точно так же при рассинхронизации невозможно получить подобие сохранёнки, чтобы всё исправить.
3. Никакой защиты от жульничества: каждый компьютер всегда знает, где соперники.

В мультиплеере существует проверка на синхронность — с каждым пакетом приходит «свёртка синхронности», основанная на положении одного из игроков. Если пришедшая свёртка не совпадает с вычисленной, игра просто вылетает с ошибкой рассинхронизации. В демо-записи таковой нет.

В DOS-версии передачей данных занимается внешний драйвер. Это позволяет писать собственные драйверы и запускалки, подчас под необычные методы передачи — параллельный кабель LapLink или цепочку COM-кабелей.

Случайность — по таблице из 256 чисел, при этом существуют два указателя: синхронный (для геймплея) и асинхронный (для спецэффектов звука и меню). Причём эта таблица — не перестановка из чисел от 0 до 255, а рандомные 256 чисел. Так что некоторые вероятности отличаются от заявленных.

Моддерство

Doom — одна из первых игр, заточенных под моддерство. Но не всё можно модифицировать.

• Модифицируются без вопросов
  • Уровни — только как замена имеющимся: например, в Doom II тридцать основных уровней и два секретных.
  • Текстуры стен, в том числе совершенно новые (не замена имеющимся)
  • Звуки — только как замена имеющимся
  • Музыка — даже если мелодии уровней одинаковые, ничего не мешает сделать разные, авторы намеренно продублировали файлы. Есть отличные конвертеры из MIDI, многие порты принимают MIDI.
  • Детали интерфейса, в том числе графические названия уровней — если, конечно, удастся вписаться в имеющиеся схемы комплексов Doom 1
  • Раскладки инструментов для MIDI-платы Gravis Ultrasound. Но порты ими не пользуются, да и мало у кого есть дорогущий «гусь».
  • Палитровые эффекты (например, от темноты или скафандра)
• Модифицируются через глюки
  • Текстуры пола/потолка, в том числе совершенно новые
• Модифицируются только в формате total conversion
  • Основная 256-цветная палитра — ведь на неё завязана вся графика
  • Спрайты
• Модифицируются только через патч EXE-файла
  • Свойства и поведение объектов: величины урона, анимационные последовательности, звуки, ссылки на функции…
  • Свойства уровней: патчи на поведение звуков (например, особо подчёркнуты шипящие какодемоны на MAP10), только на MAP30 монстры могут делать телефраг, работа специальных тэгов 666 и 667, на какой уровень переходить после основного/секретного выхода, какую из небесных текстур брать, наличие/отсутствие текстовой вставки
  • Свойства текстур: анимации, выключатели. Интересно поступили в TNT: Evilution (одной из частей Final Doom): сделали длиннющие текстуры выключателей, и выравниванием влево-вправо подставляли нужный кусок.
  • Схемы комплексов Doom 1: анимации, положение указателей «вы тут», строящаяся Вавилонская башня…
  • Тексты, в том числе текстовые названия уровней

Существовала прога DEHACKED, которая занималась именно что патчем EXE-файла.

Многие из портов без вопросов позволяют менять всё из этого — кроме той самой палитры, на которую завязана вся графика.

История выпуска Doom в общее пользование

Никто не выкладывал редакторов в общее пользование. Однако форматы были быстро распознаны, и помимо первенца, крайне неудобного DEU, появились и другие редакторы — WADED, DCK…

В 1994 году открыли исходные тексты сетевых драйверов. Началась волна собственных драйверов (PARSETUP — LPT-кабель, HX8 — цепочка COM-кабелей) и запускалок (DOOMATIC мог даже передавать WAD по сети, если он есть у главного).

В декабре 1997 некомпилирующийся Doom для Linux (в версии Final Doom) выложили под несвободной образовательной лицензией. Уже через месяц Doom скомпилировали для DOS: вместо Watcom C взяли DJGPP (версию GCC/G++ для DOS; символ + в DOS запрещён и компилятор назывался GPP, отсюда DJGPP), вместо отсутствовавшей библиотеки DMX взяли открытый Allegro. И после этого пошла волна портов, из которых назову только четырёх первенцев:

• Boom (Lee Killough) — стал основой для дальнейшего моддинга и стандартом новых секторных эффектов: есть дверь, требующая все шесть ключей, или лифт, где синхронно едут пол и потолок на манер кабины. Серьёзно ускорен по сравнению с Doom.
• Doom Legacy (Denis Fabrice, Boris Pereira) — один из самых дружественных портов.
• glDoom (Bruce Lewis) — первая попытка перевести Doom на OpenGL.
• ZDoom (Marisa Heit и другие) — отходит от полной совместимости со старой игрой, зато вводит новые и новые фичи: прыжки, плавание, рельсотрон, захват флага. Ныне брошен, но есть продолжение GZDoom.

В середине 1998 года разработке glDoom пришёл конец — у Льюиса накрылся жёсткий диск. И тогда в 1999 году id Software перелицензировали Doom под GPL2 — если бы лицензия не была столь жёсткой, у кого-то точно нашёлся бы код. А код действительно в 2010 нашёлся — когда Льюис разгребал компьютер умершего друга.

В январе 1999 компания Raven выложила в открытый доступ Heretic, Hexen и компилятор скриптов для Hexen. Лицензия на исходник была странная и привычная больше для скомпилированных программ — так что программисты обменивались портами на птичьих правах. Только в 2008, после многочисленных петиций, перелицензировали под GPL всё, кроме компилятора.

386-е компьютеры, на которых бегал Doom, были очень ограниченными, а исходный текст — довольно качественным (за исключением меню, переделать под переменное разрешение — та ещё работа). Несмотря на то, что Си — чисто процедурный язык, Doom написан в неплохом объектном стиле и разбит на слои — внешний цикл (G), геймплей (P), рендерер (R), меню (M), ссылки в код из таблиц (A)… Ну и игра сделана без единого компьютерного дробного, в так называемой фиксированной запятой 16,16 (в роли машинной единицы число 65536), что тоже упрощает портацию на маломощные процессоры. Отдельным спортом стал запуск Doom на чём угодно, где есть 32-битный процессор, кнопки и экран: на фотоаппаратах, принтерах, графических калькуляторах, читалках…

В момент создания Doom (1993…94) немалое количество компьютеров из звукоизвлекающих устройств имело только встроенный динамик. К 1999 звуковым контроллером оснащались все ПК, во многих он был распаян на матплате, к тому же библиотека DMX, занимавшаяся, в числе прочего, поддержкой динамика, была выпилена из игры, потому на динамик забили. Формат звука для динамика был совершенно очевиден: однобайтовые ноты, менявшиеся с частотой в 140 Гц (4·частота тактов), но какая шкала? Около 2007 выяснили: четвертьтоновая (24 единицы = частота вдвое).

Главный недостаток современных истинно трёхмерных версий Doom — спрайты очень плохо совместимы с обзором выше-ниже. Можно сделать полигональные модели, но они в большинстве случаев выглядят крипово. И тут аж в 2022 некто Daniel Peterson сделал Voxel Doom — большая часть объектов заменена воксельными моделями.

Все файлы данных остаются коммерческими, и даже есть FreeDoom (на 2023 неготовый) — попытка создать полностью открытый WAD. Выглядит как последняя перескиновка.

Примечания

	[ + ] Игровые движки
Страницы в категории «Игровые движки»  Build, Движок Doom