![](https://habrastorage.org/webt/ut/82/xl/ut82xlgqptiw9edm6gnhjo9dsz0.jpeg)
В предыдущей части мы начали знакомиться с игровыми консолями пятого поколения, настоящим некстгеном своего времени. Сам этот термин пошёл в массы именно тогда: только-только выходящим на рынок новым консолям был посвящён американский видеоигровой журнал Next Generation, позже переименованный в NextGen.
История успеха консолей пятого поколения началась в 1993 году с консоли 3DO, но настоящая битва за внимание геймеров была впереди. Пятое поколение не только определило саму форму современных игр, но и смену главных действующих лиц — компаний, задающих тренды.
Сегодня рассмотрим две главнейшие платформы поколения, Saturn от некогда великой, но начинающей стремительно терять полимеры Sega, и PlayStation от новичка в индустрии видеоигр — Sony. Заодно узнаем кое-что про концептуальное противостояние квадов и треугольников, а также про необычные сложности в реализации эффектов полупрозрачности.
Sega Saturn (ноябрь 1994)
![](https://habrastorage.org/webt/ym/kh/co/ymkhco8xjqdmkylv5l0gnznsnrw.jpeg)
К началу 1990-х годов компания Sega являлась признанным лидером в области аркадных видеоигр и опытным разработчиком технологий трёхмерной графики. Сначала это были автоматы серии Super Scaler, использующие аппаратное масштабирование спрайтов, давшие миру игры Out Run и After Burner, потом — серия аркадных платформ Model 1, 2 и 3, явившая среди прочего Virtua Fighter, Daytona USA — игры, определившие целые жанры трёхмерных аркадных гонок и драк.
![](https://habrastorage.org/webt/t4/_t/il/t4_tilzpsjgllqqyo-ry8rtzid0.png)
В прошлый раз, в случае с весьма успешной системой четвёртого поколения, Sega по сути просто адаптировала свою аркадную System 16 для домашнего применения, создав её упрощённую и удешевлённую вариацию, сохранившую прежнюю, хорошо себя зарекомендовавшую на практике архитектуру.
![](https://habrastorage.org/webt/sx/om/4q/sxom4qs7czbpjd_igoweu8_cb1e.png)
Странным образом, когда настало время проектировать игровую систему следующего поколения, компания не стала задействовать имеющиеся технологии, а разработчикам компании при создании новой системы не удалось уловить заданный самой же Sega тренд на трёхмерную полигональную графику, равно как и учесть популярность жанра интерактивного кино.
![](https://habrastorage.org/webt/j-/ve/wh/j-vewhcznxikwj09pef0wj9rvzy.png)
В результате возможности консоли Sega Saturn представляют собой удивительный гибрид технологий прошлого и настоящего, теоретически обладающий неплохим потенциалом, но во многом использующий устаревшие подходы и фактически лучше всего справляющийся со спрайтовой графикой прошлых лет. Трёхмерная же графика формируется не самым тривиальным использованием не вполне предназначенной для неё аппаратуры.
В области звука, например, Sega решила использовать многоканальный синтезатор, способный на устаревающий FM-синтез и воспроизведение сэмплов, но не обладающий поддержкой сжатия аудио. Это решение, конечно, имеет свои интересные особенности, но на практике цифровые звуковые эффекты на платформе в среднем звучат заметно хуже, чем у главного конкурента, при одинаковом объёме звукового ОЗУ (512 килобайт).
![](https://habrastorage.org/webt/lf/0p/qx/lf0pqxvzgud3icmxhsklwi9qrfy.png)
Отсутствует в системе и аппаратная поддержка цифрового видео, из-за чего в играх применяются чисто программные кодеки типа Cinepak. Поэтому видеозаставки в части игр имели более низкое качество или меньший размер кадра по сравнению с PlayStation, а FMV-игры не получили такого широкого распространения, как на той же 3DO. В более поздних играх ситуация более-менее выровнялась, в частности, за счёт внедрения более качественного программного кодека TrueMotion.
В народе издревле ходит молва, что проигрыш Sega Saturn в битве лидеров пятого поколения связан с избыточной сложностью архитектуры, которая затрудняла программирование и требовала значительных усилий для эффективного раскрытия потенциала платформы. И хотя про причины довольно скромного коммерческого успеха нельзя что-то утверждать однозначно — на протяжении 1990-х годов Sega понаделала целую серию эпических ошибок в стратегии развитии своего консольного бизнеса — с утверждением про сложность архитектуры поспорить невозможно. Ведь даже просто объяснить устройство Saturn на пальцах крайне затруднительно.
Дело осложняется тем, что довольно богатая официальная англоязычная документация на эту весьма нетривиальную систему является весьма иносказательным переводом с японского, в большей части которого извлечение сути сказанного не представляется возможным. И я наверняка ошибусь в чём-нибудь, пытаясь изложить своё теоретическое понимание — из основных платформ именно с этой я на практике дела не имел.
▍ Архитектура
Для начала, у консоли не одно, а сразу два сердца — два центральных 32-битных процессора Hitachi SH-2 с архитектурой RISC, работающих на частоте 28 МГц, с доступом к общей памяти, в конфигурации мастер и подчинённый. Казалось бы — ура, подвезли параллелизм. Но на практике для получения вычислительных преимуществ в такой конфигурации требуется очень аккуратно планировать код и использование процессорного кэша, чтобы процессоры не конфликтовали за доступ к общему ОЗУ, и по большей части в играх эффективно работает только один процессор.
![](https://habrastorage.org/webt/j0/yi/je/j0yijecwy28go6cj4qmngn0rtmi.jpeg)
Хотя основное ОЗУ и общее для двух процессоров, но его тоже два, общим объёмом два мегабайта. Одно из них реализовано на более быстрой памяти SDRAM, а другое — на медленной DRAM. Процессоры поддерживают целочисленное умножение и деление с внутренним параллелизмом (делают по два умножения и два деления одновременно), но работает оно не так уж быстро. Это также создавало дополнительные сложности в эффективном использовании ресурсов системы.
К счастью, в дополнение ко встроенным математическим блокам двух основных процессоров, в системе есть ещё один процессор. Точнее это сигнальный процессор. Точнее их два. Они совершенно разные и имеют разное назначение. Первый, упомянутый выше, является частью System Control Unit (SCU-DSP), второй же управляет звуковой системой — Saturn Custom Sound Processor (SCSP-DSP).
SCU-DSP представляет собой оригинальный сигнальный RISC-процессор с 48-битным АЛУ и 32-битными регистрами, работающий на частоте 14 МГц. Он предназначен для быстрого выполнения однотипных вычислений над массивами данных, в основном геометрического характера — умножение матриц, проецирование вершин. Также он оснащён контроллером DMA для пересылки массивов откуда надо куда надо, пока кто надо пытается вычислить эти массивы.
Наличие SCU-DSP позволило получить приличную производительность в 3D графике — он способен выполнять операции T&L быстрее, чем SH2 — но ещё больше усложнило программирование: этот процессор возможно программировать только на ассемблере, а объём его встроенного сверхбыстрого ОЗУ составляет всего один килобайт для кода и столько же для данных. То есть максимальная длина программы для DSP всего 256 инструкций.
Второй DSP, Yamaha YMF292, является основной звуковой системы. Он реализует смешивание PCM-источников и FM-синтез. Управляется он ещё одним процессором, классическим Motorola 68EC000, работающим на частоте 12 МГц, и обладающим своими собственными 512 килобайтами ОЗУ.
Чего ещё может быть два? Правильно — два видеопроцессора, VDP1 и VDP2. И две видеопамяти! У каждого из видеопроцессоров Saturn есть собственная видеопамять. Память VDP1 имеет общий объём 1 мегабайт и делится на три части. Две части по 256 килобайт — два раздельных буфера кадра, что необходимо для местной реализации двойной буферизации, и одна часть на 512 килобайт — память текстур и дисплейных списков. Память VDP2 представлена ещё одним блоком объёмом 512 килобайт. Таким образом, расход видеопамяти на Saturn далёк от оптимального — текстуры нельзя расположить в буфере кадра. Предположительно, причиной этого странного решения стало достижение достаточной скорости работы: в такой конфигурации процессы отображения буфера кадра, растеризации полигонов и отображение слоёв плоской графики не конфликтуют за одновременный доступ к одной и той же памяти.
Дополнительного веселья добавляет то, что видеопроцессоры разработаны двумя разными компаниями — Hitachi (VDP1) и Yamaha (VDP2), имеют совершенно разные функции и идеологию, довольно сложную связь и хитроумные ограничения на взаимодействие между собой.
![](https://habrastorage.org/webt/iv/cn/jw/ivcnjwev950e_p1eqvlvwx_sr6s.png)
Всего же в системе можно насчитать порядка восьми процессоров и шести видов памяти различного функционального назначения — точное число варьируется в зависимости от способа подсчёта. При этом из-за относительно невысокой производительности как центрального процессора, так и средств визуализации, для достижения наилучших визуальных результатов на платформе было просто необходимо грамотно совмещать использование возможностей всех этих элементов, что удавалось очень немногим разработчикам.
▍ Видеопроцессоры
Видеопроцессор VDP1 выполняет функцию обработки так называемого слоя спрайтов. Он занимается растеризацией прямоугольных текстур из видеопамяти в буфер кадра, применяя к ним геометрические трансформации. В терминологии, принятой в документации на Sega Saturn, отображаемые с помощью VDP1 элементы называются просто «частью» или «деталью» (part). Это те самые квады, квадратные полигоны, о них мы особо поговорим чуть ниже — они играют роль и спрайтов, и при необходимости полигонов в трёхмерных играх. Помимо текстурированных квадов, части-детали могут быть квадами без текстур, а также линиями и прямоугольниками без заливки.
Буфер кадра VDP1 использует свои личные 512 килобайт видеопамяти, разделённые на две страницы — в одну идёт растеризация нового кадра, другая тем временем передаётся в VDP2 для последующего отображения на экране. В зависимости от разрешения, пиксели в буфере кадра могут быть представлены в 8-битном индексированном цвете или в 16-битном в формате RGB с пятью битами на канал. В зависимости от режима изменяется размер буфера кадра, а также доступные опции отрисовки, и, конечно, скорость работы.
Поддерживается довольно широкий перечень отображаемых разрешений, от 320 на 224 до 704 на 512 пикселей. Сам же буфер при этом может иметь организацию только 512 на 256, 512 на 512 или 1024 на 256 пикселей, то есть его пространство расходуется не очень эффективно. Один буфер должен помещаться в 256 килобайт, поэтому высокие разрешения доступны только в режиме 8-битного цвета.
В качестве источника поддерживается широкий диапазон размеров прямоугольных текстур и широкий набор глубины цвета: 4, 6, 7 (да, бывает и такое), 8 и 16 бит. Один пиксель при этом занимает половину, один или два байта в памяти, а ширина текстуры должна быть кратной 8 пикселям. Вся исходная графика вынуждена умещаться в ОЗУ размером 512 килобайт, а поддержка иных способов сжатия, помимо понижения разрядности индексов цвета, отсутствует.
![](https://habrastorage.org/webt/cm/jn/kl/cmjnklddad_i-1hq3n-udxalers.jpeg)
Нужно обратить внимание на крайне специфическую особенность растеризатора: в зависимости от выбранного режима, он оперирует либо индексами цвета, либо 15-битными RGB-значениями (16-битный режим). И о ужас, даже в 16-битном режиме пиксели также могут быть представлены в виде 15-битного значения индексированного цвета. Да, нормальные человеческие RGB-пиксели могут быть перемешаны в одном буфере с бесчеловечными индексированными. Зачем это понадобилось? Дело в том, что память палитр находится внутри VDP2, а VDP1 к этой памяти обратиться никак не может, и, соответственно, во время растеризации цветовые данные для индексированного цвета недоступны.
В 16-битном RGB-режиме буфера доступны особые режимы отображения: тень и маска, затемнение исходных цветов, полупрозрачность, а также все эти режимы, но уже с шейдингом по Гуро. Эффекты рассчитаны на работу с 16-битным же RGB-источником, и не будут применены к пикселям буфера кадра, имеющими формат индексированного цвета, так как на этапе растеризации невозможно получить RGB-значения для таких пикселей. Но формат источника эти функции никак не проверяют, что в теории может оказаться полезным для весьма хитроумных визуальных эффектов.
На выходе VDP1 выдаёт поток пикселей из своего буфера кадра. Пока VDP1 занят рисованием нового содержания в одну страницу буфера кадра, VDP2 забирает пиксельный поток, идущий из второй страницы. В нём уже нет информации о принадлежности этих пикселей тому или иному спрайту. VDP2 может только судить о режиме цвета полученного значения: если старший бит 16-битного слова установлен, это RGB значение, иначе — индексированный цвет, и его нужно преобразовать в RGB при помощи палитры.
Видеопроцессор VDP2 несёт функцию обработки фоновой графики, занимаясь формированием плоских слоёв фона, официально называемых «сценами». Эти слои устроены подобно классическим тайловым слоям на консолях предыдущих поколений и работают совершенно независимо от VDP1. Всего может отображаться четыре плоских слоя и один слой с трансформацией и вращением, подобный Mode 7 на Super Nintendo, или же два таких псевдо-3D слоя без плоских слоёв.
Другая важнейшая функция VDP2 — преобразование индексированного цвета в собственно RGB, а также реализация полупрозрачности. Графика фона не попадает в буфер растра VDP1, к которому на этом этапе отображения просто нет доступа. Она формируется на лету и складывается с пиксельным потоком, получаемым из VDP1, согласно настройкам приоритетов, прямо в момент прохода луча развёртки по экрану.
Палитры и цветовая математика VDP1 работают в 15-битном и 24-битном цвете, в зависимости от выбранного режима работы палитр. Для 24-битного цвета на один цвет расходуется сразу четыре байта памяти палитр, что уменьшает количество палитр вдвое.
Центральные процессоры и дополнительный DSP-процессор с контроллером DMA также имеют доступ к буферу растра VDP1 — только к той её части, что в момент обращения является теневой и не отображается на экране — и при необходимости могут программно дорисовать туда что-нибудь. Или (спойлер) считать оттуда что-нибудь.
Несмотря на все архитектурные ухищрения, растеризатор VDP1 имеет довольно низкую производительность, особенно в режиме RGB-полупрозрачности, который в шесть раз медленнее обычной отрисовки. Поэтому полигональный бюджет сцен довольно ограничен, и для получения визуально интересной картинки разработчики были вынуждены креативно применять псевдотрёхмерные слои фона VDP2, добавляя ими детализации на экране.
![](https://habrastorage.org/webt/wz/vs/ol/wzvsol-biwi7iufhprq2khnwaeg.png)
Например, с их помощью отображается бесконечная поверхность земли в Panzer Dragoon, а в трёхмерных драках один слой изображает текстуру пола, тогда как несколько плоских слоёв фона — задний план с параллаксом.
▍ Ква-квады
Настало время поговорить о пресловутых «квадах», то есть о квадратных, а точнее говоря, четырёхугольных полигонах. Эта технология в середине 1990-х являлась альтернативой применяемым ныне повсеместно полигонам треугольной наружности.
Разница между этими сущностями вовсе не в одной лишней вершине, как можно было бы подумать — PlayStation тоже поддерживает отрисовку полигонов с четырьмя вершинами. Главное отличие в том. что системы на основе квадов и треугольников реализуют диаметрально противоположные подходы к растеризации текстурированных геометрических примитивов.
Эти противоположности так и называются: прямое и инверсное текстурирование. Прямое — в смысле от пикселей текстуры (текселей) к пикселям экрана, инверсное — от пикселей экрана к текселям. Иначе говоря, при прямом текстурировании для каждого текселя вычисляется, в какой пиксель экрана он попадает, а при инверсном, наоборот, для каждого пикселя экрана вычисляется, какой тексель в него попадает.
![](https://habrastorage.org/webt/ss/qa/ma/ssqamax3ua1iae93lq8uc4jxgcm.png)
Для растеризации треугольных полигонов используется инверсное текстурирование способом так называемой построчной отрисовки (scanline rendering). Для отрисовки полигона его грани сначала проецируются в пространство экрана, после чего построчно и линейно перебираются все экранные пиксели, в которые попал полигон. Таким образом, на экране получается линейный цикл, в памяти же происходит перемещение указателя выборки по текстурным координатам.
![](https://habrastorage.org/webt/k6/wn/yf/k6wnyffhpdazcav11pmsntdjln8.png)
Для ускорения вычислений это может быть линейный шаг, и тогда получается аффинное текстурирование с характерными искажениями, которыми славится графика на первой PlayStation. Или же может использовать честное перспективно-корректное текстурирование, требующее более сложной математики, в которой учитывается глубина каждой строки полигона. Отличным компромиссом является линейно-кусочная перспективная коррекция, как в программном растеризаторе игры Quake, дающая хороший баланс скорости и точности. Однако, использование квадов тоже является неплохим компромиссом, если перспективная коррекция невозможна — при аффинном текстурировании квады дают меньше искажений на плоских поверхностях, чем треугольники.
![](https://habrastorage.org/webt/og/88/y1/og88y1s29e258dla0rhngjizqc4.png)
Растеризация же квадратного полигона, соответственно, происходит прямым методом: линейный проход происходит по всем текселям прямоугольной текстуры, и для каждого из них рассчитывается расположение пикселя на экране. При этом возникает проблема разрывов: пиксели на экране не обязательно будут находиться по соседству, и растеризатор должен заполнить этот разрыв с помощью алгоритмов, аналогичных рисованию линии между двумя точками. Другой недостаток — многократная перезапись пикселей, в которые может оказаться спроецирован один и тот же тексель. Есть и достоинства: линейный проход по текселям позволяет использовать техники сжатия, подобные RLE, а также хорошо совместим с технологией кэширования памяти.
Как можно заметить, инверсное текстурирование проще в реализации, так как не требуется решать проблему разрывов и перезаписи пикселей. К тому же, эта техника позволяет при желании растеризовать полигоны любых других выпуклых форм, хотя на практике ограничиваются только треугольниками, как единственной всегда гарантированно выпуклой формой. К тому же помимо отображения нужно вычислять нормали и текстурные координаты, что для многоугольников сложнее.
![](https://habrastorage.org/webt/qn/pb/_g/qnpb_gjbn2wwl1kk1zh24kz1kbg.png)
Дополнительной особенностью реализации квадов на 3DO и Saturn является отсутствие такой сущности, как текстурные координаты, что не прибавляет удобства в использовании — использовать стандартные техники текстурирования, когда все элементы одной модели или персонажа собраны в одну текстуру, не получится.
Так или иначе, исторически квады были реализованы только в трёх крупных платформах середины 1990-х — на 3DO, в видеокарте NVidia NV1 и на Sega Saturn, и дальнейшего развития эта технология практически не имела.
▍ Полупрозрачность
Как ни странно, ни специфическая поддержка полигонов, ни особенности архитектуры, ни сложность в достижении хорошей производительности не помешали Saturn вполне уверенно конкурировать с PS1, обеспечивая примерно равное качество визуала в играх, а местами и лучшее: хотя полигонов на экране и меньше, и текстуры также не особо перспективно-корректны, и вообще их маловато, зато они хотя бы не плывут прямо перед носом игрока.
![](https://habrastorage.org/webt/nb/5x/x0/nb5xx0q2rndcnbdzu9njf6r1kte.png)
Наибольшее же отличие между этими двумя платформами и хорошо визуально заметная слабина Sega Saturn проявилась в довольно неожиданном месте. Речь идёт о реализации полупрозрачности, то есть блендинга.
Несмотря на преувеличенные слухи, родившиеся из созерцания игроками реальных игр для Saturn, полупрозрачность консолью поддерживается, причём сразу несколько видов — и на стороне VDP1, и на стороне VDP2. Однако, практическое применение этих видов полупрозрачности содержит множество нетривиальных моментов, что и проявилось в выходивших играх: многие разработчики даже не пытались разобраться в этой головоломке и шли по пути наименьшего сопротивления.
Настоящая полупрозрачность на стороне VDP1, позволяющая наложить друг на друга несколько полигонов или спрайов, поддерживается только в режиме 15-битного RGB-цвета. Доступен всего один вид блендинга, 50:50 между пикселями буфера кадра и текстуры — RGB-значения приёмника и источника делятся сдвигом пополам и складываются. Так как этот режим требует, чтобы и буфер кадра, и текстура имели 16-битный формат, а объём видеопамяти для текстур составляет всего 512 килобайт, этот режим имел крайне ограниченное применение в играх.
![](https://habrastorage.org/webt/wo/uc/9u/wouc9uzm_ztmke3ckrh4polwzvg.png)
Зная, что растеризация квадами склонна к перезаписи одних и тех же пикселей, вы могли бы ожидать, что это приводит к проблемам с полупрозрачностью — пиксели могли бы многократно накладываться сами на себя, изменяя цвет нежелательным образом. И да, в режиме RGB-полупрозрачности на VDP1 именно это и происходит, что ещё больше ограничивает применимость эффекта.
В режиме же растеризации в индексированном цвете, применяемом в 2D-играх на Saturn, любой полупрозрачный квад, который VDP1 отрисовывает в буфер, просто перезаписывает пиксели в буфере кадра, затирая предыдущий индекс или RGB-значение. Таким образом, цвета спрайтов никак не могут быть смешаны между собой — в каждом пикселе содержится только один индекс, записанный последней операцией растеризатора, обратившейся к этому пикселю.
Фактическая же полупрозрачность для индексированного цвета реализуется в VDP2 во время сложения слоёв. Получив пиксель с признаком индексированного цвета, VDP2 преобразует его в RGB-код. В памяти палитр помимо собственно значений RGB присутствует один дополнительный бит, указывающий на необходимость применения к пикселю этого цвета особых эффектов. В частности, VDP может сделать его полупрозрачным по отношению к нижележащим слоям фоновой графики, также простым смешиванием 50:50.
![](https://habrastorage.org/webt/vf/1b/ns/vf1bns6heropr2wboesngje7twa.png)
Но слой спрайтов, они же квады, они же полигоны и запчасти-детали, с точки зрения VDP2 всего один. А значит, полигон или спрайт может быть полупрозрачным только по отношению к слоям фона (если они вообще есть), но не к нижележащим спрайтам или полигонам. Это даёт занимательный визуальный артефакт, когда на экране пересекается два спрайта, один из которых полупрозрачный: второй спрайт под ним пропадает, а фон продолжает просвечивать. Каноничный пример этого эффекта — плащ Николь, одной из героинь в игре Guardian Heroes.
![](https://habrastorage.org/webt/2q/qv/fy/2qqvfyogsjdpc6wvtemorv2q6ba.png)
Помимо этих двух режимов, VDP2 также поддерживает полупрозрачность между слоями фона. Эта возможность предоставляет большее число градаций прозрачности, чем только 50:50, позволяя, например, наложить какой-то бледненький слой полупрозрачных облаков поверх картинки. Эффекты полупрозрачности такого рода встречаются в играх для Saturn повсеместно, и смотрятся очень даже красиво.
![](https://habrastorage.org/webt/cc/ex/yz/ccexyz0ux-jhg9qofw4ah0jsmj0.png)
В качестве альтернативы, позволяющей хоть как-то наложить два спрайта друг на друга в режиме индексированного цвета, в VDP1 предусмотрен режим растеризации с пропуском пикселей: в буфер кадра рисуются не все пиксели, а через один в шахматном порядке. Таким образом, через вновь нарисованный объект становятся видны нижележащие пиксели, и хотя ЭЛТ экраны телевизоров того времени сглаживают переходы цвета, на современных экранах и в эмуляторах это смотрится просто ужасно. Однако, делать так проще всего, и многие разработчики обходились лишь этой опцией. Что интересно, скорость растеризации при её использовании не возрастает.
![](https://habrastorage.org/webt/ia/qd/nw/iaqdnwwdyuie7x-z7aknancgacm.png)
Хотя реализация полупрозрачных объектов в трёхмерных играх. сравнимой с конкурирующими платформами, и крайне осложнена, она не полностью невозможна. Например, разработчики Burner Rangers нашли решение. Однако, простым его назвать никак не получится:
- С помощью VDP1 в буфер кадра выводятся все полупрозрачные элементы сцены в половинном разрешении
- Те части, которые не должны быть видны, будучи перекрытыми более близкими объектами, стираются (рисуются чёрные силуэты)
- Данные из буфера кадра копируются в память VDP2 с помощью DMA
- Буфер кадра VDP1 очищается, в него рисуется уже нормальная сцена без полупрозрачных элементов
- Буферы переключаются, и VDP2 накладывает полупрозрачные элементы как обычный слой фона во время отображения буфера
▍ Эстетика и цифры
Из вышесказанного можно вывести наиболее узнаваемые элементы визуальной эстетики Sega Saturn. Главным образом это повсеместно встречающаяся пиксельная сетка вместо честной полупрозрачности в трёхмерных играх. Из вторичных признаков — стабильные, хотя и не очень перспективно-корректные текстуры и полигоны, часто повышенное разрешение, но с простым плоским освещением. В играх регулярно встречаются большие бесконечные 3D-плоскости, вокруг которых строится окружение — своего рода Mode 7 с полигональными объектами.
![](https://habrastorage.org/webt/dg/et/ng/dgetngj0ydjxeizyfwa-b9lrp3s.png)
Что касается цифр, официальные источники заявляют много различных значений, среди которых, например, 300000 полигонов в секунду с текстурами и освещением. Фактически же в реальных играх наблюдаются гораздо более скромные цифры порядка 20000-60000 полигонов.
При этом из-за сильно ограниченного объёма видеопамяти и не самых развитых возможностей для оптимизации её расхода, игры используют не очень большое количество малоцветных текстур небольшого размера, а часть полигонов и вовсе обходится только лишь раскраской по Гуро.
Sony PlayStation (декабрь 1994)
Несмотря на дебют на новом для себя рынке, Sony включилась в воскресную схватку двух йокодзун во всеоружии, предусмотрев достаточно эффективные решения для всех трендовых задач — и быстрой трёхмерной графики, и красивого пиксельного 2D, и интерактивного кино. Как говорится, всем сёстрам по серьгам. И хотя для достижения оптимальной производительности было срезано несколько углов, заметная потеря качества визуализации 3D не стало критичной — зато была обеспечена и скорость, и простота использования.
![](https://habrastorage.org/webt/eg/hv/e9/eghve9wzny2hfeapkhejpvordf8.jpeg)
Как вы уже слышали из каждого утюга, однажды Sony разработала звуковую систему для Super Nintendo (1990), а впоследствии являлась главным партнёром Nintendo в разработке CD-дополнения Super NES CD-ROM. Впрочем, это дополнение представляло собой именно CD-привод и ничего больше. Думаю, нет смысла пересказывать уже изрядно остывшую сенсацию с нахождением и изучением одного из прототипов этого устройства, несущего на борту надписи Nintendo и PlayStation. Важно, что несмотря на наличие действующих договорённостей, Sony решила не разыгрывать эту карту, и отказаться от выпуска этого устройства в пользу полностью своей собственной разработки.
![](https://habrastorage.org/webt/yq/am/bq/yqambqbql9racyatt0pf-qgihdk.jpeg)
Разработка полностью самостоятельной, значительно более сложной и мощной консоли началась в 1992 году, и всего лишь через два года новая платформа вышла на японский рынок под названием Sony PlayStation. Важно отметить, что её внутреннее устройство не имело совершенно ничего общего с технологиями, используемыми Nintendo, а значит, непосредственного влияния предыдущий проект на судьбу нового не оказал. Но, возможно, участие в проектах Nintendo дало Sony необходимый опыт и понимание нужд разработчиков игр, чтобы в столь короткие сроки создать собственное, действительно оптимальное и эффективное решение.
Я считаю, что именно простота, понятность и лаконичность архитектуры, позволяющей получить достаточную производительность без применения хитросплетения десятка процессоров, стала одним из ключевых факторов успеха платформы. Со мной согласен и Джон Кармак. Рассказывая о своём опыте портирования Doom на Atari Jaguar, он сравнивает архитектуру этой консоли с PlayStation, и говорит: «чем хороша PlayStation — она программируется просто как один процессор с одним быстрым ускорителем».
That is why Playstation kicked so much ass for development — it was programmed like a single serial processor with a single fast accelerator.
— John Carmack (slashdot.org)
▍ Архитектура
Хотя в архитектуре PlayStation при желании тоже можно насчитать изрядное количество вычислительных элементов, дело не в том, сколько их, а в том, насколько удачно выбрана схема их взаимодействия. И в этом плане всё вышло очень хорошо: все подсистемы имеют чёткую роль и разделение, выполняя свою функцию как чёрный ящик, не требуя углубления в детали типа циклов доступа к памяти и тактов текстурного блока.
![](https://habrastorage.org/webt/zj/e8/x6/zje8x6hr3xzypiuozavhmhqucu0.png)
Система построена на одном 32-битном RISC-ядре архитектуры MIPS R3000, работающем на частоте 33 мегагерца. Процессор имеет кэш инструкций объёмом 4 килобайта, но у него нет кэша данных — вместо него скрэтчпад на 1 килобайт. Основная память представлена 2 мегабайтами EDO DRAM, с которой работает только процессор и непосредственно подчинённые ему компоненты, и никто ему не мешает — в частности, нет разделения времени доступа к памяти с видеопроцессором.
Физически процессор является частью системы на чипе производства LSI, в которой также реализовано два сопроцессора — CP0, представляющий собой контроллер скрэтчпада, и CP2, векторный процессор для оптимизации вычислений стадии T&L — он также известен под названием Geometry Transform Engine (GTE).
Небольшое отступление: часто встречается непонимание функции векторного процессора, ведь речь идёт про 3D, а его название наводит на мысли про «векторную» графику. Но на самом деле речь идёт просто об эффективном применении серии вычислений к последовательности однотипных данных, т.е. к вектору в математическом смысле. Например, применение операции проецирования вершин из 3D пространства в пространство экрана к массиву этих самых вершин.
Также на одном кристалле с основным процессором расположен декодер макроблоков MDEC. Все элементы этой системы выполняют вычисления исключительно с фиксированной точкой, сопроцессор CP1 для вычислений с плавающей точкой в системе не реализован.
![](https://habrastorage.org/webt/hj/0p/q2/hj0pq2g3kotvdao4inmsb4ytrxq.jpeg)
Звуковая система и контроллер CD-ROM также выполнены в виде отдельных подсистем с собственным ОЗУ, выполняющих строго фиксированный набор функций. Звуковой процессор занимается смешиванием звуковых каналов, применением эффектов и распаковкой ADPCM-звуков на лету. Звуки хранятся в его личных 512 килобайтах памяти. Это не программируемый процессор, подобный тем, что встречались в четвёртом поколении консолей — задания по проигрыванию тех или иных звуков с нужными параметрами ему передаёт центральный процессор.
Контроллер CD-ROM занимается чтением запрошенных секторов диска в собственный 32-килобайтный буфер. Передачей данных между всеми компонентами системы занимается 7-канальный контроллер DMA, имеющий выделенные каналы для каждого из компонентов.
Процессор, используя GTE, обрабатывает данные трёхмерной сцены, производит необходимые трансформации вершин и расчёт освещения, Z-сортировку — у системы нет попиксельного Z-буфера — и отсечение. Готовый поток треугольников передаётся GPU, который в архитектуре системы играет роль растеризатора.
▍ Видеосистема
Видеосистема консоли поддерживает довольно широкий набор разрешений экрана, от 256 на 240 до 640 на 240, режимы с чередованием строк для удвоенного вертикального разрешения. В большинстве игр использовалось разрешение 320 на 240.
Поддерживается 15-битный (RGB555) и 24-битный цвет (RGB888), причём в 24-битном режиме пиксель действительно представлен тремя, а не четырьмя байтами. Однако, аппаратный растеризатор консоли работает исключительно в 16-битном режиме, поэтому применение 24-битного режима за редкими исключениями ограничивалось только полноэкранными видеозаставками.
Система имеет выделенную физически видеопамять объёмом один мегабайт. В ней располагается один или два буфера кадра, а также текстуры и палитры. Все они имеют одинаковый формат и хранятся в общем пространстве координат с незначительными ограничениями на расположение. Буфер кадра — это просто выбранная прямоугольная область внутри видеопамяти, с размером, соответствующим разрешению экрана. Растеризатор одинаковым образом может работать с любым источником и приёмником внутри этой памяти, что натуральным образом реализует возможность рендера в текстуру.
![](https://habrastorage.org/webt/4a/mq/fo/4amqfoqt0fktmfdrhygn5mh6f3o.png)
Текстуры всегда имеют размер 256 на 256 пикселей и могут храниться в форматах 4 и 8 бит на пиксель в индексированном цвете и в формате 16 бит на пиксель в RGB555. Для работы с текстурами меньшего размера предусмотрена установка квадратных регионов, внутри которых зацикливаются текстурные координаты. Палитры для индексированного цвета также хранятся в видеопамяти в формате 16-битных текстур размером 16 на 1 или 256 на 1 пиксель.
![](https://habrastorage.org/webt/kp/3-/y9/kp3-y9tidve0b_5svpzrn8zkeju.png)
Необычной особенностью консоли является нелинейность яркости для значений каналов RGB555 — больше градаций высокой яркости и меньше низкой. Половинная яркость представлена значением 8 из диапазона 0..31. Другим необычным моментом является то, что полностью чёрный цвет 0x0000 в палитрах и текстурах зарезервирован как прозрачный, а значит, полностью чёрный цвет невозможно использовать в текстурах. Вместо него применяют почти чёрный цвет, с единичкой в любом из цветовых каналов, но из-за нелинейной яркости отличие от полностью чёрного заметно визуально.
Растеризатор консоли способен отрисовывать линии, закрашенные или текстурированные треугольные и четырёхугольные полигоны, быстро копировать прямоугольные растровые изображения без лишних преобразований (спрайты), выполнять освещение по Гуро и различные варианты блендинга. При этом никакой фильтрации текстур не предусмотрено, а также полностью отсутствует мипмаппинг и перспективная коррекция. Также растеризатор не поддерживает субпиксельную точность, из-за чего возникает характерное «желеподобное» пиксельное дрожание граней полигонов при перемещении камеры.
Характерное искажение текстур трудно передать статичными скриншотами
Для достижения высокой производительности растеризации на PlayStation применяется исключительно аффинное текстурирование, которому свойственны сильные искажения текстур на полигонах большой площади. Эти искажения можно повсеместно наблюдать в играх для платформы, они стали наиболее узнаваемым её атрибутом. Особенно это проявлялось в ранних играх и в играх гоночного жанра, где полигоны поверхности дороги регулярно приближались к камере широкой частью, что крайне сильно искажало текстуры дорожной разметки.
![](https://habrastorage.org/webt/ro/wl/zo/rowlzoi3ehrcwvbokagkpciiwwm.gif)
Минимизировать заметность этого артефакта можно за счёт программной тесселяции — разбиения крупных полигонов на набор более мелких, на которых искажения проявляются не так сильно. Такая техника встречается даже в самых ранних играх для PlayStation, хотя использовать её действительно эффективно разработчики научились ближе к концу жизненного цикла консоли.
![](https://habrastorage.org/webt/oe/oi/wq/oeoiwqr8pkueb6mhj52dcsphnou.png)
Так как растеризатор работает в 15-битном цвете, этой точности может не хватать при операциях блендинга и освещения по Гуро. Тогда задействуется опциональный упорядоченный дитеринг 2x2 пикселя. Дитеринг всегда применяется к линиям, к текстурированным полигонам только для освещения и блендинга, и никогда не применяется к прямоугольникам (спрайтам). Разработчики игр, как правило, не отключали эту опцию, из-за чего характерная шахматная сетка повсеместно встречается в играх платформы.
![](https://habrastorage.org/webt/0p/gh/nl/0pghnlv1nphz-17bow7dvtnitdm.png)
В системе присутствует аппаратный декодер макроблоков, MDEC, для эффективной распаковки видеороликов в формате Motion JPEG, работающим в 24-битном цвете. Процесс воспроизведения роликов включает передачу потока данных от контроллера CD-ROM в основное ОЗУ через DMA, декодирование данных с использованием MDEC и передачу готового кадра через DMA в видеопамять.
![](https://habrastorage.org/webt/zj/xx/01/zjxx01lcfgt9buusrgwdtqfxq-i.png)
Декодер обеспечивает хорошее качество и плавность видео. Его производительности хватает для воспроизведения потока в разрешении 320 на 240 с частотой 30 кадров в секунду, хотя, как правило, в играх она была ниже и составляла 15-20 к/сек — вероятно, для экономии места на диске. Хотя воспроизведение видео всё равно занимает некоторые вычислительные ресурсы системы, аппаратный декодер позволяет воспроизводить полноэкранное видео одновременно с игровым процессом, что применялось для ряда эффектных сцен в играх серии Final Fantasy.
Judge Dredd для PlayStation — крайне спорная игра, демонстрирующая удивительный микс из технологий FMV и полигональной графики
Выделенный характер видеопамяти означает, что доступ к ней имеет только видеопроцессор. Это означает, что центральный процессор не может программно рисовать в видеопамяти всё, что ему вздумается — он должен делать это через растеризатор, или же заниматься подобными делами в своей собственной памяти и передавать готовую картинку в видеопамять через DMA. Возможность динамического обновления содержимого видеопамяти за пределами воспроизведения видеороликов, судя по всему, использовалась разработчиками игр крайне редко, в основном для небольших анимированных текстур.
Довольно необычным моментом в истории платформы является внесение изменений в низкоуровневую реализацию видеосистемы в ревизии C, появившейся в конце 1995 года, через год после выхода платформы на рынок. Эта ревизия не соотносится с конкретным номером модели консоли. В ней изменён тип видеопамяти, с двухпортовой DRAM на более доступную SGRAM с совершенно другой логикой и таймингами доступа, а также обновлён растеризатор: улучшена логика применения 24-битного цвета при освещении по Гуро, приводившая в предыдущей ревизии к неэффективной работе дитеринга.
Демонстрация цветовых артефактов в Tomb Raider на ранней ревизии GPU
Визуально эти изменения проявились в играх в виде уменьшения бандинга цветов, более плавных цветопереходах, и незначительном изменении частоты кадров, которое в зависимости от игры может происходить как в сторону увеличения, так и уменьшения.
▍ Резюме
PlayStation безусловно обладает очень узнаваемой визуальной эстетикой. Суммируя вышесказанное, она состоит из огромного количества характерных признаков: дрожащих полигонов, плывущих текстур с сильно выраженной пиксельностью и малоцветностью, заметным шахматным дитерингом в большинстве трёхмерных игр. Зато этих полигонов много, она часто освещены по Гуро, и работают игры довольно бодро.
![](https://habrastorage.org/webt/hz/kp/rl/hzkprlq6v664fduscfve8wttywk.png)
Отдельной частью эстетики платформы является визуальный дизайн демонстраций её возможностей и контента на демо-дисках, входивших в комплект с консолью, а также прилагавшихся к журналу Official PlayStation Magazine (вышло около полусотни таких дисков). Я затрудняюсь проанализировать эти материалы, чтобы раскрыть секрет их стиля — скорее всего это дух эпохи второй половины 1990-х и MTV, но увидев эти ролики однажды, вы не ошибётесь.
Легендарный Demo 1 (1997) и весь контент на нём
Рекламные материалы, включая указанные ролики, заявляли производительность порядка 500000 текстурированных и освещённых полигонов в секунду, либо же 1500000 одноцветных без освещения. На упаковке же консолей заявлялась цифра 350000 без уточнений. Конечно, это пиковые значения, достигнутые в неизвестно каких синтетических тестах или маркетинговых упражнениях.
Игра Motorhead без всяких улучшайзеров. Работает на частоте 60 кадров в секунду, что обеспечивает идеально плавную картинку, но… только в режиме четырёх противников на трассе
Фактическая же производительность находилась на уровне примерно 100000 полигонов в секунду со всеми опциями. Тем не менее, она действительно была весьма достойной, за счёт чего на платформе можно встретить немало игр, работающих со скоростью 60 кадров в секунду, а средняя частота кадров составляла около 30.
Продолжение следует
История пятого поколения не закончилась противостоянием Sega и Sony. Всего через несколько лет ситуация изменилась, и борьба разгорелась с новой силой, теперь уже между новым лидером — PlayStation, а также изрядно задержавшейся с выходом новой консолью от Nintendo и домашними ПК с их новомодными 3D-ускорителями.
Поговорим об этом в третьей части. Скоро на ваших экранах!
«Графика древности» — это цикл статей, посвящённый детальному разбору разнообразных аспектов способов визуализации в видеоиграх прошлых лет, от самых истоков игровой индустрии до конца века, а также анализу технологических оснований, формирующих узнаваемую визуальную эстетику компьютерной графики различных исторических периодов. Предыдущие публикации цикла:
- Графика древности: от текста к видеоиграм
- Графика древности: легендарный Mode 7
- Графика древности: палитры, часть 1/2
- Графика древности: палитры, часть 2/2
- Графика древности: пятая волна. Новые технологии и 3DO (часть 1/4)
Продолжение следует!
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
![](https://habrastorage.org/webt/tp/sk/z-/tpskz-7w7a8e74isoowuep40xeg.png)