Энциклопедия третьего измерения, часть 4. 3D API, или язык акселераторов

3D-акселератор — сложная штуковина. Несколько десятков миллионов вентилей в основном кристалле, еще несколько — в сервисных ( DDR , RAMDAC и т.д.) плюс электронные цепи, размещающиеся на самой плате видеокарты. И со всем этим надо как-то управляться. У акселератора есть свой ассемблер (не совсем

Рис. 1. Так выглядел легендарный 3dfx Voodoo, понимавший исключительно Glide. С него все и началось.
так, но сравнение хорошее) и специальные команды, адреса и интерфейсы, через которые им можно управлять. Все вместе это сложнейшая система. У каждого конкретного акселератора (а их сотни) свои особенности, свои дополнительные команды, а иногда и целые блоки. Если написать программную последовательность для одного акселератора, на другом она работать уже не будет. Или будет, но до тех пор, пока кристалл не задымится. А теперь поставьте себя на место разработчика компьютерных игр. С одной стороны, надо научиться управлять этой сложнейшей системой, понять ее язык, с другой — быть на гребне технологической волны, держать руку на пульсе прогресса, ну а с третьей — сделать игру совместимой с разными акселераторами. На практике это означает, что придется писать не один движок, а столько, сколько акселераторов поддерживается. Сразу грустно стало? На самом деле я сгустил краски, разработчикам живется не так уж плохо. И им не приходится писать сотни движков вместо одного. И им не приходится вникать в особенности акселераторов. Они могут вообще ничего не знать о железе игрока и успешно разрабатывать игры. А освободили их от этого тяжкого бремени программно-аппаратные интерфейсы — 3D API.

Рис. 2. Еще десяток лет назад каждый уважающий себя геймер хотел получить под елку такую коробочку…
Это специальная библиотека, которая позволяет разработчикам не думать о таких мелочах, как адреса видеобуфера или заполнение системных регистров, и сосредоточиться на процессе разработки. На практике это выглядит так. Чтобы создать, например, точечный источник света, нужно задействовать многие команды акселератора, подумать о перераспределении памяти, количестве оставшихся источников (большинство акселераторов аппаратно обрабатывает лишь 8 источников света, остальные эмулируются) и еще много о чем. А вот через API это делается всего одной командой (максимум — двумя). Разработчик пишет эту команду, а все остальное делает 3D API. Примерно так же делаются и другие сложные вещи. Например, в OpenGL такая сложнейшая вещь, как NURBS (которая до сих пор считается признаком технологического шика), создается несколькими простыми командами. **

**
Рис. 3. …и возможности, которые она давала, были по тем временам невероятными. Хотя сейчас, в эру HL2 и Doom 3, такой скриншот выглядит по меньшей мере нелепо.
В работе акселератора много рутины. Поэтому многие стандартные действия, вроде подготовки видеообласти (viewport), выполняет тот же 3D API. Не думайте, что он работает только с акселератором. И с процессором, и с памятью, и даже с другими API, например с Windows API , который отвечает за прорисовку окон. Получается, разработчику игр почти ничего делать не надо: задал несколько простых стандартных команд, и готово. Нет, не получается. Им тоже забот хватает. Зато с поддержкой 3D API остаются время и силы на проработку действительно интересных и сложных вещей, не рутинных, а творческих. На самом деле взаимодействие 3D API и акселератора несколько сложнее, чем я сейчас описал. Ведь между ними стоит еще и драйвер. Но драйвер — существо подневольное, что ему API скажет, то он и будет делать. Зачем он нужен? Для разных версий акселераторов нет разных 3D API. Один 3D API, по-хорошему, должен понимать все железо, какое только есть на свете. Но если бы он на самом деле умел общаться со всем железом, то весил бы не несколько мегабайт. Поэтому 3D API один на всех, а вот драйверов много — под каждый акселератор свой. Говоря программистским языком, драйвер предоставляет небольшой, а 3D API — очень большой уровень абстракции. Некоторые тут возмутятся и воскликнут, что тот же Detonator подходит к нескольким десяткам разных акселераторов. Путаете, господа. Detonator — это не драйвер, а целый монструозный пакет драйверов. А для каждого типа акселераторов “дрова” нужны и вправду уникальные. На этом можно было бы и закончить наш разговор, если бы не было одной маленькой проблемки. На свете несколько 3D API от разных компаний. И разные игры также заточены под разные API. И даже те игры, которые формально работают с несколькими API, на самом деле по-настоящему хорошо понимают только один-два API, а остальные — через пень-колоду. Или нагло эмулируют (симулируют). Впрочем, даже с родными API нередко возникают проблемы. Glide В 1995 году на свет появился легендарный 3D-акселератор 3dfx Voodoo. Это был первый массовый акселератор, хоть и стоил по тем временам довольно дорого. Но зато те графические красоты, которые он демонстрировал, могли растопить сердце и кошелек любого геймера. Но на старых играх, не созданных для

