В предыдущих двух частях статьи (тут и тут) мы обсудили общие черты пятого поколения игровых консолей и подробно разобрали особенности первой тройки лидеров поколения — 3DO, Sega Saturn и Sony PlayStation.
Однако, всего лишь через три года после начала поколения в новейших графических технологиях домашней 3D-графики случилась новая революция, которая вполне могла потянуть на очередную смену поколений: переход от квадратных пикселей низкого разрешения к мутным пятнам высокой чёткости.
Изменились и лидеры. 3DO и Saturn постепенно ушли со сцены, PlayStation сохранила и укрепила свои позиции, а новыми весомыми игровыми платформами в индустрии стали консоль Nintendo 64 и домашние ПК, оснащённые графическими ускорителями. О них и будет сегодняшний рассказ.
Nintendo 64 (июнь 1996)
Чтобы показать всем кузькину мать и не оконфузиться перед конкурентами, Nintendo привлекла к разработке своей новой консоли компанию, которая съела не одну собаку
на продвинутой трёхмерной графике — Silicon Graphics (SGI). Последняя как раз создала достаточно недорогое графическое решение для игровых применений, и искала партнёра для выхода на рынок видеоигр. Сначала технология была предложена компании Sega, но из-за разногласий между американским и японским подразделениями случились заминка и отказ от сотрудничества. Тогда технологию предложили Nintendo, и она согласилась.
Маркетинговая видеопрезентация Project Reality
Так, в 1993 году стартовал Project Reality, продвигавшийся под названием Ultra 64, и, наконец, перед самым выходом на рынок переименованный в Nintendo 64. В результате совместных усилий получилась последняя, самая продвинутая система поколения. Она стоит особняком от предыдущей основной тройки лидеров и технически является скорее представителем условного пятого с половиной поколения, приближаясь к Sega Dreamcast (1998).
Теоретически Nintendo 64 предложила самую совершенную графическую технологию, ранее доступную только на рабочих станциях Silicon Graphics. В частности, система поддерживает аппаратное сглаживание текстур и антиалиасинг, буфер глубины, честный альфа-блендинг, и многое другое. Также она имеет наибольший объём оперативной памяти среди конкурентов.
Quake II на, представьте себе, PlayStation и Nintendo 64. Pick your poison!
На практике же необходимые для экономической эффективности упрощения аппаратуры, а также ряд не очень удачных технических и концептуальных решений привели к сомнительной ситуации, когда более простая, практически топорная визуализация на менее продвинутой PlayStation зачастую выглядела выигрышнее, обладая лучшей детализацией и плавностью анимации.
Другой проблемой системы стал выбранный Nintendo носитель в формате классического картриджа на микросхемах масочного ПЗУ. Его объём был значительно меньше, чем у ставшего новым стандартом компакт-диска (4-64 мегабайт против почти 700), что полностью исключило теряющий актуальность, но всё ещё представленный на рынке жанр FMV, анимированные заставки, а также потоковое аудио — игры были вынуждены рассчитывать на сэмплы и синтез звука в реальном времени. Только в поздних играх появились небольшие видеоролики и живые саундтреки.
Нужно отметить, что картридж Nintendo 64 устроен концептуально иначе, чем на системах предыдущих поколений, из-за чего все прежние преимущества этого формата были утрачены — мапперы и дополнительные процессоры ушли в прошлое. ПЗУ картриджа не проецируется в адресное пространство центрального процессора, а значит, хранящиеся в нём данные и код недоступны для прямого чтения и выполнения. При включении консоли специальный контроллер копирует первый мегабайт памяти картриджа в ОЗУ. Далее игра должна самостоятельно подгружать код и ресурсы в ОЗУ по мере необходимости.
С другой стороны, скорость работы интерфейса с картриджем значительно выше, чем у компакт-дисков (5-30 против 0.3 мегабайт в секунду), что позволяет даже ограниченно применять кэширование текстур с подгрузкой их из картриджа на лету, подобно динамическим текстурным атласам (т.н. «мегатекстура») современных игр, но всё же не исключает необходимость загрузок уровней и экранов меню. Впрочем, они происходят практически незаметно для пользователя и не имеют привычных по CD-консолям экранов «Loading».
Позже Nintendo попыталась исправить ситуацию с не очень удачным выбором носителя посредством выпуска внешнего дисковода для проприетарных магнитных дисков, 64DD. Это устройство вышло в 1999 году только в Японии, и не получило популярности. Главной проблемой нового формата был объём дисков — всего 64 мегабайта. Всего для 64DD было выпущено 9 игр.
▍ Архитектура
Это вторая система, с которой я имел практический опыт разработки кода. Однако, во времена её популярности, в конце 90-х, я с ней почти не сталкивался, и потому особо тёплых чувств не накопил. Работа с Nintendo 64, как, впрочем, и местная библиотека игр, понравились мне меньше, чем в случае с 3DO. Хотя и ничего плохого сказать про всё это я не могу — сделано профессионально и качественно, с умом и фантазией.
На первый взгляд, архитектура системы довольно красива и устроена даже проще, чем PlayStation. В ней можно насчитать ровно три процессора. Однако, есть в ней и несколько не очень приятных моментов, сильно затрудняющих и понимание, и использование. Особенно это касается попыток работать с железом без официального SDK, который успешно маскирует наиболее сложные моменты готовой реализацией сложного кода.
Nintendo 64 построена на 64-битном RISC-процессоре VR4300 производства NEC, работающем на частоте 93 МГц. Она обладает 4 мегабайтами общего ОЗУ на основе очень быстрой RDRAM (Rambus DRAM), в котором выполняется код основного процессора. Также туда загружаются необходимые ресурсы из картриджа, там содержится буфер кадра и происходит растеризация. Разумеется, процессор в этой ситуации имеет меньший приоритет чем видеосистема, но ситуация сглаживается наличием у центрального процессора нормального человеческого кэша L1.
Задачами генерации графики и звука может заниматься как сам центральный процессор, так и особый чип Reality Co-Processor, содержащий в себе ещё одно RISC-ядро, называемое Reality Signal Processor (RSP) и мощный аппаратный растеризатор Reality Display Processor (RDP). Специализированного геометрического процессора и звуковой системы у консоли нет, решение обеих этих задач возложено на RSP, хотя может выполняться и основным процессором.
RSP представляет собой несколько урезанный 32-битный вариант R4000, оптимизированный для векторных вычислений, и является краеугольным камнем системы, в котором сосредоточена как её мощь, так и весьма высокая сложность эффективного программирования. Этот процессор имеет собственную быструю раздельную оперативную память для кода и данных, IMEM и DMEM, имеющую объём по 4 килобайта каждая. В память IMEM загружается так называемый «микрокод», задающий исполняемую RSP роль в тот или иной момент времени, а в DMEM размещаются входные данные и результаты выполнения кода.
Основной задачей RSP является преобразование различных данных в формат RDP. В трёхмерной полигональной графике его роль сильно напоминает вершинный шейдер, только очень низкоуровневый: один из видов микрокода реализует внутри RSP аналог ступени конвеера T&L, трансформации и освещения, то есть преобразование входной 3D-геометрии и расчёт освещения. Речь, конечно, идёт о вершинном освещении по Гуро.
Растеризацией полигонов и прочими графическими операциями, а также формированием итогового изображения занимается RDP. Он занимается отрисовкой треугольников и прямоугольников (спрайтов), наложением и фильтрацией текстур, применяет цветовые операции. Поддерживается блендинг с содержимым буфера кадра, мап-мапы и антиалиасинг. Впервые в мире игровых консолей реализована полноценная аппаратная поддержка попиксельной Z-буферизации.
Может напрашиваться аналогия: раз RSP играет роль вершинного шейдера, значит RDP похож на пиксельный шейдер. Но это не так, RDP выполняет фиксированный набор функций с программированием на уровне установки нескольких различных режимов работы, наподобие функции glTexEnvi в конвейере OpenGL.
RDP поддерживает разрешения 320 на 240 и 640 на 480, и работает в 32-битном цвете, с поддержкой полноценного альфа-канала. В качестве источника изображений для растеризации поддерживаются текстуры в форматах RGBA с 16 и 32 битами (1 или 8 бит на альфа-канал), 16-битном YUV, 4-битные и 8-битные текстуры с RGB-палитрами, а также довольно необычный формат чёрно-белых текстур с альфа-каналом и без, которые могут быть полезны для разного рода масок и эффектов.
Главная проблема RDP — его исключительно маленькая память текстур, TMEM, имеющая объём всего 4 килобайта. Перед тем как RDP сможет отрисовать примитив с наложением текстуры, эта текстура должна быть загружена в TMEM специальными вызовами — иначе говоря, это не автоматический текстурный кэш.
Каждая текстура во время отрисовки должна размещаться в TMEM, а при использовании мипмапов — и все их уровни тоже. На практике это означает, что текстура в 16-битном RGB с мип-мапами будет иметь размер 32 на 32 текселя. В случае текстур с индексированным цветом TMEM делится пополам: в одной половине сама текстура, в другой её палитра. Переключение текстуры — очень накладная операция, которую следует избегать. Для отображения текстур большего размера требуется выполнять несколько операций отрисовки и загрузки TMEM, что в официальной документации предлагается выполнять полностью вручную.
Одной из самых интересных особенностей RDP является способ фильтрации текстур. Хотя текстурный блок и делает выборку четырёх соседних текселей, фактически интерполяция идёт только по трём из них, исключая диагонального соседа. Эта разновидность интерполяции называется трёхточечной, её часто путают с трилинейной, которая учитывает соседние мипмапы — такой у RDP нет.
Трёхточечная интерполяция придаёт сглаженным пикселям специфическую диагональную форму, которая при креативном применении даёт кажущееся повышение чёткости отдельных элементов. Разработчики игр учитывали эту особенность при подготовке текстур, и если сглаживать их обычной билинейной фильтрацией в эмуляторе, разница будет очевидна.
Другой особенностью системы является поддержка антиалиасинга. Однако, так как большинство игр работало в низком экранном разрешении, использование антиалиасинга приводило к излишней размытости картинки, что скорее являлось минусом, чем плюсом. Особенно учитывая, что включённый антиалиасинг снижал скорость растеризации.
▍ Микрокод
Микрокод — это ещё одна ключевая особенность системы: код, написанный на ассемблере RSP, для выполнения разнообразных задач векторного характера: проецирование и преобразование 3D-координат, передача дисплейных списков RDP, а также обработка звука — смешивание потока из различных источников для отправки на аудио-ЦАП.
Данный микрокод сложно написать и ещё сложнее использовать, так как объём памяти микропрограмм крайне мал — всего 1024 инструкции, а любой игре требуется как-то выполнять две параллельные задачи, ведь ей нужно и звук, и изображение. Поэтому требуется постоянно жонглировать микропрограммами, загружая то код для графических вычислений, то код для обработки звука, то ещё какой-нибудь другой.
Безусловно, можно полностью исключить работу с RSP и возложить все задачи на основной процессор консоли, который может самостоятельно взаимодействовать и с RDP, и со звуковым ЦАП, и даже с буфером кадра — при желании можно реализовать полностью программную растеризацию, не задействуя даже RDP. Но всё это очень сильно, просто катастрофически снижает производительность системы, лишая её всех преимуществ.
Проблема с микрокодом долгое время являлась критической и с точки зрения эмуляции платформы. Ранние эмуляторы перехватывали библиотечные вызовы SDK и выполняли собственную реализацию, поэтому эмулировать работу ядра RSP им не требовалось. Такое решение позволило создать первый работоспособный эмулятор платформы, UltraHLE, уже в 1999 году, но поддерживало очень ограниченный набор игр и требовало дорабатывать эмулятор для поддержки каждой игры.
Эмуляторы же с низкоуровневой эмуляцией, способные выполнять реальный микрокод и вести новые разработки, появились относительно недавно. Они крайне требовательны к компьютеру, и до сих пор ещё довольно сырые.
Nintendo предоставляла своим лицензированным разработчикам уже готовый микрокод для решения типовых задач в составе официального SDK, и по большей части все игры ограничивались использованием этого решения, так как создание собственной альтернативы было весьма непростым делом. Тем не менее, этот путь сулил повышение эффективности, и некоторые разработчики, в частности, Factor 5, всё же решилась на данный подвиг.
Микрокод аукнулся и разработчикам-любителям. Официальный микрокод вполне определённо является объектом авторского права, и без разрешения Nintendo и SGI его использовать нельзя — а Nintendo, конечно же, никогда никому такого разрешения не даст. Написать же свой код сравнимой сложности — невыполнимая задача для разработчика, только осваивающего систему, так как требует хорошего понимания аппаратуры и сложных оптимизированных вычислений. Проблема этого рода повлияла на судьбу недавнего удивительнейшего проекта, любительского порта игры Portal для Nintendo 64 — он был убран из Steam из-за наличия в нём оригинального кода Nintendo.
Официальный SDK предлагает немаленький набор микропрограмм для решения различных задач. Каждой программе соответствует свой набор из нескольких десятков вызовов в SDK для передачи параметров. Среди этих программ:
- rspboot — код для загрузки микропрограмм согласно списку задач, фактически диспетчер микрокода.
- Fast3D и F3DNoN — реализуют 3D-клиппинг, проецирование и матричные преобразования для вершин, расчёт освещения, функцию тумана, генерацию текстурных координат с переспективной коррекцией. Работают с треугольными полигонами, на выходе формируют до 6 команд для RDP.
- Line3D — выполняет примерно те же функции, но работает с векторами, а не закрашенными полигонами. Полезен для отрисовки «проволочных» сцен.
- Turbo3D — минимальная версия Fast3D с пониженной точностью вычислений, не поддерживающая клиппинг, освещение, перспективную коррекцию текстурных координат и сложные матричные преобразования. Предназначается для оптимизации скорости отрисовки некоторых элементов сцены, повышая скорость работы в 5-6 раз.
- Sprite2D — предназначается для быстрой работы со спрайтами, преобразуя их параметры в вызовы в формате RDP.
- S2DEX — реализует классическую тайло-спрайтовую систему, удобную для разработки двухмерных игр.
- Z-Sort — сортирует список объектов по глубине и рисует их в соответствующем порядке. Хотя в Nintendo 64 реализован аппаратный попиксельный Z-буфер, растеризация без Z-буфера работает в четыре раза быстрее, чем с ним, и такая упрощённая сортировка позволяет ускорить работу, а также снизить расход памяти.
Также есть микрокод для микширования цифрового звука, включая распаковку ADPCM и MIDI-синтезатор, а также микрокод для оптимальной распаковки изображений в формате N64 JPEG, местной вариации стандартного JPEG.
▍ Мутный туман
Визуальная эстетика Nintendo 64 весьма узнаваема, её трудно перепутать с любой другой платформой. Описать главное впечатление от неё можно одним словом: мутно.
Во-первых, это единственная в поколении система с фильтрацией текстур, а так как текстурная память очень мала и для достижения хорошей скорости работы переключение текстур требуется делать как можно реже, эти текстуры имеют крайне низкое разрешение и цветность, и их разнообразие невелико. В результате изображение по большей части превращается в размазанные пятна.
Во-вторых, часто используемый антиалиасинг размывает ещё и рёбра полигонов, делая картинку ещё менее чёткой, особенно в низком экранном разрешении и на ЭЛТ-телевизорах.
В-третьих, ужасающая малополигональность объектов и окружения. Полигональная производительность напрямую связана с используемым микрокодом, и теоретически может достигать 600000 полигонов в секунду при использовании Turbo3D, а в сети можно встретить упоминания и вовсе умопомрачительного миллиона. Но в реальных играх значения скорее ближе к 100000 полигонов в секунду. К тому же, RDP не отличается высокой скоростью растеризации, особенно при использовании Z-буфера.
И конечно же, повсеместный сильнейший туман, начинающийся примерно на кончике носа главного героя. Впрочем, благодаря полноценной поддержке полупрозрачности и 24-битному цвету смотрится он красиво и является одной из самых узнаваемых визуальных особенностей местной графики.
Другая характерная особенность Nintendo 64, следствием которой, собственно, и стало сгущение тумана — низкая частота кадров. Если на PlayStation и Saturn игры, работающие с частотой 60 кадров в секунду, встречались просто редко, здесь таких почти совсем нет. В основном это драки один на один и F-Zero X.
Обзор немногочисленных игр, работающих в 60 кадрах в секунду, для Nintendo 64 и Sega Saturn
Чтобы хоть как-то повысить частоту кадров до приемлемых значений в районе средних 20 FPS для NTSC и 17 FPS для PAL, игры были вынуждены очень сильно ограничивать количество полигонов на экране и дальность прорисовки.
Обзор игр Nintendo 64, поддерживающих дополнительное ОЗУ, с демонстрацией визуальной разницы
Часть игр компенсировала проблему низкой чёткости изображения работой в высоком разрешении, 640 на 480, но это требовало модуля расширения ОЗУ до 8 мегабайт (4 штатных плюс 4 в модуле), а частота кадров при этом падала до величин, близких к отрицательным.
PC: софтвер, 3Dfx и DirectX (1993-1996)
Хотя персональные компьютеры не являются частью системы поколений игровых устройств, представляя собой отдельную независимую сущность, интересно рассмотреть, что в то же самое время происходило в этой, параллельной игровым консолям, реальности. А происходило многое, и в том числе такая же масштабная смена парадигм.
Первые персональные компьютеры IBM долго оставались аутсайдерами в игровой индустрии. Поначалу они не имели ни цветной графики, ни звука, сравнимого даже с тогдашними домашними 8-битными платформами, при многократно более высокой стоимости. Оптимизированные под конкретные визуальные сюжеты и игровые жанры приставки показывали максимально плавную и яркую картинку, играли впечатляющие мелодии, а PC едва-едва шевелил 4-мя или 16-ю цветами в небольшом окошке под вялое хрюканье системного динамика.
Однако открытая архитектура PC давала возможность постепенно интегрировать новейшие технологические достижения, и по прошествии времени на платформу пришли и хорошая графика, и звук, и значительные вычислительные мощности. К закату четвёртого поколения PC догнал консоли, а в пятом, с появлением в 1993 году Intel Pentium, ситуация пришла к современному состоянию — мощные дорогостоящие PC уже однозначно превосходили игровые консоли, а сопоставимые по стоимости бюджетные конфигурации компьютеров обладали примерно равными характеристиками.
В рамках одной платформы IBM PC за годы существования пятого поколения консолей было реализовано сразу несколько подходов к трёхмерной графике: программный во всех возможных вариациях и воплощениях, и аппаратный, с растерзацией текстурированных полигонов. Также в эти годы произошёл переход от MS-DOS к операционной системе будущего, Windows 95 и появление DirectX.
▍ Программное 3D
Фазовый переход в концептуальном подходе к трёхмерной графике на PC и её новому уровню качества случился всего за три-четыре года, между 1993 и 1997-ым годами.
Конечно, трёхмерные игры существовали на PC и раньше, и в них были опробованы самые разные технологии: векторы, одноцветные полигоны, спрайты, фракталы, рейкастинг, воксели и так далее. Они как-то работали, не отличаясь детализацией картинки, скоростью работы и понятностью игрового процесса, и имели какую-то ограниченную популярность. Но в 1993 году вышла игра, изменившая всё и задавшая тренд на 3D графику на домашних ПК — всем хорошо известный Doom.
Хотя Doom и не был полностью трёхмерным, и даже не использовал технологию полигонов, тем не менее, он смог значительно расширить рамки того, что всего лишь годом ранее предлагал Wolfenstein 3D, и показать, какой может быть действительно удачная, крутая трёхмерная игра действия, понятная любому игроку, и какой графикой она может обладать. К тому же он худо-бедно работал даже на устаревших 386-ых процессорах пятилетней давности. К слову, за давностью лет не все это осознают, но Doom был выпущен почти на год позже первого Pentium, и в рекомендуемых системных требованиях имел 486 процессор или старше.
Появление процессора Pentium, совпавшее со стартом пятого поколения игровых консолей, обеспечило IBM PC фору. Он был мощнее бюджетных RISC-решений, представленных на консолях, и теперь его чисто программных мощностей хватало для отображения ранней трёхмерной графики в более высоких разрешениях или с лучшей частотой кадров. Некоторое отставание обозначилось ближе к 1996 году, когда на PlayStation и Sega Saturn начали выходить игры второй волны, от набравшихся опыта разработчиков, научившихся более эффективно использовать имеющиеся технические возможности.
Однако, выход игры Quake летом 1996 года показал возможность быстрой текстурированной полигональной графики, превосходящей по качеству аппаратные реализации, которые можно было наблюдать на консолях. Помимо прочих технологий, в ней был использован упомянутый в предыдущей части метод линейно-кусочной перспективной коррекции при отрисовке полигонов, который даёт лишь незначительный проигрыш в скорости по сравнению с аффинным текстурированием. К тому же оказалось, что его код довольно хорошо поддаётся конвейеризации на первых процессорах Pentium. Аналогичный алгоритм применялся и в аппаратных растеризаторах 3D-ускорителей.
▍ 3D ускорители
Слово «ускоритель» (графический) имеет двоякое значение. С одной стороны, оно подразумевает устройства в составе видеокарты, реализующие более эффективное выполнение операций по обработке того или иного вида графики, как 2D, так и 3D — то есть аппаратно ускоряющие работу с графикой. В этом значении родственным термином является «графический процессор» (GPU).
Графические ускорители различного рода появились на платформе IBM PC ещё в начале 1990-х годов, и к середине 1990-х их было накопилось уже много — ATI Mach, S3 Trio и ViRGE, Rendition Verite, Matrox Impression и Mystique, Creative 3D Blaster, и прочие, не забывая, конечно же, NV1 от NVidia в Diamond Edge 3D. Они были выполнены в виде полноценных и довольно дорогостоящих видеокарт, обладали довольно скромными возможностями в области трёхмерной графики, отсутствием стандартизации способов применения этих возможностей, и самое главное — ограниченной поддержкой в играх. И хотя они безусловно сыграли свою историческую роль, особого успеха эти устройства не имели.
Ситуация в корне изменилась с выходом на рынок первого устройства на базе графического чипсета 3dfx, Voodoo Graphics, появившегося всего лишь на полгода позже Quake, в том же 1996 году. Первоначальная стратегия компании отчасти была схожа с 3DO несколькими годами ранее — 3dfx формировал спецификацию, референсный дизайн платы и поставлял только чипы, а фактические видеокарты выпускались разными производителями.
Появление Voodoo дало термину «ускоритель» в контексте IBM PC тех лет ещё одно определение: оно стало указывать на устройство, выполненное в виде дополнительной платы, подключаемой к уже имеющейся обычной видеокарте и ускоряющее работу с 3D-графикой. Двухмерные элементы и стандартная графика по прежнему отображались штатной видеокартой, а карта Voodoo накладывала поверх них создаваемое ей изображение. Наложение выполнялось аналоговым способом/ Видеовыход штатной карты подключался к входу ускорителя, а кабель монитора — к выходу ускорителя.
Такое решение позволило снизить стоимость устройства для конечного потребителя, а может, сыграл роль и какой-то психологический эффект (можно не покупать то, что уже есть, а просто докупить нужную функцию) — так или иначе, вполне вероятно, что именно оно положительно сказалось на популяризации аппаратно ускоренной 3D графики на PC. Вскоре, когда потребитель оценил открывающиеся возможности и они начали продавать себя сами, от концепции отдельного дополнения отказались, и начиная с Voodoo3 решения на основе технологии 3dfx вернулись к формату полноценной видеокарты.
Но формат устройства, конечно, был не главным. Гораздо важнее была оперативно добавленная поддержка Voodoo в суперпопулярный Quake. Она смогла привлечь внимание массового потребителя и радикально изменила визуальные стандарты игр для PC.
▍ 3dfx и Voodoo
Безусловно, архитектура всех ранних 3D-ускорителей на PC заслуживает внимания, ведь в каждом из них есть немало интересных особенностей. Но и без того огромный объём статьи не позволяет углубиться во все эти детали. Уделю внимание только Voodoo, как переломному для истории PC и наиболее знаковому устройству тех времён. На Хабре можно найти статьи, посвящённые другим решениям, например, видеокартам от S3 Graphics, как, впрочем, и более подробный разбор архитектуры 3dfx, и даже не один.
Решение от 3dfx обладает и характерными визуальными особенностями, утраченными в более поздних решениях, и наиболее полно соответствует пятому поколению — моменту, когда на рынке игровых консолей уже были одновременно представлены все главные и самые успешные игроки.
Сама компания 3dfx была основана выходцами из Silicon Graphics Interactive в 1994 году. Хотя визуально можно предположить, что их новая разработка как-то связана технологией от SGI 1993 года, применённой в Nintendo 64, на самом деле практически ничего общего, кроме наличия сглаживания текстур между ними нет. Архитектура и возможности этих устройств очень сильно отличаются.
Известно, что планировалось применение 3dfx в более поздней Sega Dreamcast, но в результате очередных внутренних разногласий, выразившихся в параллельной разработке двух разных архитектур, Sega в итоге остановилась на альтернативном решении от NEC, PowerVR.
Архитектура Voodoo проста и эффективна, никаких микрокодов и хитроумных текстурных кэшей. Она представлена контроллером буфера кадра FBI (Frame Buffer Interface) и растеризатором TREX (он же текстурный блок), физически расположенными в двух раздельных больших микросхемах. Каждый из компонентов обладает своим персональным ОЗУ, в виде отдельной физической микросхемы на плате ускорителя.
TREX занимается преобразованием треугольников из набора вершин и текстурных координат в пиксели, накладывая на полигоны перспективно-корректные текстуры с фильтрацией. Архитектура предусматривает включение до трёх TREX, каждый со своей отдельной памятью текстур объёмом 1-8 мегабайт, работающих параллельно и передающих результат растеризации каждой из текстур друг другу по цепочке.
С одним текстурным блоком доступна только билинейная фильтрация (классическая, по четырём точкам) в один проход или трилинейная в два прохода. Если текстурных блоков больше одного (Voodoo 2 и старше), становится доступным мультитекстурирование.
Размер текстур ограничен 256 на 256 текселей и степенями двойки, меньше можно, больше нет. Цветовые форматы представлены различными вариациями RGB и ARGB, включая 8-битные и 16-битные, в том числе RGB332, RGB565, варианты с 4 битами на канал и альфу, а также чёрно-белыми и одним патентованным YIQ. Из палитровых форматов предусмотрен только один 256-цветный, с указанием, что он недоступен в первой ревизии чипсета.
Выбрав нужные тексели и применив фильтрацию, TREX передаёт готовые пиксели следующему текстурному блоку, если таковой есть, или, если он последний в цепочке, в FBI.
FBI принимает пиксели от растеризатора, применяет к ним цветовые операции — туман, полупрозрачность, освещение по Гуро, выполняет проверку Z-буфера, и записывает их в буфер кадра. Также он реализует двойную буферизацию: читает предыдущий кадр и отправляет на видео-ЦАП, пока растеризатор формирует новый кадр. ОЗУ буфера кадра может иметь объём 2-4 мегабайта.
Voodoo Graphics первого поколения имел базовую конфигурацию с одним растеризатором и 4 мегабайтами памяти — 2 мегабайта для буфера кадра и 2 мегабайта для хранения текстур. В такой конфигурации памяти хватало для хранения либо двух страниц буфера кадра и 16-битного Z-буфера с разрешением 640 на 480 пикселей, либо только на две страницы 800 на 600 без Z-буфера. На моделях с 8 мегабайтами памяти Z-буфер становился доступен и в 800 на 600, но другие разрешения не поддерживались.
Особенностью архитектуры и её визитной карточкой является работа исключительно в 16-битным цветом в формате RGB565. Так как этого было маловато, операции альфа-блендинга и освещения применяли к результату упорядоченный дитеринг (шахматную сетку пикселей) 2x2 — характерный визуальный артефакт, родственный дитерингу на PlayStation, делающий графику на видеокартах 3dfx довольно узнаваемой.
Об эту особенность было сломано немало копий: кому-то нравилась специфическая цветовая гамма, кому-то шахматный дитеринг не мешал, а другие считали это критичным недостатком.
Видеообзор особенностей дитеринга и его фильтрации на видеокартах 3dfx
Особенно это проявилось в третьем поколении Voodoo, которое внутри выполняло вычисления в 24-битном цвете, но ради экономии памяти всё ещё хранило результат в буфере кадра в 16 битах. При этом непосредственно в процессе отображения картинки, то есть формирования видеосигнала, применялась специальная фильтрация, сглаживающая дитеринг и грубые градиентные переходы, свойственные 16-битному цвету. Особенностью этого решения является невозможность сделать скриншот с применённой фильтрацией. 3dfx называла это безумие «22-битным цветом».
Полноценная поддержка 32-битного цвета появилась только в последнем, пятом поколении видеокарт Voodoo, в 2000 году.
Что касается собственно ускорения, то есть скорости растеризации, даже первая модель Voodoo показывает очень неплохие результаты. Теоретические цифры заявлялись в районе одного миллиона полигонов в секунду, но нужно помнить, что Voodoo — только растеризатор. Все задачи этапа T&L по подготовке потока треугольников для растеризации возложены на центральный процессор, и скорость этого процесса зависит от множества параметров, а скорость аппаратной растеризации зависит от площади полигонов и опций отображения.
Учесть всё это в оценке очень сложно, но для реальных игр того времени эта цифра находится, пожалуй, в районе 200000 полигонов в секунду. По крайней мере, её хватало для работы игр в разрешении 640 на 480 со стабильной скоростью около 20-30 кадров в секунду. Например, на Pentium 166MMX в игре Quake, использующей двухпроходный рендер для наложения карт освещения на диффузные текстуры при использовании одного текстурного блока, Voodoo выдавала 26 к/сек в разрешении 640 на 480, и 47 к/сек в чуть пониженном разрешении 512 на 384 пикселей.
Первые 3D ускорители тоже принесли свою визуальную эстетику в игры, и в особенности это касается Voodoo. Архитектура карты и повышенные технические характеристики позволили немного сгладить углы мутного месива, которое предлагала Nintendo 64. Специфическое сочетание сглаженной картинки с размытыми, но чуть более чёткими текстурами, отсутствие излишнего антиалиасинга на линиях, довольно высокое разрешение и яркая гамма — есть ощущение некоторого избыточного осветления — создали легко узнаваемый стиль.
Впрочем, не всем пользователям понравилась потеря настраиваемой гамма-коррекции и «шершавого» вида программного рендера в Quake, так как сглаживание и осветление довольно радикально меняли настроение в кадре этой довольно брутальной игры. Это разделило пользователей на тех, кому нравилось то или иное сочетание, и некоторые из них надолго сохраняли лояльность продуктам 3dfx и Glide-версиям игр именно по причине такого визуального отличия.
▍ Графические API
С появлением популярных 3D-ускорителей развитие трёхмерной графики на PC перешло в иную плоскость: в стандартизацию средств визуализации и абстрагирование от конкретной технической реализации.
На каждой из игровых консолей было представлено одно, очень конкретное и неизменное архитектурное решение, а предлагаемый SDK и графический API поставлялись непосредственно производителем и являлись прямой производной от конкретной архитектуры. Если там и возникали сторонние решения, как у Psygnosis на PlayStation и Factor 5 на Nintendo 64, они были привязаны к общей технической основе и потому неизбежно приобретали значительное сходство.
На PC же 3D-ускорители могли иметь довольно разную архитектуру, изменяющуюся с выпуском новых моделей. Было важно обеспечить работоспособность игр как на уже существующих моделях, так и на будущих. По этой причине стала набирать популярность концепция стандартного графического API. Сначала это был Glide для 3Dfx, потом начал набирать популярность (и до сих пор сохранил) OpenGL от SGI и ARB, но на платформе Window. Главенствующим же стандартом стало местное проприетарное решение, DirectX.
Несмотря на уже зародившиеся на тот момент универсальные решения, сама 3dfx попыталась пойти особым путём, предложив в 1995 году проприетарную библиотеку Glide для работы со своими ускорителями. Первые буквы в её названии отсылают к OpenGL. По сути, Glide представлял собой уменьшенный набор возможностей этого обширного графического API, поддерживая только те из них, которые были реализованы в ускорителях компании.
Аналогично местным графическим API на игровых консолях, Glide стал прямой производной от конкретной графической архитектуры — в частности, в API не предусматривалась работа с цветностью выше 16 бит. И хотя он позволял эффективно решать задачи с использованием решений от 3dfx, он не обладал ни открытостью, ни необходимой универсальностью для внедрения поддержки устройств иных производителей. Для работы с другими видеокартами играм приходилось осуществлять параллельную поддержку других графических API. С 1995 года было выпущено около полутора сотен игр с поддержкой Glide. В 2000 году 3dfx отказалась от дальнейшей поддержки своего API.
Аналогичные проприетарные решения предлагались и другими производителями видеокарт для работы с их ускорителями — например, S3D от S3. Отсутствие поддержки в играх и меньшая популярность этих решений не позволили сыграть им сколько-то заметную роль.
Успеха смогли добиться два универсальных API: одно проприетарное от Microsoft — лидера в области домашних операционных систем, другое открытое от Silicon Graphics Interactive — лидера в области трёхмерных графических рабочих станций. Речь, конечно, идёт про DirectX и OpenGL.
Спецификация OpenGL (Open Graphics Library) родилась в результате растущего давления конкурентов Silicon Graphics, пытавшихся предложить свои альтернативы ставшему индустриальным стандартному для профессиональных графических решений проприетарному API IRIS родом из начала 1980-х годов. Чтобы сохранить позиции на рынке, SGI решила переработать существующее решение, и в 1992 году опубликовала его открытую вариацию под названием OpenGL 1.0. Переработки коснулись определения архитектуры стандартного графического конвейера, абстрагирование от аппаратных реализаций с программной поддержкой тех или иных функций при необходимости, а также исключение всего, не касающегося непосредственно работы с трёхмерной графикой (создание окон, работу с клавиатурой и мышью). С тех пор стандарт постоянно обновлялся, учитывая новые веяния и включая дополнительные расширения.
DirectX первой версии был представлен в сентябре 1995 года. Решение от Microsoft было призвано решить проблему растущего разнообразия аппаратных решений. Это было комплексное API для создания любых 2D и 3D графических интерактивных приложений, с поддержкой аппаратного ускорения любых операций при наличии такового. Функционально DirectX делился на компоненты, посвящённые соответствующим задачам — DirectDraw для плоской графики, DirectSound и DirectMusic для звука и музыки, DirectInput для устройств управления, DirectShow для мультимедийного контента. Наконец, в 1996 году к ним присоединился Direct3D для работы с аппаратно ускоренной трёхмерной графикой. Это решение было создано на основе приобретённого Microsoft в 1995 году Reality Lab API.
Поначалу DirectX поставлялся отдельно, но в 1997 году его инсталлятор был включён прямо в установочный пакет Windows 95 OSR 2.5, и с тех пор это API входит в состав всех новых версий Windows.
Так как компьютеры гораздо чаще использовались для игровых приложений именно под управлением ОС от Microsoft, ситуация грозила монополией. Летом 1997 года около 50 разработчиков игр подписали открытое письмо, обращённое к Microsoft, с просьбой поддержать в их ОС альтернативу в лице OpenGL. Как ни странно, обращение возымело некоторое действие, и уже в декабре 1997 года начало сотрудничество SGI и Microsoft над проектом Fahrenheit, высокоуровневой надстройкой над OpenGL и Direct3D, призванном унифицировать операции стадии T&L, поддерживая оба API в качестве бэк-енда стадии растеризации. Но дело не пошло. Microsoft больше интересовало развитие собственного решения, и в 1999 году проект был закрыт, а поддержка аппаратного ускорения для OpenGL исключена из базовой поставки Windows XP. С тех пор полноценная реализация API поддерживалась в Windows силами разработчиков драйверов для видеокарт. Без установки драйверов OpenGL работал в ужасающе медленном программном режиме.
Жизнь в кроссплатформенном OpenGL поддерживалась многочисленными энтузиастами и Джоном Кармаком до 2016 года, когда была предложена современная замена — API Vulkan, решающая многие накопившиеся за годы существования системные проблемы. Сам OpenGL в исходной форме сохранился до сих пор, но его развитие остановилось на версии 2017 года, и поддержки графических решений новейшего времени в нём не предусмотрено.
Что касается возможностей, оба API были вполне равноценными и примерно одинаковыми в удобстве применения. Они давали одинаковую картинку и незначительно отличались в ту или иную сторону производительностью в отдельно взятых играх. Поддержка новых веяний типа пиксельных шейдеров достаточно оперативно добавлялась в оба API.
В 1997 году новая видеокарта RIVA 128 от NVidia окончательно определила будущее трёхмерной графики на PC. Она снова была выполнена в формате полноценной видеокарты, теперь уже обладающей доступной ценой, достаточно производительной полигональной 3D-визуализацией и развитой поддержкой в существующем ПО. Успех был закреплён с выходом первой видеокарты в линейке GeForce в 1999 году, и с тех пор устройства этой серии преобладают на рынке. Впрочем, дальнейшую историю вы знаете лучше меня.
Продолжение следует
Мы уже узнали всё про лидеров пятого поколения игровых консолей и про параллельную реальность на персональных компьютерах. Но расходиться ещё рано. В заключительной, самой объёмной части статьи мы узнаем многое про аутсайдеров поколения, а также о современном наследии, которое оставила после себя пятая волна. Скоро на ваших экранах.
«Графика древности» — это цикл статей, посвящённый детальному разбору разнообразных аспектов способов визуализации в видеоиграх прошлых лет, от самых истоков игровой индустрии до конца века, а также анализу технологических оснований, формирующих узнаваемую визуальную эстетику компьютерной графики различных исторических периодов. Предыдущие публикации цикла:
- Графика древности: от текста к видеоиграм
- Графика древности: легендарный Mode 7
- Графика древности: палитры, часть 1/2
- Графика древности: палитры, часть 2/2
- Графика древности: пятая волна. Новые технологии и 3DO (часть 1/4)
- Графика древности: пятая волна. Sega Saturn и Sony PlayStation (часть 2/4)
Продолжение следует!
Telegram-канал со скидками, розыгрышами призов и новостями IT 💻
