90-е стали десятилетием существенного прогресса в мире видеоигровых консолей[1]. Каждая новая модель привносила повышение вычислительных мощностей и улучшение графики.
Однако выпадающим из общей картины фактом стало появление в середине 90-х приводов CD-ROM. Хотя диск на 640 МиБ был в 320 раз больше объёма картриджей[2], скорость доступа (800 мс[3]) и пропускная способность (150 КиБ/с в случае односкоростных приводов) были, соответственно в 4 миллиона раз и в 35 раз ниже.
Mega-CD стала проектом компании Sega по добавлению CD-ROM к её консоли Genesis. Для этой платформы выпустили почти двести[4] игр. Среди них были и потрясающие Sonic CD, Snatcher, Final Fight CD, а также несколько RPG. Однако бесконечный конвейер игр, в которых активно использовалось Full Motion Video (FMV) (Night Trap, Prize Fighter, Slam City, Corpse Killer, Supreme Warrior, WireHead и A/X-101), создал плохую репутацию этой приставке Sega .
Среди этого мусора появилась Silpheed. Превосходный художественный вкус наряду с движком, способным выдавать великолепные анимации, свели прессу с ума[5][6]. Игроки гадали, было ли это 3D в реальном времени или же всё вычислялось заранее[7]. Игра заслужила похвалы, которой она достойна и сегодня[8][9].
Если вас не впечатлило увиденное, то учтите, что эти почти полноэкранные катсцены воспроизводились на CPU m68k с частотой 12,5 МГц, в них использовалось 16 цветов и они занимали 150 КиБ/с. Учитывая 16-битную музыку с частотой дискретизации 16 кГц, на каждый кадр видеопотока с 15 fps оставалось всего 8 КиБ.
Последние две недели я в свободное время занимался реверс-инжинирингом формата FMV игры. Это сильно отличалось от моей обычной работы, потому что мне не пришлось написать ни строки кода.
Ниже я опишу то, к чему пришёл. А если вы для понимания этой темы хотите посмотреть все катсцены и видео с фонами геймплея, то можете перейти в сториборд, который я создал при помощи спроектированных мной инструментов (я пользоваться ИИ, так что не могу сказать, что написал их).
Краткое описание внутреннего устройства Sega-CD
Прежде, чем мы перейдём к оптимизациям и трюкам, обеспечившим такую высокую эффективность формата видео Silpheed, нужно разобраться, как взаимодействуют Sega Genesis и Mega-CD.
GENESIS │ MEGA-CD │ ┌──────────────────────┐ │ ┌───────────┐ ┌──────────┐│ MC68000, 7,67 МГц │ │ │ WORD RAM │ │ MC68000 ││ │ ┌───┴──────┐ │ 256 КБ │ │ ││ ОЗУ 64 КБ ◄──┤ Порт ├────────►───────────┤ │ 12,5 МГц ││ │ │расширения│ │PROGRAM RAM│ │ ││ Audio RAM 8 КБ (Z80) │ └───┬──────┘ │ 512 КБ │ │ │└──────────┬───────────┘ │ └─────┬─────┘ └─────┬────┘ │ │ └──────────────┬─────┘ ┌─────┴──────────┐ │ │ │ │ │ ┌───────┐ ┌────┴────┐ ┌────▼──────┐ ┌─────▼─────┐ │ │ Ricoh │ │ ASIC │ │ VDP │ │ Z-80 │ │ │ PCM ├─────┤ GFX │ │ ┌───────┐ │ │ YM2612 │ │ └───┬───┘ └────┬────┘ │ │64KVRM │ │ │ SN76489 │ │ │ │ │ └───────┘ │ │ │ │ │ │ └─────┬─────┘ └──────┬────┘ │ │ │ │ │ │ │ ┌───────┴──────┐ │ │ ┌──┴───────┐ ┌────▼────┐ │ Привод │ │ └───┤RCA-кабель├────────► Микшер ◄─┤ CD-ROM │ │ └──┬───────┘ └────┬────┘ └──────────────┘ │ │ │ ┌────▼────┐ │ │ │ ТВ ◄──────────────────┼─────────────────────┘ └─────────┘ │
Подключение Mega-CD превращает консоль в две параллельно работающие системы. На стороне Mega-CD выполняется воспроизведение PCM и CD, соединённое напрямую с микшером[10]. Так же там есть ASIC с ускорением графики (rot/scal/misc) для конкуренции с играми наподобие Mario Kart. Две системы взаимодействуют через общую память (порт расширения) и аналоговое микширование аудио.
Разобравшись, как всё это работает, я ещё больше зауважал разработчиков Mega-CD. Похоже, добиться устойчивой работы такой конфигурации ужасно трудно, особенно когда дело касается синхронизации.
Архитектура Silpheed
Система Mega-CD выполняет рендеринг на телеэкран с тремя слоями. Два из них состоят из тайлов, они называются фонами (A и B), а третий — это передний план, состоящий из спрайтов.
Подчинённый CPU m68k записывает тайлы и карту тайлов для фона B, в то время как основной CPU занимается «отрисовкой» фона A, содержащего HUD, а также переднего слоя спрайтов.
Подчинённый CPU использует систему с двойным буфером, выполняя рендеринг в Word RAM в режиме L1. Пока основной CPU передаёт один буфер VDP (Video Display Processor), подчинённый CPU рендерит следующий кадр в другой буфер.
В неинтерактивных сценах для звука используется только чип Ricoh приставки Mega-CD, генерирующий музыку PCM-качества. Во время интерактивных сцен Ricoh время от времени используется для воспроизведения аудиосэмплов PCM, а музыка проигрывается через YM2612.
Любопытный факт
Аудиотракт самой консоли Genesis (Model 1) невероятно сложен. Вывод Genesis, её передний разъём, должен быть физически соединён с входом RCA на задней части Sega-CD «кабелем микширования». Sega-CD микширует входящий линейный сигнал со своим собственным сигналом CD-DA + PCM. Получившийся результат напрямую подаётся на телевизор через ещё один RCA-кабель!
Продуманные архитектурные решения
Большинство FMV-игр выглядело плохо, потому что разработчики использовали подход «сверху вниз» и пытались уместить настоящий фильм на крошечный CD-ROM в устройстве со слабым CPU. Для этого приходилось уменьшать размеры видео, мириться с артефактами сжатия и дизерингом.
При разработке Silpheed компания Game Arts выбрала противоположный подход. Она начала снизу, разрабатывая игру на основе ограничений системы. Ей удалось выбрать идеальный баланс: полигоны с плоским затенением, всего 16 цветов, отсутствие затенения по Гуро и минимальный дизеринг.
Такой подход ни за что бы не позволил добиться успеха, если бы не талантливые художники Game Arts, способные довести дело до конца на основании принятых решений (особенно это касается ограниченного количества цветов).
Любопытный факт
В случае игр на CDROM для PC ситуация была иной: благодаря более мощным CPU (DX4-100) в них можно было использовать гораздо более качественные кодеки. В некоторых играх с хорошим финансированием, например, в Command & Conquer, Crusader: No Remorse и Wing Commander III (4 CD-диска!) FMV-ролики невероятно улучшили сторителлинг.
Проблема пропускной способности
Главная проблема FMV заключалась в пропускной способности приводов. Данные необходимо было извлекать с CD-ROM, распаковывать при помощи процессора в изображение, после чего это изображение передавалось на видеоэкран, чтобы добраться до телевизора. Mega-CD плохо подходила для всех трёх этапов:
Проблема карт тайлов
На первый взгляд, есть ещё одна проблема. Без буфера кадров рендеринг должен представлять собой неуклюжий процесс отрисовки 768 тайлов размером 8×8 пикселей. Затем тайлы выстраиваются на экране при помощи карты тайлов размером 32×28 тайлов (традиционно в терминологии Genesis называемой nametable). В результате получается изображение 256×224 пикселя.
Три простых способа экономии пропускной способности
Простейший способ экономии пропускной способности — снижение размера видео. В Silpheed тоже используется этот трюк, но в небольшой степени: только окрашиванием в чёрный верхних и нижних строк тайлов (суммарно 16 строк). Это выглядит практически как художественное решение, ведь соотношение сторон получается почти как в кинотеатре!
Второй способ экономии — уменьшение частоты кадров. В Silpheed максимум используется 15fps, а в некоторых сложных сценах частота падает до 7,5fps.
Третий способ — это сжатие. Для него катсцены и фоновое видео обрабатываются по-разному.
Сжатие видео
В Silpheed не применяется дельта-сжатие. Каждый кадр видео автономен. В кадре содержатся все нужные ему тайлы и карта тайлов для размещения тайлов на экране.
При таком описании кажется, что сжатие вообще не применяется. Но здесь неуклюжая система карт тайлов становится перспективным источником оптимизаций. Возьмём для примера кадр 44 из катсцены «Game starts».
Если добавить сетку с шагом 8×8 пикселей, то можно заметить, что изображение обладает любопытными свойствами. Например, многие тайлы состоят из одного сплошного цвета.
Эта особенность активно задействуется в формате видео Silpheed. Кодировщик генерирует только один из 15 тайлов со сплошной заливкой, а затем многократно ссылается на него в карте тайлов. В этом кадре из 896 тайлов 456 ссылаются на одни и те же 15 одноцветных тайлов. Так мы уже снизили потребление пропускной способности примерно на 50%.
На нижнем изображении показаны оставшиеся тайлы, состоящие из нескольких цветов. Для них у Silpheed тоже припасён трюк.
Использование ASIC Mega-CD для распаковки
С 456 тайлами мы уже разобрались, осталось 440 (см. изображение ниже). У некоторых из этих тайлов тоже есть интересное свойство: они состоят только из двух цветов.
ASIC приставки Mega-CD обеспечивал расширенные графические возможности. Самые известные из них — вращение и масштабирование (позволяющие конкурировать с играми наподобие Mario Kart для Super Nintendo). Гораздо менее известна функция «Font bit»[11]. Как понятно из названия, она должна была обеспечивать быстрый двухцветный рендеринг кандзи/текста. На основании трёх байт регистры шрифтов генерируют 16 нибблов (8 байт), то есть две полных строки тайла 8×8. Работает это следующим образом.
-
Записываем два 4-битных индекса палитры в регистр исходного цвета ($FF804D).
-
Цвет A = пиксели, генерируемые, когда бит равен 0
-
Цвет B = пиксели, генерируемые, когда бит равен 1
-
-
Записываем в $FF804E 16-битный паттерн битовой карты.
-
Каждый бит означает один пиксель.
-
16 бит интерпретируются, как две строки по 8 пикселей.
-
Бит 0 выбирает цвет A.
-
Бит 1 выбирает цвет B.
-
-
ASIC разворачивает 1-битный паттерн в 4-битные пиксельные данные.
-
Считываем сгенерированные данные тайлов из $FF8050-$FF8056.
На основании трёх байтов регистры шрифтов генерируют 16 нибблов (8 байт). Это позволяет сэкономить ещё 37% пропускной способности от оставшихся 50%. И это ещё не учитывая время CPU, сэкономленное благодаря отсутствию необходимости маскирования битов для записи нибблов.
На верхнем изображении показано 234 тайла, состоящих из двух цветов. Они сгенерированы регистрами шрифтов ASIC. Снизу показаны оставшиеся: 206 сырых тайлов, которые хранятся в кадре в виде «сырых» нибблов 8×8.
Сжатие карты тайлов
У каждого кадра есть карта тайлов, которая тоже сжимается. Обычно 768 тайлов занимали бы 768x 10 бит = 960 байт. В схеме сжатия применяется ещё одно свойство изображения, а именно линейное увеличение индексов в карте тайлов (ниже показан пример карты тайлов 8×2).
0 1 2 3 4 5 6 78 9 A B C D E F
Карта тайлов хранится в виде 768-битной битовой карты (96 байт), где 0 означает «автоматический инкремент», а 1 означает чтение непосредственного значения. На практике, этот трюк снижал занимаемое место примерно на 30% (96 + 556-байтная полезная нагрузка = 652 байт).
Фрактальный уровень
Если вы посмотрите сториборд, то увидите, что на двух уровнях (Stage 1 и Stage 10) есть сложные текстуры (которые разработчики в интервью называли «фракталами»). Эти последовательности очень сложно сжимать; настолько, что для них использовались все тайлы в сыром формате без каких-либо трюков. Единственный способ их реализации заключался в снижении частоты кадров до 7,5fps.
Трюк с палитрой
Посмотрев на геймплей игры, можно заметить, что в лазерных лучах и взрывах не используется сплошной цвет, они многоцветные. Этот эффект достигается резервированием четырёх цветов в конце палитры и сдвигом их в каждом кадре основным процессором m68k.
Из-за этого художникам приходилось проектировать геймплей, задействуя всего 12 цветов (в катсценах применяются все 16 цветов, потому что в них нет лазерных эффектов)!
Ссылки
ссылка на оригинал статьи https://habr.com/ru/articles/1059000/