Теперь подробнее остановимся на истории каждой из технологий. Начнем с Direct3D. В те давние времена, когда Windows только входила в нашу жизнь, абсолютное большинство игр писалось еще под DOS, а Windows 3.1 не предоставляла эффективных средств доступа к видео- и звуковым устройством. Такое положение дел не устраивало Microsoft, и корпорация вознамерилась сделать 3D API, который стал бы удобным инструментом в руках разработчиков игр. То ли из-за нехватки времени и ресурсов, то ли по другим причинам Microsoft решила не изобретать велосипед, а использовать наработки компании RenderMorphics. Это был совсем маленький проект, на его базе была создана небольшая библиотека Game SDK, которая и стала впоследствии именоваться DirectX 1.0. И как это ни прискорбно для Microsoft, первому DirectX не суждено было стать распространенным средством разработки игр. Причин тому было множество, и если с плохой структурой и сложностью использования еще можно было мириться, то многочисленные ошибки и неповоротливость написанных игр ставили крест на широком распространении этой технологии. Но не в правилах Microsoft сдаваться, и она немедленно принялась совершенствовать свое неудачное детище. Первой по-настоящему принятой программистским сообществом версией DirectX стала 7.0. Этот продукт был лишен большинства из «детских болезней» своих предшественников: научился почти полностью использовать потенциал видеокарт, его интерфейс стал гораздо приятнее, и, главное, DirectX 7.0 был стабилен (сейчас существует DirectX 9.0 - мощное и удобное средство разработки). Вы, наверное, обратили внимание, что я периодически называю вроде бы одно и то же по-разному - то DirectX, то Direct3D. На самом деле все просто: Direct3D - это часть DirectX. До седьмой версии в DirectX было два графических инструмента: Direct3D и DirectDraw, для трех- и двухмерной графики соответственно. DirectX содержит и другие полезные компоненты - например, DirectSound и DirectPlay. Первый используется для воспроизведения звуков, а второй облегчает жизнь разработчику игр: он берет на себя работу с вводом и даже включает сетевые интерфейсы.

История OpenGL ведется с 1992 года. Компания Silicon Graphics создала его как открытый стандарт. Отсюда и первая часть названия, а GL означает Graphic Library (графическая библиотека). На данный момент OpenGL находится под контролем комитета Architectural Review Board (ARB), куда входят представители наиболее влиятельных в 3D-секторе корпораций - nVidia, ATI, SGI, Apple, Intel, id Software и, что особенно интересно, Microsoft. ARB является по сути некой бюрократической машиной, чья задача - вводить в стандарт OpenGL новые возможности. Для этого был создан механизм расширений. Как и любая бюрократическая машина, ARB работает медленно и неповоротливо, что стало главной проблемой OpenGL, который просто не может угнаться за стремительным развитием графических технологий. Достаточно сказать, что между выходом версий 1.0 и 1.4 прошло больше десяти лет! Сейчас этот стандарт морально устарел. Хотя все новые возможности современных видеоускорителей доступны через расширения ARB, пользоваться ими, прямо скажем, неудобно.

OpenGL, создававшийся для профессионального сектора, прочно в нем закрепился во многом благодаря своей переносимости, а вот нишу PC-игр практически полностью уступил своему конкуренту. Изменится ли эта ситуация? Чтобы существенно потеснить DirectX в game-секторе, ARB необходимо вывести OpenGL на современный уровень, и, надо сказать, комитет не сидит сложа руки: грядет так долго ожидаемая вторая версия GL, ее создатели хотят снова создать стандарт на десятилетие вперед. А что же Microsoft? Попытается ли компания захватить и профессиональный сектор? Это возможно только с выходом DirectX под другие операционные системы, что вряд ли случится.

Перейдем к сравнению технологий. DirectX построен по объектно-ориентированной схеме, а OpenGL по процедурной. Что лучше? Программа на GL одинаково «хорошо» выглядит и на C++, и на чистом C, чего не скажешь о DX (хотя это надуманное преимущество, сейчас мало кто пишет на C, особенно под Windows). А вот простота архитектуры GL - неоспоримый плюс: GL работает исключительно с примитивами (треугольники, отрезки и точки) и управляется набором булевых переменных, которые позволяют включать или отключать некоторые функции - например, накладывать текстуру или нет, использовать ли освещение и т. д. Код для отображения «вашего первого треугольника» занимает примерно пятьдесят строк. В DX эта цифра куда больше. С одним-то треугольником у GL все хорошо, но как только захочется использовать что-нибудь из современных 3D-эффектов - появляются расширения GL, и еще недавно простой и понятный код тонет в непонятных и ничего не значащих для человека, не посвященного в тайны 3D-графики, строках.

