![](https://habrastorage.org/webt/fj/_l/fe/fj_lfegq3cy821v9vjxbve701u8.jpeg)
В предыдущих двух частях статьи (тут и тут) мы обсудили общие черты пятого поколения игровых консолей и подробно разобрали особенности первой тройки лидеров поколения — 3DO, Sega Saturn и Sony PlayStation.
Однако, всего лишь через три года после начала поколения в новейших графических технологиях домашней 3D-графики случилась новая революция, которая вполне могла потянуть на очередную смену поколений: переход от квадратных пикселей низкого разрешения к мутным пятнам высокой чёткости.
Изменились и лидеры. 3DO и Saturn постепенно ушли со сцены, PlayStation сохранила и укрепила свои позиции, а новыми весомыми игровыми платформами в индустрии стали консоль Nintendo 64 и домашние ПК, оснащённые графическими ускорителями. О них и будет сегодняшний рассказ.
Nintendo 64 (июнь 1996)
![](https://habrastorage.org/webt/xg/_h/o-/xg_ho-rh8vyapjumlxoqsjh_jrc.jpeg)
Чтобы показать всем кузькину мать и не оконфузиться перед конкурентами, Nintendo привлекла к разработке своей новой консоли компанию, которая съела не одну собаку
на продвинутой трёхмерной графике — Silicon Graphics (SGI). Последняя как раз создала достаточно недорогое графическое решение для игровых применений, и искала партнёра для выхода на рынок видеоигр. Сначала технология была предложена компании Sega, но из-за разногласий между американским и японским подразделениями случились заминка и отказ от сотрудничества. Тогда технологию предложили Nintendo, и она согласилась.
Маркетинговая видеопрезентация Project Reality
Так, в 1993 году стартовал Project Reality, продвигавшийся под названием Ultra 64, и, наконец, перед самым выходом на рынок переименованный в Nintendo 64. В результате совместных усилий получилась последняя, самая продвинутая система поколения. Она стоит особняком от предыдущей основной тройки лидеров и технически является скорее представителем условного пятого с половиной поколения, приближаясь к Sega Dreamcast (1998).
![](https://habrastorage.org/webt/ge/dw/u-/gedwu-pcjesfhenqaoylg23i5tk.jpeg)
Теоретически Nintendo 64 предложила самую совершенную графическую технологию, ранее доступную только на рабочих станциях Silicon Graphics. В частности, система поддерживает аппаратное сглаживание текстур и антиалиасинг, буфер глубины, честный альфа-блендинг, и многое другое. Также она имеет наибольший объём оперативной памяти среди конкурентов.
Quake II на, представьте себе, PlayStation и Nintendo 64. Pick your poison!
На практике же необходимые для экономической эффективности упрощения аппаратуры, а также ряд не очень удачных технических и концептуальных решений привели к сомнительной ситуации, когда более простая, практически топорная визуализация на менее продвинутой PlayStation зачастую выглядела выигрышнее, обладая лучшей детализацией и плавностью анимации.
Другой проблемой системы стал выбранный Nintendo носитель в формате классического картриджа на микросхемах масочного ПЗУ. Его объём был значительно меньше, чем у ставшего новым стандартом компакт-диска (4-64 мегабайт против почти 700), что полностью исключило теряющий актуальность, но всё ещё представленный на рынке жанр FMV, анимированные заставки, а также потоковое аудио — игры были вынуждены рассчитывать на сэмплы и синтез звука в реальном времени. Только в поздних играх появились небольшие видеоролики и живые саундтреки.
![](https://habrastorage.org/webt/np/xg/jl/npxgjl7b8nm4nopwxgoqnnh79rg.jpeg)
Нужно отметить, что картридж Nintendo 64 устроен концептуально иначе, чем на системах предыдущих поколений, из-за чего все прежние преимущества этого формата были утрачены — мапперы и дополнительные процессоры ушли в прошлое. ПЗУ картриджа не проецируется в адресное пространство центрального процессора, а значит, хранящиеся в нём данные и код недоступны для прямого чтения и выполнения. При включении консоли специальный контроллер копирует первый мегабайт памяти картриджа в ОЗУ. Далее игра должна самостоятельно подгружать код и ресурсы в ОЗУ по мере необходимости.
С другой стороны, скорость работы интерфейса с картриджем значительно выше, чем у компакт-дисков (5-30 против 0.3 мегабайт в секунду), что позволяет даже ограниченно применять кэширование текстур с подгрузкой их из картриджа на лету, подобно динамическим текстурным атласам (т.н. «мегатекстура») современных игр, но всё же не исключает необходимость загрузок уровней и экранов меню. Впрочем, они происходят практически незаметно для пользователя и не имеют привычных по CD-консолям экранов «Loading».
![](https://habrastorage.org/webt/lt/ut/k0/ltutk063x74iyzrglccdjajivam.jpeg)
Позже Nintendo попыталась исправить ситуацию с не очень удачным выбором носителя посредством выпуска внешнего дисковода для проприетарных магнитных дисков, 64DD. Это устройство вышло в 1999 году только в Японии, и не получило популярности. Главной проблемой нового формата был объём дисков — всего 64 мегабайта. Всего для 64DD было выпущено 9 игр.
▍ Архитектура
Это вторая система, с которой я имел практический опыт разработки кода. Однако, во времена её популярности, в конце 90-х, я с ней почти не сталкивался, и потому особо тёплых чувств не накопил. Работа с Nintendo 64, как, впрочем, и местная библиотека игр, понравились мне меньше, чем в случае с 3DO. Хотя и ничего плохого сказать про всё это я не могу — сделано профессионально и качественно, с умом и фантазией.
На первый взгляд, архитектура системы довольно красива и устроена даже проще, чем PlayStation. В ней можно насчитать ровно три процессора. Однако, есть в ней и несколько не очень приятных моментов, сильно затрудняющих и понимание, и использование. Особенно это касается попыток работать с железом без официального SDK, который успешно маскирует наиболее сложные моменты готовой реализацией сложного кода.
![](https://habrastorage.org/webt/ib/4s/_i/ib4s_irojcdznj8vptcmdevb6eq.png)
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 размещаются входные данные и результаты выполнения кода.
![](https://habrastorage.org/webt/mv/yo/ao/mvyoaovb789omcbmtsjlxzjz878.jpeg)
Основной задачей RSP является преобразование различных данных в формат RDP. В трёхмерной полигональной графике его роль сильно напоминает вершинный шейдер, только очень низкоуровневый: один из видов микрокода реализует внутри RSP аналог ступени конвеера T&L, трансформации и освещения, то есть преобразование входной 3D-геометрии и расчёт освещения. Речь, конечно, идёт о вершинном освещении по Гуро.
Растеризацией полигонов и прочими графическими операциями, а также формированием итогового изображения занимается RDP. Он занимается отрисовкой треугольников и прямоугольников (спрайтов), наложением и фильтрацией текстур, применяет цветовые операции. Поддерживается блендинг с содержимым буфера кадра, мап-мапы и антиалиасинг. Впервые в мире игровых консолей реализована полноценная аппаратная поддержка попиксельной Z-буферизации.
Может напрашиваться аналогия: раз RSP играет роль вершинного шейдера, значит RDP похож на пиксельный шейдер. Но это не так, RDP выполняет фиксированный набор функций с программированием на уровне установки нескольких различных режимов работы, наподобие функции glTexEnvi в конвейере OpenGL.
![](https://habrastorage.org/webt/pg/cc/qp/pgccqppqhmmrluexkrdsax-h1um.jpeg)
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 нет.
![](https://habrastorage.org/webt/bz/qt/c4/bzqtc40ngpp8vhyaoygkqknlkwo.jpeg)
Трёхточечная интерполяция придаёт сглаженным пикселям специфическую диагональную форму, которая при креативном применении даёт кажущееся повышение чёткости отдельных элементов. Разработчики игр учитывали эту особенность при подготовке текстур, и если сглаживать их обычной билинейной фильтрацией в эмуляторе, разница будет очевидна.
Другой особенностью системы является поддержка антиалиасинга. Однако, так как большинство игр работало в низком экранном разрешении, использование антиалиасинга приводило к излишней размытости картинки, что скорее являлось минусом, чем плюсом. Особенно учитывая, что включённый антиалиасинг снижал скорость растеризации.
▍ Микрокод
Микрокод — это ещё одна ключевая особенность системы: код, написанный на ассемблере RSP, для выполнения разнообразных задач векторного характера: проецирование и преобразование 3D-координат, передача дисплейных списков RDP, а также обработка звука — смешивание потока из различных источников для отправки на аудио-ЦАП.
Данный микрокод сложно написать и ещё сложнее использовать, так как объём памяти микропрограмм крайне мал — всего 1024 инструкции, а любой игре требуется как-то выполнять две параллельные задачи, ведь ей нужно и звук, и изображение. Поэтому требуется постоянно жонглировать микропрограммами, загружая то код для графических вычислений, то код для обработки звука, то ещё какой-нибудь другой.
![](https://habrastorage.org/webt/jc/wy/ar/jcwyarct5ohcmxveotf71jpokhu.png)
Безусловно, можно полностью исключить работу с 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 весьма узнаваема, её трудно перепутать с любой другой платформой. Описать главное впечатление от неё можно одним словом: мутно.
Во-первых, это единственная в поколении система с фильтрацией текстур, а так как текстурная память очень мала и для достижения хорошей скорости работы переключение текстур требуется делать как можно реже, эти текстуры имеют крайне низкое разрешение и цветность, и их разнообразие невелико. В результате изображение по большей части превращается в размазанные пятна.
![](https://habrastorage.org/webt/eu/xj/ne/euxjnehpzjj4mes3qrifpfbl9nk.png)
Во-вторых, часто используемый антиалиасинг размывает ещё и рёбра полигонов, делая картинку ещё менее чёткой, особенно в низком экранном разрешении и на ЭЛТ-телевизорах.
В-третьих, ужасающая малополигональность объектов и окружения. Полигональная производительность напрямую связана с используемым микрокодом, и теоретически может достигать 600000 полигонов в секунду при использовании Turbo3D, а в сети можно встретить упоминания и вовсе умопомрачительного миллиона. Но в реальных играх значения скорее ближе к 100000 полигонов в секунду. К тому же, RDP не отличается высокой скоростью растеризации, особенно при использовании Z-буфера.
![](https://habrastorage.org/webt/hd/kp/qx/hdkpqxdtm4ktoddi4lbhcyjvtge.png)
И конечно же, повсеместный сильнейший туман, начинающийся примерно на кончике носа главного героя. Впрочем, благодаря полноценной поддержке полупрозрачности и 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)
Хотя персональные компьютеры не являются частью системы поколений игровых устройств, представляя собой отдельную независимую сущность, интересно рассмотреть, что в то же самое время происходило в этой, параллельной игровым консолям, реальности. А происходило многое, и в том числе такая же масштабная смена парадигм.
![](https://habrastorage.org/webt/bf/wa/0u/bfwa0ugh6ebtbwmckflxtmfs3me.png)
Первые персональные компьютеры IBM долго оставались аутсайдерами в игровой индустрии. Поначалу они не имели ни цветной графики, ни звука, сравнимого даже с тогдашними домашними 8-битными платформами, при многократно более высокой стоимости. Оптимизированные под конкретные визуальные сюжеты и игровые жанры приставки показывали максимально плавную и яркую картинку, играли впечатляющие мелодии, а PC едва-едва шевелил 4-мя или 16-ю цветами в небольшом окошке под вялое хрюканье системного динамика.
![](https://habrastorage.org/webt/ot/g2/a5/otg2a52635tzslmibzcxaoaw0ye.png)
Однако открытая архитектура PC давала возможность постепенно интегрировать новейшие технологические достижения, и по прошествии времени на платформу пришли и хорошая графика, и звук, и значительные вычислительные мощности. К закату четвёртого поколения PC догнал консоли, а в пятом, с появлением в 1993 году Intel Pentium, ситуация пришла к современному состоянию — мощные дорогостоящие PC уже однозначно превосходили игровые консоли, а сопоставимые по стоимости бюджетные конфигурации компьютеров обладали примерно равными характеристиками.
![](https://habrastorage.org/webt/-m/ni/gm/-mnigmwx4rtehfe0jan9bblvqbk.png)
В рамках одной платформы IBM PC за годы существования пятого поколения консолей было реализовано сразу несколько подходов к трёхмерной графике: программный во всех возможных вариациях и воплощениях, и аппаратный, с растерзацией текстурированных полигонов. Также в эти годы произошёл переход от MS-DOS к операционной системе будущего, Windows 95 и появление DirectX.
▍ Программное 3D
Фазовый переход в концептуальном подходе к трёхмерной графике на PC и её новому уровню качества случился всего за три-четыре года, между 1993 и 1997-ым годами.
![](https://habrastorage.org/webt/wt/we/8i/wtwe8i5xxqqsmdu5tkog4ucwuos.png)
Конечно, трёхмерные игры существовали на PC и раньше, и в них были опробованы самые разные технологии: векторы, одноцветные полигоны, спрайты, фракталы, рейкастинг, воксели и так далее. Они как-то работали, не отличаясь детализацией картинки, скоростью работы и понятностью игрового процесса, и имели какую-то ограниченную популярность. Но в 1993 году вышла игра, изменившая всё и задавшая тренд на 3D графику на домашних ПК — всем хорошо известный Doom.
![](https://habrastorage.org/webt/um/ba/zz/umbazzlpm5zmhudvzcpgg2ilyzg.png)
Хотя Doom и не был полностью трёхмерным, и даже не использовал технологию полигонов, тем не менее, он смог значительно расширить рамки того, что всего лишь годом ранее предлагал Wolfenstein 3D, и показать, какой может быть действительно удачная, крутая трёхмерная игра действия, понятная любому игроку, и какой графикой она может обладать. К тому же он худо-бедно работал даже на устаревших 386-ых процессорах пятилетней давности. К слову, за давностью лет не все это осознают, но Doom был выпущен почти на год позже первого Pentium, и в рекомендуемых системных требованиях имел 486 процессор или старше.
![](https://habrastorage.org/webt/gu/cf/fs/gucffspupsgfp7ntkwlaapjzszc.png)
Появление процессора Pentium, совпавшее со стартом пятого поколения игровых консолей, обеспечило IBM PC фору. Он был мощнее бюджетных RISC-решений, представленных на консолях, и теперь его чисто программных мощностей хватало для отображения ранней трёхмерной графики в более высоких разрешениях или с лучшей частотой кадров. Некоторое отставание обозначилось ближе к 1996 году, когда на PlayStation и Sega Saturn начали выходить игры второй волны, от набравшихся опыта разработчиков, научившихся более эффективно использовать имеющиеся технические возможности.
![](https://habrastorage.org/webt/cw/yx/tu/cwyxtucqwnj-ovul-ewi4lbmdwc.png)
Однако, выход игры Quake летом 1996 года показал возможность быстрой текстурированной полигональной графики, превосходящей по качеству аппаратные реализации, которые можно было наблюдать на консолях. Помимо прочих технологий, в ней был использован упомянутый в предыдущей части метод линейно-кусочной перспективной коррекции при отрисовке полигонов, который даёт лишь незначительный проигрыш в скорости по сравнению с аффинным текстурированием. К тому же оказалось, что его код довольно хорошо поддаётся конвейеризации на первых процессорах Pentium. Аналогичный алгоритм применялся и в аппаратных растеризаторах 3D-ускорителей.
▍ 3D ускорители
Слово «ускоритель» (графический) имеет двоякое значение. С одной стороны, оно подразумевает устройства в составе видеокарты, реализующие более эффективное выполнение операций по обработке того или иного вида графики, как 2D, так и 3D — то есть аппаратно ускоряющие работу с графикой. В этом значении родственным термином является «графический процессор» (GPU).
![](https://habrastorage.org/webt/hi/ys/ey/hiyseya3y72y2hcmcmxhzyevvxa.jpeg)
Графические ускорители различного рода появились на платформе 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 формировал спецификацию, референсный дизайн платы и поставлял только чипы, а фактические видеокарты выпускались разными производителями.
![](https://habrastorage.org/webt/kz/h-/rm/kzh-rmxgev0njms0wi5j6idnz5u.jpeg)
Появление Voodoo дало термину «ускоритель» в контексте IBM PC тех лет ещё одно определение: оно стало указывать на устройство, выполненное в виде дополнительной платы, подключаемой к уже имеющейся обычной видеокарте и ускоряющее работу с 3D-графикой. Двухмерные элементы и стандартная графика по прежнему отображались штатной видеокартой, а карта Voodoo накладывала поверх них создаваемое ей изображение. Наложение выполнялось аналоговым способом/ Видеовыход штатной карты подключался к входу ускорителя, а кабель монитора — к выходу ускорителя.
Такое решение позволило снизить стоимость устройства для конечного потребителя, а может, сыграл роль и какой-то психологический эффект (можно не покупать то, что уже есть, а просто докупить нужную функцию) — так или иначе, вполне вероятно, что именно оно положительно сказалось на популяризации аппаратно ускоренной 3D графики на PC. Вскоре, когда потребитель оценил открывающиеся возможности и они начали продавать себя сами, от концепции отдельного дополнения отказались, и начиная с Voodoo3 решения на основе технологии 3dfx вернулись к формату полноценной видеокарты.
![](https://habrastorage.org/webt/x9/9t/my/x99tmykwwqjvgw8_8dbhmnnvclm.jpeg)
Но формат устройства, конечно, был не главным. Гораздо важнее была оперативно добавленная поддержка Voodoo в суперпопулярный Quake. Она смогла привлечь внимание массового потребителя и радикально изменила визуальные стандарты игр для PC.
▍ 3dfx и Voodoo
Безусловно, архитектура всех ранних 3D-ускорителей на PC заслуживает внимания, ведь в каждом из них есть немало интересных особенностей. Но и без того огромный объём статьи не позволяет углубиться во все эти детали. Уделю внимание только Voodoo, как переломному для истории PC и наиболее знаковому устройству тех времён. На Хабре можно найти статьи, посвящённые другим решениям, например, видеокартам от S3 Graphics, как, впрочем, и более подробный разбор архитектуры 3dfx, и даже не один.
![](https://habrastorage.org/webt/7r/gr/oe/7rgroeewht4wx9gol8cbhdwj3vw.png)
Решение от 3dfx обладает и характерными визуальными особенностями, утраченными в более поздних решениях, и наиболее полно соответствует пятому поколению — моменту, когда на рынке игровых консолей уже были одновременно представлены все главные и самые успешные игроки.
Сама компания 3dfx была основана выходцами из Silicon Graphics Interactive в 1994 году. Хотя визуально можно предположить, что их новая разработка как-то связана технологией от SGI 1993 года, применённой в Nintendo 64, на самом деле практически ничего общего, кроме наличия сглаживания текстур между ними нет. Архитектура и возможности этих устройств очень сильно отличаются.
Известно, что планировалось применение 3dfx в более поздней Sega Dreamcast, но в результате очередных внутренних разногласий, выразившихся в параллельной разработке двух разных архитектур, Sega в итоге остановилась на альтернативном решении от NEC, PowerVR.
![](https://habrastorage.org/webt/6r/ml/82/6rml82c8pw04mnp32eiyqrm9omy.png)
Архитектура Voodoo проста и эффективна, никаких микрокодов и хитроумных текстурных кэшей. Она представлена контроллером буфера кадра FBI (Frame Buffer Interface) и растеризатором TREX (он же текстурный блок), физически расположенными в двух раздельных больших микросхемах. Каждый из компонентов обладает своим персональным ОЗУ, в виде отдельной физической микросхемы на плате ускорителя.
![](https://habrastorage.org/webt/3k/sk/6x/3ksk6xfnc18yxffl3gssiud08yy.jpeg)
TREX занимается преобразованием треугольников из набора вершин и текстурных координат в пиксели, накладывая на полигоны перспективно-корректные текстуры с фильтрацией. Архитектура предусматривает включение до трёх TREX, каждый со своей отдельной памятью текстур объёмом 1-8 мегабайт, работающих параллельно и передающих результат растеризации каждой из текстур друг другу по цепочке.
С одним текстурным блоком доступна только билинейная фильтрация (классическая, по четырём точкам) в один проход или трилинейная в два прохода. Если текстурных блоков больше одного (Voodoo 2 и старше), становится доступным мультитекстурирование.
Размер текстур ограничен 256 на 256 текселей и степенями двойки, меньше можно, больше нет. Цветовые форматы представлены различными вариациями RGB и ARGB, включая 8-битные и 16-битные, в том числе RGB332, RGB565, варианты с 4 битами на канал и альфу, а также чёрно-белыми и одним патентованным YIQ. Из палитровых форматов предусмотрен только один 256-цветный, с указанием, что он недоступен в первой ревизии чипсета.
Выбрав нужные тексели и применив фильтрацию, TREX передаёт готовые пиксели следующему текстурному блоку, если таковой есть, или, если он последний в цепочке, в FBI.
![](https://habrastorage.org/webt/eg/hq/li/eghqlimr5nwdqf4vypvzewk8pd0.jpeg)
FBI принимает пиксели от растеризатора, применяет к ним цветовые операции — туман, полупрозрачность, освещение по Гуро, выполняет проверку Z-буфера, и записывает их в буфер кадра. Также он реализует двойную буферизацию: читает предыдущий кадр и отправляет на видео-ЦАП, пока растеризатор формирует новый кадр. ОЗУ буфера кадра может иметь объём 2-4 мегабайта.
Voodoo Graphics первого поколения имел базовую конфигурацию с одним растеризатором и 4 мегабайтами памяти — 2 мегабайта для буфера кадра и 2 мегабайта для хранения текстур. В такой конфигурации памяти хватало для хранения либо двух страниц буфера кадра и 16-битного Z-буфера с разрешением 640 на 480 пикселей, либо только на две страницы 800 на 600 без Z-буфера. На моделях с 8 мегабайтами памяти Z-буфер становился доступен и в 800 на 600, но другие разрешения не поддерживались.
![](https://habrastorage.org/webt/81/td/se/81tdsetnqhzlias2dn397-cpaea.png)
Особенностью архитектуры и её визитной карточкой является работа исключительно в 16-битным цветом в формате RGB565. Так как этого было маловато, операции альфа-блендинга и освещения применяли к результату упорядоченный дитеринг (шахматную сетку пикселей) 2x2 — характерный визуальный артефакт, родственный дитерингу на PlayStation, делающий графику на видеокартах 3dfx довольно узнаваемой.
Об эту особенность было сломано немало копий: кому-то нравилась специфическая цветовая гамма, кому-то шахматный дитеринг не мешал, а другие считали это критичным недостатком.
Видеообзор особенностей дитеринга и его фильтрации на видеокартах 3dfx
Особенно это проявилось в третьем поколении Voodoo, которое внутри выполняло вычисления в 24-битном цвете, но ради экономии памяти всё ещё хранило результат в буфере кадра в 16 битах. При этом непосредственно в процессе отображения картинки, то есть формирования видеосигнала, применялась специальная фильтрация, сглаживающая дитеринг и грубые градиентные переходы, свойственные 16-битному цвету. Особенностью этого решения является невозможность сделать скриншот с применённой фильтрацией. 3dfx называла это безумие «22-битным цветом».
Полноценная поддержка 32-битного цвета появилась только в последнем, пятом поколении видеокарт Voodoo, в 2000 году.
![](https://habrastorage.org/webt/g2/0j/m_/g20jm_znuz4sqjzg8wbikfdfgtu.jpeg)
Что касается собственно ускорения, то есть скорости растеризации, даже первая модель Voodoo показывает очень неплохие результаты. Теоретические цифры заявлялись в районе одного миллиона полигонов в секунду, но нужно помнить, что Voodoo — только растеризатор. Все задачи этапа T&L по подготовке потока треугольников для растеризации возложены на центральный процессор, и скорость этого процесса зависит от множества параметров, а скорость аппаратной растеризации зависит от площади полигонов и опций отображения.
Учесть всё это в оценке очень сложно, но для реальных игр того времени эта цифра находится, пожалуй, в районе 200000 полигонов в секунду. По крайней мере, её хватало для работы игр в разрешении 640 на 480 со стабильной скоростью около 20-30 кадров в секунду. Например, на Pentium 166MMX в игре Quake, использующей двухпроходный рендер для наложения карт освещения на диффузные текстуры при использовании одного текстурного блока, Voodoo выдавала 26 к/сек в разрешении 640 на 480, и 47 к/сек в чуть пониженном разрешении 512 на 384 пикселей.
![](https://habrastorage.org/webt/uv/-a/ps/uv-apsi5vswihpmbkhazkbydhv0.jpeg)
Первые 3D ускорители тоже принесли свою визуальную эстетику в игры, и в особенности это касается Voodoo. Архитектура карты и повышенные технические характеристики позволили немного сгладить углы мутного месива, которое предлагала Nintendo 64. Специфическое сочетание сглаженной картинки с размытыми, но чуть более чёткими текстурами, отсутствие излишнего антиалиасинга на линиях, довольно высокое разрешение и яркая гамма — есть ощущение некоторого избыточного осветления — создали легко узнаваемый стиль.
Впрочем, не всем пользователям понравилась потеря настраиваемой гамма-коррекции и «шершавого» вида программного рендера в Quake, так как сглаживание и осветление довольно радикально меняли настроение в кадре этой довольно брутальной игры. Это разделило пользователей на тех, кому нравилось то или иное сочетание, и некоторые из них надолго сохраняли лояльность продуктам 3dfx и Glide-версиям игр именно по причине такого визуального отличия.
▍ Графические API
С появлением популярных 3D-ускорителей развитие трёхмерной графики на PC перешло в иную плоскость: в стандартизацию средств визуализации и абстрагирование от конкретной технической реализации.
На каждой из игровых консолей было представлено одно, очень конкретное и неизменное архитектурное решение, а предлагаемый SDK и графический API поставлялись непосредственно производителем и являлись прямой производной от конкретной архитектуры. Если там и возникали сторонние решения, как у Psygnosis на PlayStation и Factor 5 на Nintendo 64, они были привязаны к общей технической основе и потому неизбежно приобретали значительное сходство.
![](https://habrastorage.org/webt/ny/ly/b3/nylyb3wz3o7ar4thiyjl-2i9_1a.jpeg)
На 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.
![](https://habrastorage.org/webt/m5/d1/qh/m5d1qhyuwavsgscajtbcqkpw3sm.jpeg)
Аналогичные проприетарные решения предлагались и другими производителями видеокарт для работы с их ускорителями — например, S3D от S3. Отсутствие поддержки в играх и меньшая популярность этих решений не позволили сыграть им сколько-то заметную роль.
Успеха смогли добиться два универсальных API: одно проприетарное от Microsoft — лидера в области домашних операционных систем, другое открытое от Silicon Graphics Interactive — лидера в области трёхмерных графических рабочих станций. Речь, конечно, идёт про DirectX и OpenGL.
![](https://habrastorage.org/webt/xp/r8/9m/xpr89m52jawd7fbt1hhkbhwajtq.png)
Спецификация OpenGL (Open Graphics Library) родилась в результате растущего давления конкурентов Silicon Graphics, пытавшихся предложить свои альтернативы ставшему индустриальным стандартному для профессиональных графических решений проприетарному API IRIS родом из начала 1980-х годов. Чтобы сохранить позиции на рынке, SGI решила переработать существующее решение, и в 1992 году опубликовала его открытую вариацию под названием OpenGL 1.0. Переработки коснулись определения архитектуры стандартного графического конвейера, абстрагирование от аппаратных реализаций с программной поддержкой тех или иных функций при необходимости, а также исключение всего, не касающегося непосредственно работы с трёхмерной графикой (создание окон, работу с клавиатурой и мышью). С тех пор стандарт постоянно обновлялся, учитывая новые веяния и включая дополнительные расширения.
![](https://habrastorage.org/webt/hp/zh/9u/hpzh9ustu1icie_imfvlvm91zbu.png)
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.
![](https://habrastorage.org/webt/cn/om/a_/cnoma_9xb6ku_-rxdtgdowylxvg.jpeg)
Так как компьютеры гораздо чаще использовались для игровых приложений именно под управлением ОС от 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.
![](https://habrastorage.org/webt/8c/wg/0f/8cwg0feh3cj01gnehapiwvahvny.jpeg)
В 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 ?
![](https://habrastorage.org/webt/jx/md/ye/jxmdyendyev6uxwdkpnkdl77zac.png)
Комментарии (11)
Panzerschrek
03.04.2024 13:16+1В переиздании Quake II от 2023-го года туда добавили Nintendo64-версию. Это оказалось для меня неожиданностью, но Quake II на Nintendo64 - во многом другая игра: уровни там все уникальные, музыка своя. При этом уровни весьма небольшие, текстуры низкого разрешения, а музыка - явно синтезаторная. Также отсутствуют некоторые монстры. Как я теперь понимаю, всё это вызвано ограничением размера картриджа. Оригинальный Quake II (под PC), был слишком большим для этой консоли, так что даже просто порезать его было невозможно и было принято решение создать свои уровни, учитывающие ограничения данной консоли.
Gummilion
03.04.2024 13:16+1Даже в Doom64 такая же фигня - уровни свои, некоторых монстров нет. При том, что Q2 намного больше, чем Doom 2 - там явно не больше 10% от оригинала могло остаться.
unreal_undead2
03.04.2024 13:16+1Doom64 вроде просто другой. Посмотрел - есть версия для PC, надо бы пройти как-нибудь. Недавно проходил версию для PS (через Psydoom) - её явно урезали, но при этом звук/графика даже поатмосфернее, чем на PC.
unreal_undead2
Ну так тогда в обозримой реальности (в частности, в компьютерных классах физтеха) стояли в лучшем случае 386ые, а про Pentium только в компьютерных журналах читали. Но да, Doom вполне неплохо на этих 386ых бегал, благо было 4Mb оперативки. Говорят, где то от бедности запускали и на 2Mb (из под Windows 3.1 в extended режиме c подключенным своп файлом) - не видел, но подозреваю что получалась скорее пошаговая стратегия.
TigerClaw
Мне попадалась версия то ли с модифицированным, то ли специально настроенным DOS/4GW, что бы работало на ПК с 2 мегабайтами оперативки. Сам не проверял ибо тогда уже мне было не актуально. Но думаю это был тот еще изврат. Кстати даже на 4 мегабайтах дум 2 мог вылетать, еретик мог вылетать чаще.
unreal_undead2
Полноценный DOS/4G точно сам умел свопиться; DOS/4GW, поставляемый с Думом и многими другими игрушками, вроде нет. Был ещё PMODE/W, съедавший меньше памяти под свои нужды и соответственно оставлявший больше приложению - скажем, Hexen у меня на 4 мегах шёл только с ним.
Gummilion
У меня Doom II на последнем уровне с включенным бессмертием, когда монстров становилось слишком много, как будто начинал свопиться - частота кадров сильно падала и начинал трещать диском. Но это была та самая неофициальная 1.666, может в ней какие-то другие настройки DOS4GW были.
unreal_undead2
Подозреваю, что просто постоянно перезачитывал карту/текстуры из WAD.
Gummilion
Ну может быть и так - хотя там скорее спрайты монстров должны перезачитываться, уровень-то сам по себе маленький.
unreal_undead2
Спрайты по идее не так много весят. Хотя, скажем, из версии для Playstation убрали "реаниматора", именно из-за того что требовал слишком много спрайтов и памяти не хватало.
NickDoom
386DX-40 и 4 (3?) Мб вроде, если без ухищрений.
А ухищряться там было куда, можно, например, подключить PWAD с «однобокими» спрайтами, то есть с одной проекции… С текстурами аналогично пошаманить, позаменять похожие на одну… да и своп, описанный в ветке :)
Хотя на трёшке-SX всё равно пошаговая стратегия получается. Я там впервые оценил прелесть слоумо, натравив двух больших пауков друг на друга :) фирменная (закрытая, без оригинала не повторить) звуковая библиотека при работе с настоящим Creative Labs Sound Blaster тааааак роскошно глючила при этом…