Полигоны Another World

Перевод статьи от Fabien Sanglard про внутренности Another World.

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

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

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

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

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

Серия статей

Another World 101

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

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

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

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

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

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

Движок также способен создавать эффекты полупрозрачности, если на сцене только восемь цветов.

Здесь цвета хранятся в пределах [0x0,0x8].

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

Прозрачность использовалась в игре не так часто, но её можно увидеть ещё раз во время эксперимента, когда молния вот-вот телепортирует Лестера в Другой Мир.

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

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

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

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

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

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

0x00

0x01

0x02

0x03

0x04

0x05

0x06

0x07

0x08

0x09

0x0A

0x0B

0x0C

0x0D

0x0E

0x0F

0x00

CMOV

MOV

ADD

CADD

CALL

RET

PAUSE
THRD

COND
JMP

SET
VECT

JNZ

CJMP

SET
PAL

RESET
THRD

SLCT
FB

FILL
FB

COPY
FB

0x10

BLIT
FB

KILL
THRD

DRAW
TEXT

SUB

AND

SHL

SHR

PLAY
SOUND

LOAD
RESC

PLAY
MUSIC

0x20

0x30

0x40

DRAW_POLY_SPRITE

0x50

0x60

0x70

0x80

DRAW_POLY_BACKGROUND

0x90

0xA0

0xB0

0xC0

0xD0

0xE0

0xF0

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

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

Что дальше?

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

Gamedev suffering

Блог о разработке игр и серверных технологиях