Не просто мем: почему DOOM запускается на калькуляторе и даже на тесте для беременности

[Article Publisher]

Если у устройства есть процессор и хотя бы рудиментарный экран, рано или поздно на нём запустят DOOM. Это негласный закон IT-индустрии. Мы видели демонический шутер на дисплее трактора John Deere, внутри клавиши клавиатуры и даже на тесте для беременности. Со стороны это кажется затянувшейся шуткой программистов. Но почему именно DOOM (1993), а не Wolfenstein 3D или Duke Nukem? Почему этот шутер стал индустриальным стандартом «Hello World» для сложной электроники? Дело не только в ностальгии. Архитектура движка id Tech 1, созданная Джоном Кармаком, представляет собой набор уникальных инженерных решений, которые позволили отвязать игру от «железа» того времени и отправить её в вечность.



Классика жанра: DOOM на инженерном калькуляторе Texas Instruments TI-83 Plus. Это пример «честного порта»: игра действительно выполняется на 8-битном процессоре Zilog Z80 с частотой 6 МГц. Текстуры упрощены до монохромной графики, но геометрия уровней узнаваема.
Автор: Kamil Kielczewski Источник: commons.wikimedia.org

Иллюзия трехмерности​

Главная причина, открывающая путь на слабые микроконтроллеры — это отказ от «честного» 3D. DOOM не нагружает процессор расчетом полигональных сеток или сложной перспективы по всем осям. Визуализация построена на методе Raycasting (бросание лучей).



Движок работает с двумерной картой (вид сверху). Чтобы нарисовать кадр, программа выпускает «лучи» из глаз игрока в 2D-пространстве. Упираясь в препятствие, движок рисует на экране вертикальную полосу пикселей. Высота полосы зависит от расстояния: чем дальше стена, тем короче линия. Это радикально снижает нагрузку на операции с плавающей запятой (FPU) и полностью исключает необходимость в Z-буфере, который «съел» бы всю память слабого устройства.



Однако одного рейкастинга для 1993 года было мало — процессоры i386 захлебывались при расчете видимости. Кармак решил эту проблему, внедрив алгоритм BSP (Binary Space Partitioning / Двоичное разбиение пространства).

Суть метода в том, что «тяжелая» работа делается заранее. При создании карты уровень нарезается на древовидную структуру. Когда игрок находится в конкретной точке, движок уже знает, какие стены видны отсюда, а какие можно отбросить, даже не пытаясь их просчитывать. Это превращает рендеринг сложной сцены в тривиальную задачу для CPU — по сути, простую перекладку данных из памяти в видеобуфер. Именно благодаря BSP микроконтроллер какого-нибудь умного термостата справляется с отрисовкой коридоров Марса.

Отказ от «железа»​

Визуальная легкость была бы бесполезна, если бы код был намертво прибит к архитектуре ПК. В начале 90-х стандартом для high-end игр был Ассемблер — быстрый, но непереносимый. Кармак сделал ставку на язык Си (ANSI C), оставив на ассемблере лишь критические участки кода (которые энтузиасты позже тоже переписали на Си).

Это решение сделало логику игры универсальной. Она полностью отделена от аппаратной части. Весь код, отвечающий за вывод звука, картинки и обработку нажатий (слои I_Video, I_Sound), вынесен в отдельные модули.

Джон Кармак. Именно его решени использовать Си вместо Ассемблера стало фундаментом для портирования игры на любые платформы — от банкоматов до фотоаппаратов.
Автор: Official GDC Источник: commons.wikimedia.org
Для энтузиаста, пытающегося запустить игру на фотоаппарате Kodak, задача сводится к написанию драйвера под конкретный экран и кнопки. Остальные 90% кода игры трогать не нужно — компилятор сам переведет их на язык целевого процессора, будь то архитектура ARM, MIPS или модный нынче RISC-V.

Эту независимость закрепил формат .WAD (Where's All the Data). Движок (исполняемый файл .exe) был полностью отделен от ресурсов (звуков, текстур, уровней). Это решило проблему памяти для встраиваемых систем. При портировании на устройство с крошечным объемом ПЗУ можно просто выкинуть оригинальный «тяжелый» WAD-файл и заменить его на урезанную версию (черно-белые текстуры, MIDI-звук), не переписывая ни строчки кода самого движка.

Открытый код и «честные» порты​

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



Однако, читая заголовки вроде «DOOM запустили на тесте для беременности», стоит сохранять долю здорового скептицизма. Существует два принципиально разных подхода:

• True Port. Игра действительно выполняется на процессоре устройства (тот самый калькулятор TI-83 или фотоаппараты).
• Display-only (Стриминг). Игра запущена на мощном ПК, а экзотическое устройство используется просто как внешний монитор.

К примеру, нашумевший случай с тестом на беременность — это гибрид. Энтузиаст заменил оригинальный чип и экран теста на крошечный OLED-дисплей и микроконтроллер, встроив их в оригинальный пластиковый корпус. То есть технически DOOM работал на новом (пусть и слабом) железе внутри старой оболочки. Но даже это стало возможным только благодаря тому, что код 1993 года оказался достаточно гибким, чтобы запуститься на устройстве размером со спичечную головку.