- Сравнительный анализ библиотек компьютерной трехмерной графики
- OpenGL и DirectX – основная информация
- Языки программирования трехмерной графики
- Языки программирования для разработки веб-игр
- Языки программирования для разработки мобильных игр
- Языки для программирования на коммерческих движках
- Как стать программистом игр?
Сравнительный анализ библиотек компьютерной трехмерной графики
Какие на сегодняшний день существуют аппаратно-ускоряемые библиотеки для создания компьютерной трехмерной графики? Конечно, любой специалист в области техники назовет DirectX и OpenGL. Проведем сравнительный анализ данных библиотек.
OpenGL и DirectX – основная информация
Во-первых, необходимо отметить, что все современные видеокарты имеют аппаратную поддержку возможностей и DirectX, и OpenGL последних версий, причем для совместимости с различными программными средствами (использующими ту или иную версию) производители встраивают в чипы реализацию сразу обеих библиотек. Причем можно с высокой степенью уверенности утверждать, что на аппаратном уровне реализация обеих библиотек выполнена настолько качественно, что ни одна из них не имеет значительно преимущества над другой. Различия между DirectX и OpenGL состоят в способе обработки графической информации, причем от версии к версии добавляются новые функции и возможности, позволяющие создавать более реалистичную графику.
Что же все-таки скрывается за словами OpenGL и DirectX? Слова эти именуют те самые Application Programming Interface (API — Интерфейс Прикладного Программирования), библиотеки для обработки графической информации и прямого доступа к железу («software interface to graphics hardware», как обозначаются они в спецификации). Из вышесказанного становится ясным, что данные библиотеки содержат набор уже однажды написанных функций, от самых простых (вывод точки на экран) до довольно сложных (построение готовых примитивов, например, пирамиды), которые применяются практически в каждой программе. Базовые функции реализованы аппаратно, в виде части графического процессора (Graphical Processing Unit, далее – GPU), а более сложные представляют собой программные модули, построенные на базовых командах. Видеокарта не всегда аппаратно поддерживает нужные для работы приложения функции, и в этом случае библиотека использует программные модули, эмулирующие требующиеся возможности. Однако необходимо отметить, что в контексте задачи, решаемой в настоящей работы, выполняемые операции относительно просты – например, не потребуется применения шейдерной графики – и, таким образом, можно сделать обоснованное предположение, что любая из доступных видеокарт будет аппаратно поддерживать все необходимые для работы приложения возможности.
Если попытаться объяснить понятным языком общую схему работы любой из библиотек, то она выглядит примерно так: предположим, требуется выполнить команду трилинейной фильтрации (Tri-linear Filtering – уменьшение искажения в картах текстур). Программа вызывает графическую часть DirectX (Direct3D или сокращенно D3D) и предает библиотечной функции данные и инструкции, в которых указывается, что нужно сделать с упомянутыми данными. Модуль библиотеки, отвечающий за работу с драйвером видеокарты, в свою очередь, передает ему необходимые данные и определяет, аппаратно или программно будет происходить требуемая обработка. Драйвер детектирует, что D3D данной версии полностью поддерживается на аппаратном уровне и передает на верхний уровень библиотеки ответ, что наличествует аппаратная поддержка. Дополнительно драйвер перенаправляет команды и информацию, полученную с программного уровня дальше вниз по так называемому «стеку обработки» – видеоадаптеру. Но на этой стадии разработчики видеокарты и драйвера могут внести в процесс свои коррективы. Например, Tri-linear Filtering – очень ресурсоемкая операция, поэтому на уровне драйверов она заменяется менее точной, но более быстрой Bri-linear Filtering (брилинейная фильтрация, реализована на картах фирмы ATi). Наконец, драйвер записывает в необходимые регистры GPU все данные, которые обрабатываются в соответствии с запросом, после чего в буфер отображаемого кадра (framebuffer) поступает двумерный кадр, который и выводится на монитор.
Конечно, такая схема работы довольно сложна, и теоретически прямое обращение к видеокарте могло бы иметь более простые интерфейсы при более высоком быстродействии, однако современные ОС полностью исключают прямой доступ к аппаратным частям компьютера. К тому же при прямом доступе к железу все операции по обработке графики проходят в разы быстрее, поскольку просчет производится непосредственно адаптером. Поэтому для работы с графической информацией и были написаны данные библиотеки, причем в разработке принимали участие многие крупные компании. Очевидно, что все – и производители, и разработчики, и потребители – были заинтересованы в стандартизации, другое дело, что исторически сложились два основных несовместимых друг с другом стандарта.
Основу обоих API составляют несколько файлов, в которых содержатся как низкоуровневые функции (типа вывода пикселя на экран), так и более сложные модули (типа рисования линии, состоящей из множества пикселей). Несмотря на то, что теоретически сложность примитивов, создаваемых библиотекой, не ограничена, было бы нелогичным включать в состав библиотеки средства для создания объектов, которые не нашли бы широкого употребления.
Языки программирования трехмерной графики
Хотя появилось множество новых языков, промышленные движки для 3D-игр по-прежнему пишутся по большой части на C++. Этот язык сочетает принципы объектно-ориентированного программирования с низкоуровневыми функциями языка C. C++ позволяет создавать программы с высоким уровнем абстракции без больших потерь в производительности.
Игровые движки реализуют множество ресурсоемких процедур для моделирования графики и физики. Современные игры могут отображать реалистичные сцены в режиме реального времени с миллионами треугольников и детализированными текстурами с учетом светотени, атмосферы и т.д. Это было бы невозможно без контроля над железом, предоставляемым C и C++.