Хабрахабр

[Перевод] Полигоны Another World

Найти знакомую вам программу и попытаться выяснить, как она была портирована. Существует интересный способ изучения архитектуры компьютеров прошлого.

Мегахит 1994 года от id Software был портирован на всё, что только можно. Хорошим выбором для этого мог бы стать DOOM. Обычно легко найти и прочитать реализацию шести подсистем ввода-вывода. Игра спроектирована вокруг ядра, чётко разделённого на слои.

Я бы сказал, что на самом деле её интереснее изучать, чем DOOM, из-за полигональной графики, подходящей для диких оптимизаций. Другим выбором могла бы стать Another World 1991 года от Эрика Шайи, в Северной Америке более известная под именем Out Of This World. В некоторых случаях хитрые трюки позволяли игре работать на оборудовании, созданном за пять лет до выхода игры.

От Amiga 500, Atari ST, IBM PC, Super Nintendo, до Sega Genesis. Эта серия статей представляет собой путешествие по оборудованию для видеоигр начала 90-х. Для каждой машины я пытался узнать, как реализована Another World.

В худших мне приходилось самому разбираться в дизассемблированном коде. В лучшем случае мне удалось связаться с оригинальным разработчиком. Это было весёлое приключение.

Another World 101

В первоначальной версии для Amiga, как сообщалось, было всего 6000 строк. В Another World довольно мало кода. Удивительно для такой огромной игры, которая поставлялась на одной дискете 1. Исполняемый файл для DOS под PC составляет всего 20 кБ. Всё потому, что большая часть бизнес-логики реализована с помощью байт-кода. 44 MiB. Исполняемый файл Another World фактически является хостом виртуальной машины, читающим и выполняющим uint8_t опкоды.

Вот и всё. Виртуальная машина в Another World определяет 256 переменных, 64 потока, 29 опкодов и три фреймбуфера (перевод от PatientZero). Если вы можете сделать виртуальную машину достаточно быстрой, чтобы работать со скоростью 20 кадров в секунду, вы в действительности сможете сыграть в игру. Если вы создадите хост для виртуальной машины, способный справиться с этим, вы сможете запустить игру.

Ограничение на палитру может удивить, учитывая, что Amiga 500 поддерживает до 32 цветов. Графическая система виртуальной машины использует систему координат 320x200 с 16-цветовой палитрой. Это было сделано целенаправленно, что позволило совместить графику с другой крупной платформой того времени — Atari ST, которая поддерживает только 16 цветов.

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

Во время столкновения с «Чудовищем» для оного используются всего три цвета: черный для тела, красный для глаз и бежевый для зубов. Даже когда была возможность использовать определённую палитру для сцены, Эрик Шайи решил не делать этого. Воображение сделало остальное.

Весьма дешёвая смена палитры позволила легко изобразить удар молнии. Подобная система для палитры полноценно раскрылась в начальной сцене.

Они нарисованы специальным цветом 0x10, которго не существует, поскольку доступно только 16 цветов. Лучи от фар Ferrari полупрозрачны. Последняя часть трюка заключается в умном выборе следующих 8 цветов в палитре. Специальное значение интерпретируется как «прочитать индекс кадрового буфера, добавить 0x8 и вернуть».

Три фреймбуфера

Эта оптимизация позволяет избежать перерисовки всех полигонов статических фонов в пользу простой операции копирования. Из трёх фреймбуферов два используются для двойной буферизации, в то время как последний используется для сохранения фоновой (BKGD) композиции.

Каждый новый кадр BKGD полностью копируется в двойной буфер. В следующем видео посмотрите, как новая сцена рисуется сначала в BKGD буфере. Обратите внимание, что после того, как автомобиль «припаркован», он также рисуется в BKGD буфере, чтобы минимизировать количество полигонов, которые будут отрисованы в последующих кадрах. Там движущиеся элементы, такие как Лестер, отрисовываются.

Это не проблема, поскольку она в значительной степени амортизируется копией BKGD. Также обратите внимание, как в композиции используется простой алгоритм художника, который, не смотря на свою простоту, приводит к лишней перерисовке.

Опкоды виртуальной машины

Здесь можно найти опкоды по управлению потоками (THRD), управлению фреймбуферами (FB) и все операции управления регистрами. В следующей таблице представлено 29 опкодов. Большинство операций «просты» в реализации, за исключением «COPY FB», «FILL» и «DRAW_POLY*», которые сложны в плане производительности.

DRAW_POLY_BACKGROUND занимает половину пространства опкодов — от 0x80 до 0xFF. Оба DRAW_POLY_* опкода охватывают более одной ячеки. Использование всех операций, начинающихся с бита «1», позволяет 7 другим битам переноситься в пространство опкодов в качестве параметров отрисовки. Весьма расточительно, но это уловка для экономии места. Поскольку этот опкод используется для фона и синиматиков, экономия места очень важна.

SPRITE версия использует все опкоды, начинающиеся с битов «01», в то время как остальные оставшиеся 6 битов предназначены для кодирования [x, y] координат и зума для отрисовки «спрайтов» Лестера, друга и врагов.

Что дальше?

Реальная проблема при портировании этой игры заключалась в манипулировании пикселями в пределах ограничений шины и пропускной способности процессора. Как упоминалось ранее, 26 из 29 опкодов легко реализовать. В этой серии будет рассмотрено, как при порте происходила манипуляция фреймбуферами и как решались проблемы DRAW, FILL и COPY опкодов.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»