http://forum.pwonline.ru/showimg.php...fice-mouse.jpg

Теперь немного о том, почему игры с использованием D3D делают все, а с OGL - единицы, а хорошо получается вообще только у Кармака и то после выхода DX8 даже он начал сливать по технологичности, хотя и успел сотворить интегрированный в основное освещение алгоритм управления затенением по картам нормалей. OpenGL - это графический API, который был создан в те времена, когда нас с вами вообще в проекте не было, и с тех пор его спецификация постоянно дополняется специальным комитетом ARB. Этот комитет решает, какие фишки войдут в новую спецификацию, и как все это будет называться в деталях. Иногда они никак не могут договориться. Иногда отдают работу по детальной проработке спецификации и ее первичной реализации сторонним компаниям, например Khronos Group. Дык вот.

По основной задумке этот ваш OpenGL - это подсистема рендеринга, единая вообще для всей системы, которая призвана делать одну вещь - обеспечивать простой и удобный вывод векторной графики. За эту свою особенность бешено любим разработчиками всяких 3D-редакторов и CAD-комплексов, поскольку там кадры в секунду не решают, а простота и легкость создания эффективного и мощного вспомогательно GUI на окне рендеринга того, для чего разработка предназначена, очень даже приветствуется. Хотя в последнее время наметилась тенденция и тут класть на OpenGL большой и жирный пиксель. OGL работает в системе как единая машина состояний и существует в одном экземпляре для одной программы. Точнее, из-за специфики использования подлючаемых динамически библиотек, драйвер в оконной проге сам может решить, сколько свопчейнов наклепать в своей любимой видеопамяти. Чтобы два параллельно запущенных OGL-приложения передавали друг другу команды рендера - так конечно не выйдет, но вот если у вас в одной проге два окна с этой вещью - вы получите незабываемые впечатления. Самые незабываемые получаются тогда, когда у вас один из потоков использует эту вот машину состояний для отрисовки чего-нибудь в память для каких-то ваших нужд. Поскольку системе в общем все равно, какие команды и от кого в рамках одного процесса использовать, в окна и в буферную область могут выводиться совершенно непредсказуемые данные.

Но одна из главных причин, почему OGL разработчики пользуют мало - это то, что из-за своей архитектуры и спецификаций драйвера для его поддержки писать сложно. Т.е. получается, что железяка использует свою архитектуру, организацию памяти, алгоритмы, шейдерные конвейеры и прочие радости для максимально эффективного вывода геометрии. Чтобы это все использовать было можно, надо написать драйвера, которые будут управлять возможностями видеокарты. И все бы ничего, да вот спецификация OpenGL прекрасно учитывает запросы программистов, но совершенно забывает о счастье разработчиков железа и драйверов, что приводит к неоптимальности его архитектуры - спецификация-то требует абсолютно четкой и конкретной работы абсолютно конкретных функций. Совершенно никак не учитывая объективные реалии внутренней логики устройств. Для кроссплатформенности - идеально. Для скорости работы - чудовищно. Причем, что интересно, в Windows, согласно документации, библиотека OpenGL реализована посредством работы с DirectX, т.е. он физически не может быть быстрее.

DX приближен к архитектуре железа, драйверы писать под него - сущее удовольствие, поскольку он по сути предоставляет универсальный интерфейс через HAL к самому железу. Работы руками для написания быстрых алгоритмов работы с аппаратной частью там требуется больше, но результаты достигаются более эффективно, именно за счет того, что у себя на высоком уровне архитектуру системы можно спроектировать так, чтобы она учитывала именно твои нужды. Это примерно тоже самое, что строить Храм Христа Спасителя из стандартных панелей от 18-этажек (OpenGL) или из обычных красных кирпичей (DX). Т.е.

glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_NORMAL_ARRAY);
glVertexPointer(...);
glNormalPointer(...);

glDrawElements(...);

Это на уровне устройства не обязательно тоже самое, что

pDevice->SetStreamSource(...f);
pDevice->SetIndices(...);

pDevice->DrawIndexedPrimitive(...);

У DX в связи с этим есть один неудобный минус - приходится самому заботиться о восстановлении данных, когда устройство переходит в режим lost - т.е. фактически нерабочий режим. Дело в том, что при перехвате управления устройством Direct3D каким-либо приложением, D3D предоставляет ему полный доступ к вообще всем имеющимся ресурсам видеоадаптера, в том числе ко всей видеопамяти. Точнее, это по идее так, более конкретно решает драйвер, но суть не в этом. Суть в том, что если какое-то приложение (например, ваша игра) перехватило управление видеокартой, то сделать с памятью она может что угодно, и в каком угодно месте - это решает драйвер и немножко - программист. При возврате управления системе или другой программе, нет никакой гарантии, что данные в видеопамяти, а также состояние устройства, небыли затерты в течение того времени, когда эти ресурсы были во власти перехватившего их приложения. А значит - надо все это вернуть обратно, загрузить снова или восстановить из системной памяти. Обычно сброс устройства в состояние lost можно наблюдать при выходе из игры клавишами alt+tab. При возврате обратно она имеет тенденцию как-то долго возвращаться к тому моменту, где вы ее покинули. Это связано как раз с восстановлением ресурсов. В связи с этой особенностью программисты, использующие D3D вынуждены писать руками особые подсистемы для движка - менеджеры ресурсов, которые берут на себя управление вершинными/индексными буферами, состоянием системы, поверхностями рендеринга и т.п. Но результат того стоит.