Как ни странно, ведутся споры о производительности. Проверить это проще простого, но зачем? - ведь результат легко предсказуем. Он будет одинаков для обеих библиотек, поскольку сейчас практически все функции реализуются напрямую через аппаратные ускорители. Расхождение результатов может быть только из-за погрешности измерений; сюда я отношу и оптимизацию тестирующего кода, и специфику конкретных драйверов, но в целом для выполнения кода на GL и DX видеокарта должна выполнять одни и те же действия, а значит, и дискуссии о быстродействии беспочвенны. Конечно, можно копать глубже и спорить о качестве шейдерных компиляторов HLSL[High-level Shader Language - С-подобный язык для написания шейдеров в DirectX 9.0] и GLSL[OpenGL Shading Language - аналог HLSL для OpenGL], но мы не будем лезть в такие дебри, тем более что оба решения далеки от совершенства.

Что мы имеем: львиная доля создателей игр выбирает DirectX за удобную поддержку современных возможностей, остальные предпочитают OpenGL - за переносимость и простоту написания программ. Ситуация в общем-то нормальная, если вспомнить, для чего создавалась каждая из технологий. Но если мы обратим внимание, что Doom III, самая нашумевшая игра последнего времени, написана на OpenGL, то поневоле закрадывается подозрение, что не все так просто. Может быть, в id Software знают какой-то секрет, делающий применение OpenGL предпочтительнее? Нет, просто команда разработчиков уже привыкла работать на нем. Это еще раз красноречиво говорит о том, что GL мало чем уступает DirectX.

Я много говорил о возможностях современного железа, но ни разу не упомянул о том, что же это за возможности и что для их использования предоставляют OpenGL и DirectX. Прежде всего, нынешние видеокарты - это программируемые устройства. Теперь некоторый код можно выполнять прямо на графическом процессоре (GPU). Эти программы называют шейдерами. Они позволяют создавать сложнейшие эффекты в реальном времени. Изначально эти программы можно было писать только на «фирменных» языках производителей видеокарт - ATI и nVidia. Оба языка очень похожи на ассемблер, но, увы, несовместимы. А кому захочется писать два разных кода для реализации одного и того же эффекта? И вот в DirectX 8.0 появляется универсальный язык программирования шейдеров. Он тоже похож на ассемблер, но позволяет обойтись одним шейдером для обоих типов видеокарт. И снова закавыка: много ли людей любят программировать на языках низкого уровня? И вот Microsoft представляет в своем DX 9.0 уже C-подобный язык HLSL. ARB в ответ выкатил аналогичную технологию GLSL. Как уже говорилось, обе эти технологии далеки от совершенства, прежде всего из-за слабой оптимизации компиляторов. Например, создатели игры Chronicles of Riddick (кстати, использовавшие OpenGL) для увеличения производительности написали все шейдеры в двух вариантах, на родных ассемблероподобных языках от ATI и nVidia. Это выглядит странным, так как обычные компиляторы показывают совсем неплохие результаты.

Итак, у нас две библиотеки с практически одинаковыми возможностями и быстродействием. Отличия лишь в сложности написания кода. И даже здесь явного лидерства нет. Все зависит от уровня используемых в программе эффектов. Если нам достаточно базовой функциональности OpenGL (то есть мы не используем расширений), то разумнее использовать именно GL, а если дело дошло до продвинутых эффектов, тут предпочтительнее Direct3D. Но с появлением второго GL ситуация может в корне измениться, так как переход на новую версию избавит GL от большинства недостатков. Но Microsoft тоже не будет стоять на месте, и вполне возможно, что к моменту своего выхода OGL 2.0 уже устареет. Да и в дальнейшем для успешной конкуренции с DX ARB понадобится существенно переработать механизм внесения изменений в библиотеку, чтобы сделать OpenGL более динамично развивающимся.