Полигоны 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.

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

Серия статей

  1. Полигоны Another World.
  2. Полигоны Another World: Amiga 500.
  3. Полигоны Another World: Atari ST.

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 OR 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 опкодов.