Еще одна причина, почему все любят DX - это его первоклассная документированность, справочные данные, и общая забота MS о том, чтобы его хотели использовать. Проявляется она также в очень плотной работе с производителями видеокарт. На практике это выглядит так. Когда-то давно все бенчмарки в СДК от производителей видеокарт создавались под OpenGL, просто потому, что он, в отличие от DX, открытый, и свое расширения создать к нему - не проблема. А ДХ был слаб, не перехватил еще инициативу в развитии и единственный вариант был, чтобы показать миру свои крутые наработки - это создать OGL-расширение. Но есть одна проблема. Это вот нам сейчас хорошо - основных производителей видеокарт всего две штуки. И каждый предусматривает СВОИ расширения, которые по-разному называются и разных параметров в функции требуют. А пока дождешься, когда ARB там родит новый стандарт - это поседеть можно. Вот где-то в этот момент MS просекла баг в такой организации производства графических апи (напомню, захоти кто-нибудь в той ситуации поддержать своим движком все новомодные штуки от обоих производителей видеокарт - пришлось бы писать фактически два куска когда, одинаковых по назначению, и нужных только для реализации одной и той же функции для разных видеокарт), решилась на коварный шаг. MicroSoft (кстати, она вышла из ARB еще в 2003) стала заглядывать к производителям видеокарт, консультироваться с ними о новых технологиях и о том, как бы они хотели, чтобы выглядел интерфейс управления их видеокартами, и тщательно и со рвением реализовывали пожелания. Причем настолько тщательно и с таким рвением, что зачастую новая версия DX с новыми фишками появлялись раньше, чем видеокарты нового поколения на полках магазинов, которые поддерживали бы эти новые штуки. По понятным причинам, используя DX, народ совершенно лишается геморроя с написанием дубликатов одних и тех же функций, может не ждать, когда наконец ARB что-нибудь родит, а могут действовать.

Кроме того, OpenGL - это спецификация, представляющая собой описание набора функций, структур и констант, которые должны быть реализованы одной библиотекой, и расширяются дополнительным функционалом путем просто добавления функций в список. Т.е. интерфейс - неизменен, а его реализация может меняться так, как хочет автор реализации.

DirectX базируется на основе COM-технологии, которая фактически убирает ситуацию DLL-Hell, обеспечивает полную независимость новых интерфейсов от старых (не говоря о реализации) и при этом обеспечивает обратную совместимость за счет включения старых версий библиотек, основанных на той же технологии и могущих быть использованными при запросе, в новый дистрибутив DirectX Redist. Это позволяет идти в ногу со временем и в новых версиях интерфейс разработать так, чтобы его было максимально удобно использовать как прикладным программистам, пишущим с использованием DX свои программы, так и системным, пишущим драйвера видеокарт.

А потом они еще и сделали библиотеку D3DX. И насовали туда столько функционала, что математический аппарат оттуда можно брать вообще целиком. А еще у них всякие DirectSound, отладочные инструменты, которые позволяют вообще все данные в видеопамяти поглядеть, профайлеры всякие, позволяющие оптимизировать все и вся, отладка шейдеров на HLSL прямо в студии и моно всяких прочих приятных штук, которые позволяют отлаживать рендер почти во всех необходимых плоскостях.

Правда разработчикам кроссплатформенного ПО приходится мириться с тем, что есть - OpenGL, ARB, Khronos Group.

http://ns.kevlo.org/projects/avila/a...eebsd-logo.gif

http://ru.fishki.net/picsw/092010/10...tivator082.jpg

http://ru.fishki.net/picsw/092010/24/mail/anthonyus.jpg

Уродство, когда для любого действия у системы есть специальный интерфейс. В Unix – все наоборот. Она предоставляет строительные блоки, из которых можно создать что угодно. Вот что такое стройная архитектура. То же самое с языками. В английском 26 букв, и с их помощью можно написать все. А в китайском для каждой мыслимой вещи – своя буква. В китайском вы сразу же получаете в свое распоряжение сложные вещи, которые можно комбинировать ограниченным образом. Это больше напоминает подход VMS: есть множество сложных вещей с интересным смыслом, которые можно использовать только одним способом. И в Windows то же самое.