Рис. 4. Одним из достоинств Direct3D многие называют его относительную простоту. Даже новичок способен создать вполне презентабельную игру.
Voodoo, почти не было прироста красоты и производительности. Почему? Да потому, что управлять акселератором можно было только с помощью специального API — Glide. И именно Glide — первый массовый 3D API. Но народным он так и не стал. Тому было две причины. Во-первых, это специальный API. Он работает (точнее, с ним работают) только Voodoo-совместимые акселераторы, в отличие от OpenGL и Direct3D, которые универсальны. Во-вторых, Glide — закрытая коммерческая библиотека. Его коды и функции доступны разработчикам только после того, как они хорошенько заплатят. Поэтому разработчики отнюдь не кинулись толпами поддерживать новый стандарт. С раcпадом 3dfx Glide также канул в лету. Правда, nVidia , которой остался значительный кусок былого гиганта, обещалась поддерживать его продукты. Но речь шла, скорее всего, только о драйверах. И по сей день некоторые игры поддерживают Glide (например, Need for Speed ), но это не более чем традиция. Остальные разработчики не столь сентиментальны и Glide давным-давно забыли. С точки зрения производительности и возможностей Glide был довольно хорошей библиотекой, но теперь безнадежно отстал. И многие владельцы Voodoo-карт теперь выбирают не Glide, а Direct3D, благо большинство последних акселераторов его поддерживают. Если вы входите в число этих людей, а игра поддерживает одновременно оба стандарта, выбирайте на пробу. Бывает, что поддержка Glide реализована только на бумаге. Direct3D “А, знаем-знаем, как же, как же, — скажете вы. — Это же старый добрый DirectX. А почему Direct 3D?” А вот почему. Очень многие путают DirectX и Direct3D. Но это разные вещи. DirectX — это комплексная библиотека, которая включает в себя целый

Рис. 5. А вот и полная схема конвейера Direct3D. Не так все оказывается просто…
выводок API, так или иначе помогающих игроделам: и Direct3D , и DirectDraw , а также DirectPlay , DirectInput , DirectSound и DirectMusic. С трехмерной графикой работает только Direct3D. Поэтому говорить мы будем только о нем. Если вам интересно: DirectDraw отвечает за двумерную акселерированную графику, DirectPlay — за сетевые и интернет-сессии (помогает при создании сетевых игр), DirectInput обслуживает устройства ввода (включая даже авиационные рули с обратной связью и турбоподдувом), а DirectSound и DirectMusic распоряжаются ресурсами вашей звуковой карты. Но речь не о них, а о Direct3D. Этот API может работать в двух режимах: Retained Mode и Immediate Mode. В режиме Immediate Mode API общается с железом напрямую и дает наибольшую производительность. Retained Mode — режим абстракции,

Рис. 6. Подобную сцену на Direct3D можно сделать примерно за полчаса. Несмотря на то, что некоторые считают OpenGL более сложным, чем Direct3D, в нем времени на такое художество уйдет не больше.
программировать в котором значительно легче, но цена простоте — производительность. Иногда в настройках игр можно найти две аббревиатуры: HAL и HEL. HAL (Hardware Abstraction Layer) — уровень аппаратной абстракции. Если вы выберете этот режим, игра будет акселерироваться железом. HEL (Hardware Emulation Layer) — это программный растеризатор. В этом режиме акселерация не работает, и 3D обсчитывает центральный процессор. Иногда этот режим называют Software Emulation. Его наиболее заметный признак — всякое отсутствие фильтрации, как следствие — страшно пикселизованные текстуры. Как правило, даже при очень серьезных проблемах с 3D HEL-режим остается работоспособным. И в самых крайних случаях приходится выбирать именно этот режим, как бы дико он ни выглядел. Direct3D стал стандартом де-факто для разработчиков игр. Microsoft поставил на простоту и функциональность и не прогадал. Но чем-то пришлось поступиться. И это “что-то” — скорость работы. Я бы не сказал, что Direct3D сильно тормознее своих собратьев, но кое-какие грешки за ним водятся. Зато разрабатывать игры с его помощью просто. К тому же все новые навороты, которые напридумывают разработчики акселераторов, традиционно первыми начинают поддерживаться именно в Direct3D, а уж потом — во всех остальных библиотеках. В отличие от Glide, Direct3D универсален и подходит к любой видеокарте. Поддержка Direct3D на уровне драйверов, как правило, сама лучшая. Поэтому особых проблем с ним не возникает. И если что-то начинает глючить, просто переустановите весь DirectX. Другой вопрос, что некоторые версии настолько хватко вписываются в систему, что избавиться от них невозможно. Старшая версия никогда не даст поставить поверх себя младшую. Но и на этот лом у нас есть свой металлолом. Экспериментально было установлено, что DirectX v.6.1 не проверяет совместимость версий, поэтому легко “покрывает” даже самые последние. Если под рукой есть этот незаменимый “директ”, просто ставьте его поверх текущего, а уж потом еще раз ставьте поверх того, что так опрометчиво снесли. Должно помочь. И еще один совет: не гонитесь за последними версиями DirectX. Новую версию целесообразно ставить, только если какая-то игра его реально требует. А ставить “на посмотреть” — себе дороже. OpenGL Трехмерный API OpenGL был создан летом 1992 года в недрах корпорации Silicon Graphics (теперь SGI) на базе библиотеки IRIS GL . Для поддержки нового стандарта (который был и по сей день остается абсолютно свободным и бесплатным) сильные мира сего создали консорциум The OpenGL Architecture Review **

Рис. 7. Своеобразная эмблема OpenGL.Board(ARB), в который вошли такие известные компании, какDEC**,E &S,IBM,Intel,Intergraph,MicrosoftиSGI. OpenGL — это универсальная, аппаратно-

Рис. 8. Схема конвейера OpenGL. Взгляните на аналогичную схему для Direct3D и найдите десять отличий. Хоть модули и называются по-другому, они, по сути, исполняют все те же функции.
независимая библиотека, которая поддерживает разнообразные 3D-объекты и конструкции, начиная с примитивов и заканчивая NURBS и даже шейдерами (в своей последней инкарнации). Библиотека OpenGL существует в двух вариантах: ICD и MCD. ICD (Installable Client Driver) включает в себя все стадии конвейера и все доступные возможности. С одной стороны, это дает весомый прирост производительности, а с другой — ICD очень сложно программировать. MCD (Mini Client Driver) — это немного урезанная версия ICD, в которую добавлен элемент абстракции. “ Программист делает только то, что ему нужно, об остальном позаботится библиотека ”. MCD работает немного медленнее, чем ICD. Но все равно OpenGL считается самой быстрой из массовых графических библиотек. Однако его не часто используют. На одну игру, заточенную под OpenGL, приходится десяток под Direct3D. Почему? Во-первых, Direct3D лоббируется своим папой-гигантом. Но это далеко не главное. Программисты — люди по большей части ленивые. Без дополнительного стимула лишнюю работу делать не будут. Оказалось, что программировать под Direct3D проще, чем под OpenGL. Хотя, например, Джон Кармак признает только OpenGL. Но он крутой программист, ему это по долгу службы положено. Есть и еще одно препятствие на пути массового внедрения OpenGL. OpenGL-драйвера почти у всех акселераторов были “сырыми”. И если этим грешил даже Riva TNT , что уж говорить о каком-нибудь Savage. OpenGL-игры глючили и вываливались через каждую минуту. За последние два года ситуация изменилась в лучшую сторону. Теперь все мейнстрим-акселераторы достойно поддерживают OpenGL. Поэтому в ближайшее время количество игр под этот API возрастет. Ведь это очень хороший, правильный стандарт, в котором, например, реализован неординарный подход к конвейеру рендера (pipeline). И еще одна деталь: в OpenGL есть интересный механизм расширений, когда любой желающий может добавить в библиотеку какие-то функции, не реализованные в базовой версии API. В Direct3D есть нечто подобное, но первопроходцем был все-таки OpenGL. И все-все-все… Я перечислил основных игроков на арене 3D API. Но кроме них есть много других библиотек. Есть специализированные библиотеки вроде Redline , PowerSGL и RenderGL , есть Mesa, заточенная под Linux , есть странный Fahrenheit , который призван “помирить” OpenGL и Direct3D… Но со всеми этими библиотеками в реальной жизни вы скорее всего не встретитесь. И говорить про них нечего. Засим откланиваюсь. Поменьше вам глюков и побольше FPS. Но “Энциклопедия третьего измерения” на этом не заканчивается.