Пользователь
0,0
рейтинг
1 июля 2011 в 14:19

Разработка → История противостояния OpenGL и Direct3D перевод

Перед тем как мы начнём, скажу: я знаю об OpenGL гораздо больше чем о Direct3D. Я в жизни не написал ни одной строки кода для D3D, и я писал руководства по OpenGL. Так что то что я тут расскажу, не вопрос предвзятости. Теперь это просто история.


Зарождение конфликта



Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.

У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.

Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование. Единый API для графики, звука и пользовательского ввода.

И так родился DirectX.

3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.

И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду. И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.

Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API — OpenGL.

Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста — привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.

Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.

Восход OpenGL



Итак, расклад сил был определён: Direct3D против OpenGL. Это действительно интересная история, учитывая насколько ужасен был D3D v3.

Комитет Архитектурных Решений OpenGL («Architectural Review Board», ARB) был организацией, ответственной за поддержку стандарта OpenGL. Они выпустили много расширений, следили за репозиторием расширений и создавали новые версии API. В Комитет входили многие влиятельные игроки графической индустрии и разработчики ОС. Apple и Microsoft в своё время тоже входили в этот комитет.

Потом появился 3Dfx с Voodoo2. Это было первое устройство, способное выполнять мультитекстурирование, чего OpenGL делать раньше не мог. Хотя 3Dfx совершенно не вписывался в стандарт OpenGL, NVIDIA, разработчик последующих графических чипов с мультитекстурированием (TNT1), положили глаз на эту реализацию. ARB пришлось выпустить расширение: GL_ARB_multitexture, которое давало доступ к мультитекстурированию.

В это же время вышел Direct3D v5. Теперь D3D стал настоящим API, а не странным куском кошачьей рвоты. Проблема? Отсутствие мультитекстурирования.

Упс.

По большому счёту, это было не так важно как должно было быть, потому что люди особо не использовали мультитекстурирование. По крайней мере напрямую. Мультитекстурирование сильно ухудшало быстродействие, и во многих случаях просто не было смысла использовать его вместо multi-passing. И, естественно, разработчики игр старались убедиться что их игры заработают на старом железе, в котором мультитекстурирования не было, и многие игры его просто не использовали.

D3D это сошло с рук.

Прошло какое то время и NVIDIA выпустили GeForce 256 (не GeForce GT-250; самый первый GeForce), по большому счёту прекратив гонку вооружений в графических ускорителях на следующие два года. Основная продающая фишка — возможность делать вертексные преобразования и освещение (T&L) аппаратно. Но это не всё: NVIDIA настолько полюбили OpenGL, что их движок T&L по сути и был OpenGL. Причём буквально: насколько я понимаю, некоторые регистры действительно напрямую принимали объекты OpenGL в качестве значений.

Выходит Direct3D v6. Наконец появилось мультитекстурирование, но… нет аппаратного T&L. У OpenGL всегда был конвеер T&L, даже до того как вышел 256 он был реализован программно. Так что для NVIDIA было не очень сложно преобразовать программную реализацию в аппаратную. В D3D аппаратный T&L появился только к седьмой версии.

Рассвет шейдеров, сумерки OpenGL



Потом вышел GeForce 3 и одновременно произошло много вещей.

Microsoft решили что теперь-то они уж точно не опоздают к празднику. И вместо того чтобы смотреть что делают NVIDIA и копировать это постфактум они пришли к NVIDIA и поговорили. Потом они полюбили друг друга и от этого союза появилась маленькая игровая приставка.

Потом был болезненный развод. Но это совсем другая история.

Для PC это значило что GeForce 3 вышел одновременно с D3D v8. И несложно увидеть насколько GeForce 3 повлиял на шейдеры в восьмерке. Пиксельные шейдеры в Shader Model 1 были очень сильно привязаны к железу NVIDIA. Аппаратной абстракции от NVIDIA не было вообше; SM 1.0 по сути был тем что делал GeForce 3.

Когда ATI вступили в гонку производительных графических карт со своим Radeon 8500, обнаружилась проблема. Пиксельный конвеер 8500 был мощнее чем у NVIDIA. И Microsoft выпустил Shader Model 1.1, который по сути был «тем что делал 8500».

Это может показаться провалом со стороны D3D. Но провал и успех это вопрос относительный. Настоящий провал происходил в стане OpenGL.

NVIDIA любили OpenGL, поэтому когда вышел GeForce 3, они выпустили комплект расширений OpenGL. Проприетартных расширений, подходящих только для NVIDIA. Естественно, когда вышел 8500, он не мог использовать ни одно из них.

Видите ли, в D3D v8 вы по крайней мере можете запустить шейдеры SM 1.0 на железе ATI. Естественно, чтобы использовать вкусности 8500 Вам придётся написать новые шейдеры, но Ваш код по крайней мере работал.

Чтобы получить хоть какие то шейдеры на 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Проприетартных расширений, подходящих только для ATI. Итак, Вам приходилось писать два пути выполнения кода, для NVIDIA и для ATI, чтобы иметь хоть какие то шейдеры.

Сейчас Вы наверняка спросите: «А чем занимался OpenGL ARB, чьей работой было поддержание OpenGL в актуальном состоянии?». Да тем же, чем занимаются большинство комитетов: тупил.

Видите ли, выше я упомянул ARB_multitexture потому что это тоже часть этой истории. С точки зрения внешнего наблюдателя ARB пытался вообще избежать добавления шейдеров. Они посчитали что если создать достаточно конфигурируемый конвеер с фиксированными фунцкиями он сможет сравняться по возможностям с шейдерными конвеерами.

И ARB стал выпускать расширение за расширением. Каждое расширение, в названии которого присутствовало «texture_env» было очередной попыткой залатать этот стареющий дизайн. проверьте реестр: между расширениями ARB и EXT таких вышло аж восемь штук. Многие вошли в основные версии OpenGL.

Microsoft в это время были участником ARB; они ушли примерно во время выхода D3D 9. Так что в принципе, вполне возможно что они каким то образом саботировали разработку OpenGL. Я лично сомневаюсь в этой версии по двум причинам. Во первых, им пришлось бы заручиться помощью других членов комитета, поскольку у одного участника только один голос. И, что более важно, во вторых, Комитету не нужен был Microsoft чтобы прийти к такому провалу. Чуть позже мы увидим что так и получилось.

Со временем ARB, скорее всего под натиском ATI и NVIDIA (очень активных участников) проснулся настолько чтобы принять шейдеры ассемблерного типа.

Хотите увидеть еще большую глупость?

Аппаратный T&L. Который в OpenGL появился раньше. Тут вот что интересно. Чтобы выжать максимальную производительность из аппаратного T&L, Вам необходимо хранить данные в GPU. В конце концов, именно в GPU они используются.

В D3D v7 Microsoft представил концепцию вертексных буферов. Это выделенные области памяти GPU для хранения данных о вертексах.

Хотите узнать когда в OpenGL появился свой аналог этого? О, NVIDIA, будучи фанатом всего что относится к OpenGL (до тех пор пока написанное остаётся проприетарным расширением NVIDIA), выпустили расширение для вертексных массивов еще при первом выпуске GeForce 256. Но когда ARB решил официально предоставить подобный функционал?

Два года спустя. Это случилось после того как они одобрили вертексные и фрагментные шейдеры (пиксели в языке D3D). Вот сколько времени заняла у ARB разработка кроссплатформенного решения для хранения данных в памяти GPU. Именно то, что нужно чтобы выжать максимум из аппаратного T&L.

Один язык чтобы всё разрушить



Итак, разработка OpenGL была раздроблена. Нет единых шейдеров, нет единого хранилища в GPU, когда пользователи D3D уже наслаждались и тем, и другим. Могло ли стать ещё хуже?

Ну… можно сказать и так. Встречайте: 3D Labs.

Кто они такие, спросите Вы? Это разорившаяся компания которую я считаю настоящими убийцами OpenGL. Естественно, общая вялось ARB сделала OpenGL уязвимым, когда он должен был бить D3D на всех фронтах. Но 3D Labs это возможно самая большая причина текущего рыночного положения OpenGL. Что они могли сделать такого?

Они разработали Язык Шейдеров OpenGL.

Дело в том что 3D Labs была умирающей компанией. Их дорогие ускорители стали ненужными когда NVIDIA усилили давление на рынок рабочих компьютеров. И, в отличие от NVIDIA, у них не было никакого присутствия на общем рынке; если бы NVIDIA победила, они бы исчезли.

Так и получилось.

И, в попытке остаться на плаву в мире, которому не нужна была их продукция, 3D Labs появились на Game Developer Conference с презентацией того что они назвали «OpenGL 2.0». Это должно было стать полностью переписанным с нуля API OpenGL. И это имело смысл; в API OpenGL было немало шероховатостей (примечание: они есть и сейчас). Просто посмотрите на что похожа загрузка и привязка текстур; это просто какая то чёрная магия.

Частью их предложения был язык шейдеров. Вот так. Однако, в отличие от текущих кросс-платформенных расширений ARB, их язык шейдеров был «высокоуровневым» (C это высокоуровневый язык для шейдеров. Нет, правда).

Итак, Microsoft в это время работали над своим собственным высокоуровневым языком шейдеров. Назвали они его, по своей давней привычке, «Высокоуровневым Языком Шейдеров» (HLSL). Но подход к языку был в корне другим.

Самая большая проблема языка шейдеров от 3D Labs была в том что он был встроенным. Видите ли, HLSL был языком, определённым Microsoft. Они выпустили для него компилятор, который генерировал ассемблерный код для Shader Model 2.0 (и последующих версий), который Вы вставляли в D3D. В дни D3D v9, HLSL никогда не вызывался из D3D напрямую. Он был удобной абстракцией, но совершенно необязательной. У разработчика всегда оставалась возможность отложить компилятор и доработать код до максимальной производительности.

В языке 3D Labs ничего этого не было. Вы скармливали драйверу код на C-подобном языке, и он возвращал шейдер. Всё, конец истории. И не ассемблерный шейдер, не то что можно вставить куда нибудь. Настоящий объект OpenGL, представляющий шейдер.

Это означало что пользователи OpenGL были беззащитны перед ошибками разработчиков, которые только начали разбираться с компилируемыми ассемблеро-подобными языками. Баги компилятора в новом языке шейдеров OpenGL (GLSL) ходили просто табунами. Что еще хуже, если Вам удавалось правильно скомпилировать шейдер для нескольких платформ (само по себе непростая задача), Вам всё равно приходилось иметь дело с оптимизаторами того времени. Которые были не так оптимальны, как могли бы.

Хотя это было главной проблемой GLSL, но не единственной. Далеко не единственной.

В D3D, как и старых ассемблерных языках OpenGL, можно было смешивать вертексные и фрагментные (пиксельные) шейдеры. Пока они использовали единый интерфейс, можно было использовать любой вертексный шейдер с любым совместимым фрагментным шейдером. Кроме того были уровни несовместимости, которые в принципе можно было терпеть; вертексный шейдер мог выдавать данные, которые фрагментный шейдер просто не читал. И так далее.

В GLSL ничего такого не было. Вертексные и фрагментные шейдеры были собраны в единую абстракцию, которую 3D Labs назвали «программный объект». И если Вам хотелось использовать вместе вертексные и фрагментные программы, Вам приходилось строить несколько таких программных объектов. И это было причиной второй проблемы.

Видите ли, 3D Labs думали что поступают очень умно. Они основали модель компиляции в GLSL на C/C++. Вы берёте .c или .cpp и компилируете в объектный файл. Потом Вы берете один или несколько объектных файлов и линкуете их в программу. Вот так и происходит компиляция в GLSL: вы компилируете шейдер (вертексный или фрагментный) в объект шейдера. Потом Вы помещаете этот объект шейдера в программный объект и связываете их вместе чтобы получить программу.

Хотя это позвляло делать некоторые потенциально крутые вещи вроде «библиотек» шейдеров, содержащих дополнительный код, который совместно использовали основные шейдеры, на практике это означало что шейдеры компилировались дважды. Один раз на этапе компиляции, один раз на этапе линковки. Не создавалось никакого промежуточного объектного кода; шейдер просто компилировался, результат компиляции выбрасывался и компиляция повторялась во время линковки.

Так что если Вы хотели связать Ваш вертексный шейдер с двумя разными фрагментными шейдерами, Вам приходилось компилировать куда больше кода, чем в D3D. Тем более что вся компиляция C-подобных языков происходила при разработке, а не при запуске программы.

У GLSL были и другие проблемы. Возможно неправильно винить во всём 3D Labs, потому что ARB в конце концов одобрила и приняла этот язык (но ничего кроме него из их предложения «OpenGL 2.0» не прошло). Но идея была именно их.

А вот действительно печальная часть. 3D Labs по большому счёту были правы. GLSL это не векторный язык шейдеров, каким всегда был HLSL. Так случилось потому что железо 3D Labs было скалярным железом (так же как современные карты NVIDIA), но в целом они были правы по части направления развития ускорителей.

Они также были правы с «compile-online» моделью для «высокоуровневых» языков. D3D впоследствии тоже на неё перешёл.

Проблема была в том что 3D Labs оказались правы в неправильное время. И в попытке призвать будущее слишком рано, в попытке его предугадать, они отбросили настоящее. Это также как OpenGL всегда имел возможность делать T&L. Если не считать того что конвееры T&L в OpenGL были полезны ещё до выхода аппаратной реализации, а GLSL был просто обузой прежде чем мир оказался готов его принять.

Сейчас GLSL — хороший язык. Но для своего времени он был ужасен. И OpenGL пострадал за это.

Приближается апофеоз



Хотя я и утверждаю что 3D Labs нанесли смертельный удар, именно комитет ARB забил последний гвоздь в крышку гроба OpenGL.

Эту историю вы наверняка слышали. Во времена OpenGL 2.1, OpenGL встал перед проблемой. У него было много старых неровностей. API было сложно использовать. Для каждого действия существовало по пять способов и никто не знал, какой окажется самым быстрым. Можно было «изучить» OpenGL по простым руководствам, но никто не говорил Вам какое API даст Вам максимум производительности.

И ARB решил сделать ещё одну попытку изобрести OpenGL заново. Это было похоже на «OpenGL 2.0» от 3D Labs, но лучше, потому что за ней стоял ARB. Попытку назвали «Longs Peak».

Что было не так с попыткой исправить старые API? Плохо было то что Microsoft в то время были уязвимы. Это было время выхода Vista.

В Vista Microsoft решили ввести давно необходимые изменения в драйверах дисплея. Они заставили драйверы обращаться к ОС для виртуализации видеопамяти и многих других вещей.

Хотя можно сомневаться в том было ли это необходимо, но факт остаётся фактом: Microsoft решили что D3D 10 будет только для Vista (и последующих ОС). Даже если у Вас было железо, способное выполнять функции D3D 10, Вы не могли запускать D3D 10 приложения без запуска Vista.

Вы также наверное помните, что Vista… ну, скажем просто что она получилась не очень. Итак, у Вас была тормозная ОС, новое API, работающее только на этой ОС, и новое поколение ускорителей которым было нужно API и ОС чтобы превзойти предыдущее поколение ускорителей.

Однако, разработчики могли бы получить доступ к фунциям уровня D3D 10 через OpenGL. Ну, смогли бы, если бы ARB не были так заняты работой над Longs Peak.

По большому счёту, ARB потратил полтора-два года на то чтобы сделать API лучше. Когда вышел OpenGL 3.0, время Vista уже заканчивалось, на горизонте появилась Win7, и большинство разработчиков уже не интересовались фунцкиями D3D-10. В конце концов, железо для которого предназначался D3D 10 замечательно работало с D3D 9. А с расцветом портов с PC на приставки (или PC-разработчиков, занявшихся разработкой для приставок) функции класса D3D 10 оказались невостребованы.

Если бы у разработчиков был доступ к этим функциям раньше, через OpenGL на машинах с WinXP, разработка OpenGL получила бы так необходимый импульс. Но ARB упустил эту возможность. И знаете что самое плохое?

Несмотря на то что два ценных года были потрачены на разработку API с нуля… они всё равно провалились и вынуждены были вернуться к предыдущей версии.

То есть, ARB не только упустили замечательную возможность, но и не сделали ту задачу, ради которой возможность была упущена. Просто полный провал.

Это и есть история борьбы OpenGL и Direct3D. История упущенных возможностей, огромной глупости, слепоты и просто безрассудства.
Перевод: Nicol Bolas
Сергей Широков @kurokikaze
карма
196,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (132)

  • +1
    7 (семь) «видите ли» на один небольшой текст — перебор.
    Ну и начало улыбнуло: я знаю об А много, а о Б ничего. Сейчас я расскажу об А и Б, но это не вопрос предвзятости.
    • +74
      Поскольку при этом он мрачно бранит А (именно А, а не Б), то это, пожалуй, и впрямь не вопрос предвзятости.
      • +1
        Интересно, в стане OpenAL такие же настроения?
  • +1
    История очень тягостная, как фильм «Human Centipede».
    • +8
      Ничего себе ассоциации. История грустная, да.

      Так сложилось, что для меня в любом программном продукте есть душа. Нейминг, визуальная, маркетинговая составляющие + интерфейс доступа (будь то API или иные способы взаимодействия), все это, в совокупности, дает некую ауру. Именно по этому я пользуюсь только NVIDIA и люблю OpenGL, не могу объяснить. Не знаю на хрена вставил эту бодягу сюда, захотелось высказаться )
  • +21
    Проблемы, как обычно, начались когда кто-то к кому-то пришёл без очередей и записи и «поговорил».
    • +1
      на минуточку, только спросить...)
  • 0
    No offence, но прямо и хочется написать: «выдыхай, бобер!».
    • +1
      Почему вам это хочется написать?
      • 0
        Статья смотрелась бы иначе, имей она важный дискляймер — «речь пойдет о PC, причем именно PC/Win». Ибо это только сегмент систем с возможностью визуализации, не более того.
        • 0
          Мне кажется «Direct3D» в названии достаточно чётко указывает на платформу.
          • +1
            Судя по упоминанию различных девайсов в комментах — не так уж и четко :)
  • +9
    Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API — OpenGL.
    Новый (современный) Джон Кармак считает наоборот. Carmack: Direct3D is now better than OpenGL
    • +16
      … is now…
    • +7
      Предатель.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +3
          Хотите сказать, что харизма Кармака не обращала ранее людей в ряды адептов OpenGL? Да для меня Кармак был один из тех, кто видел что все хуево, но все равно говорил, что его новый движок будет OpenGL-based ибо это разумно.
          • +1
            Во времена Кармака был D3D, OpenGL и ныне покойный GLIde. И единственным в то время недостатком OpenGL было отстутствие в комплекте библиотеки работы с матрицами и векторами.
            GLIde — была удобна но закрыта. D3D — тогда ещё не был достойным конкурентом.
            • +2
              Когда закончились времена Кармака по вашему?
              • +1
                В игрострое вместе с Q3. Но он вполне может вернуться.
                • 0
                  Разве не Doom 3 был лебединой песней?
                  • +3
                    Дум 3 — вполне годный проект. Но не для гения размера Кармака. Сравните, если грубо:

                    Вульфенштейн + Дум — родоначальники жанра FPS. И Модель распространения демоверсий через BBS.

                    Квейк — первый 3D шутер. И Игра по сети.

                    Потом провалившийся из-за маркетинговых просчётов массовый FPS. Так вообще опередил своё время.

                    Потом Вторая квака — шутер с встроенной историей.

                    Потом Квейк Арена — командное мегамочилово.

                    И всё. после просто качественные проекты, и ничего за гранью как раньше.
                    • +3
                      Знаете, сам задрот-олдфаг, но все-таки Doom 3 это была очередная Значимая OpenGL ступень Кармака и id Tech движка, имхо. С остальным же полностью согласен.
                      • +2
                        Вот именно, это была только их ступень.
                        А до этого это были ступени не только для них но и для игровой индустрии.
                    • +2
                      Во-первых, стрелялок с сюжетом не просто для галочки был с десяток до Quake 2.
                      Во-вторых, Quake 3 и Unreal Tournament разрабатывались более-менее одновременно и движок у Кармака вышел уже не столь очевидно превосходящим конкурентов, а по некоторым мнениям даже худший. Более того, в “командном мегамочилове” не было ни одного командного режима.

                      Прорывы закончились на Q1.
                      • 0
                        Скорее на Quake 2. Не было сравнимого FPS на то время.

                        А вот дальше да, согласен. Но это все дела минувших дней.

              • 0
                С выходом Unreal / Tournament не?
    • 0
      У него просто контракт с OpenGL закончился :)
  • +14
    Ситуация с OpenGL чем то напоминает ситуацию с Xorg… Или наоборот?..
  • +4
    крышку гроба OpenGL
    и что теперь будет с OpenGL для iOS и Android?
    • +16
      JavaScript != java
      Object C != C++
      OpenGL ES != OpenGL

      • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      А там не OpenGL, а OpenGL ES
  • –1
    "Они заставили драйверы обращаться к ОС для виртуалищации видеопамяти и многих других вещей."

    Поправьте пожалуйста «виртуализации».
  • 0
    Хороший комент по вашей же ссылке:
    One last thing, PLEASE EVERYBODY ON THE INTERNET STOP COMPARING OPENGL AND DIRECTX! Either compare Direct3D vs OpenGL or don't do this. DirectX provides input support, sound support, movie playing, etc etc that OpenGL doesn't.
    • +7
      Ну, в этом комменте просят не сравнивать OpenGL и DirectX, а либо сравнивать OpenGL и D3D, либо не сравнивать вообще. В этом переводе сравнивается именно OpenGL и D3D.
      • +1
        Точнее OpenGL vs DirectDraw+Direct3D. Вроде бы корректно…
        • +1
          DirectDraw уже вообще не имеет смысла с чем то сравнивать.
        • +3
          дайрект дро ж закопали таки в итоге
          • +1
            а я его еще помню :) даже книжку недавно нашел по нему — сдул пыль и положить на полку — историю надо знать!
    • +1
      Этот пост в основном про Direct3D.
  • +4
    Я помню в Windows 95 одним из штатных скинсейверов была плавающая фраза «Open GL»
    • +3
      А я помню что после покупки 3д-ускорителя все эти OpenGL заставки так и не были аппаратно ускорены, что меня сильно в свое время удивило)
    • +3
      Нет-нет. Только в Windows 95 OSR 2.
    • +3
      А я помню, как ко мне курсе на втором пришёл старшекурсник — ему нужно было написать курсовик по трёхмерной графике, я взял готовый пример с планетами из Delphi, что-то там подправил и продал ему. У меня тогда была Riva TNT. На компе у препода не было ускорителя и программка аццки тормозила. Наверное, так я и стал быдлокодером :)
  • +14
    Когда я начинал писать под D3D я ужасался тому, что многие вещи, которые очень просто реализовывались в OpenGL, в D3D реализовывались очень и очень сложно через адские COM интерфейсы. Возможно именно тот факт, что автор плохо знаком с D3D, сказывается на его убеждении, что OpenGL мертв. Как известно: всегда лучше там, где нас нет. Всегда кажется, особенно если ты успел собрать все подводные камни в некоторой технологии, что другая технология окажется серебряной пулей и решит все проблемы.
    Впрочем, я уже года 4 не притрагивался ни к OGL, ни к D3D. Неужели в противостоянии OGL и D3D всё действительно так плохо?
    • +11
      Не всё так плохо. Стремительно врываются новые платформы — iOSы, плейтейшены и Android'ы.

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

      А вот ценность DirectX для Майкрософта — сомнительна. В какой-то момент они могут и слить эту технологию, и поддержать GL. Да и Windows — уже не безусловный лидер. Т.е. на десктопах — конечно да, но ведь развивается ниша и планшетов, и ARM ноутбуков, и телефончиков. Так что от GL не откажутся.

      Другой вопрос — нужно ли 3д на недесктопах?
      ИМХО — Пока не особенно, но мощности всё же растут, и фишки люди хотят видеть уже и на дешёвых китайских смартфонах. А там уж точно лицензионной винды (даже мобайл) не будет никогда. А GL будет.

      Сейчас на ПК, только доступность специалистов является определяющей при выборе из этих двух технологий. А на не ПК — всё уже решено.

      Так вот — моё имхо — специалисты владеющие GL — не переведутся. И даже размножатся. И в каой-то момент GL придёт и на PC. Директу не выжить в такой борьбе. Вопрос времени.
      • –1
        >Т.е. на десктопах — конечно да, но ведь развивается ниша и планшетов, и ARM ноутбуков, и телефончиков.
        XNA (угадайте на чём основан) работает на телефоне, консоли и ПК.

        Если это не мультиплатформенность, я даже не знаю.
        • +8
          Вы только забыли добавить про то что софт Консоли, ПК и телефона должны быть от майкрософт.
          Если это кроссплатформенность, то я даже не знаю…
          • –5
            И что в этом плохого, или ваша позиции вроде этого:
            «ААХХХ M$ — КОРПОРАЦИЯ ЗЛА!!!».

            >Если это кроссплатформенность, то я даже не знаю…
            Укажите на противоречие.
            • +15
              То что список платформ — закрыт. И расширяться не будет.
              Технология невыгодна для проектов с потенциально широким охватом аудитории.

              Да, мы покроем 85% десктопов и 1% телефонов. И 20% приставок.
              Но на GL — мы покроем 100% десктопов, 99% телефонов, много мультимедиа плееров, 80% приставок, читалки, кучку планшетов, полсотни миллионов телевизоров, 34 модели холодильников и пару пылесосов.

              Не считая гаджетов, которые появятся только в следующем году.

              Для меня выбор — очевиден. И корпорации тут не причём.
              Просто на GL под майкрософтовские оси писать можно а на директе под немайкрософтовские нельзя.
              • –5
                Вы знаете, мало убедительно.

                1. Прикольно, конечно, что есть «34 модели холодильника» и прочее, но толку в этом? Играют люди либо на ПК, либо на приставках (ну да, еще в Angry Birds на айпаде). ПК и приставки закрываются DirectX-ом. Чего еще надо?
                2. Наивно надеяться, что Ваш код вот сразу «полетит» на всех пылесосах. Автор статьи очень хорошо объяснил, что OpenGL'я есть куча версий разных вендоров, версий, расширений и т.д. У Вас в коде будет куча «иф (хБокс) { рисовать_вот_так() }. Такой код не жизнеспособен.
                3. DirectX развивается (посмотрите на современные видеокарты, 3-д движки, и самое главное — на то, на чём сегодня делается большинство игр). OpenGL (опять таки со слов автора статьи) тупит и ходит кругами.

                В общем, OpenGL клёвая штука для каких-нибудь OpenSource-проектов, демок, для курсача или когда и вправду стоит задача „чтоб кругом работало хоть как-то“. Но коммерческий продукт под десктоп, я считаю, сегодня можно делать только на DirectX.
                • +6
                  Если коротко — не согласен!

                  Коммерческих проектов под десктоп на GL сделано не мало. На директе тоже были, но давно.

                  Приставки — это не только XBox.
                  • +1
                    Сколько людей — столько мнений. У меня просто обратная ситуация — OpenGL был давно, а вот на DirectX последние пару лет пишу. Возможно, я ошибаюсь в своей категоричности, просто озвучил «вид со своей колокольни».

                    Конечно, приставки бывают разные.
                    • +7
                      Я повторю свою основную мысль — в большинстве случаев пофиг на чём писать. Писать надо на том в чём опыта больше на данный момент. Мелкие различия в функциональности — не важны и всегда обходятся.

                      Но иногда всё таки GL — правильнее ;-), но зависит только от проекта это.
                      Да и с QT очень хорошо сочетается. А на QT мы подсели плотно ;-)
                • +2
                  > Но коммерческий продукт под десктоп, я считаю, сегодня можно делать только на DirectX.

                  *sigh* blog.wolfire.com/2008/12/why-you-should-support-mac-os-x-and-linux/

                  С точки зрения делания бабла целесообразно будет ограничить понятие “десктоп” до “виндовс” только если вы готовы потратить миллионы долларов на рекламу, иначе… в статье по ссылке выше всё сказали.
                  • 0
                    Ребята в этой статье:
                    1. Заработали половину денег на продажах софта под винду
                    2. Нифига не заработали на продаже той же софты под линукс
                    3. Гордо и красиво срубили на своей инди-игре (или чего они там продавали) аж 1 раз в жизни ну может пару килобаксов. А всякие конторы, реально смотрящие на мир (Вальв, Близзард, ИД и т.д.) пишут себе под Винду очередные Варкрафты да Халф-Лайфы и скромненько свою сотню вечнозелёных лимонов в год получают.

                    Так что статья прекрасно доказывает противоположный своему названию факт.
                    • 0
                      Почитайте статью (да хотя бы мой комментарий) разув глаза и поймёте что статья прекрасно доказывает и то что написано в её названии и ваш третий пункт.

                      Впрочем, чего я тут распинаюсь. Вам деньги не нужны — кто-нибудь другой подберёт.
                    • +1
                      валв и ид используют openGL, поэтому и делают кросс-платформенные игры. помимо винды и хбокса ид пишут под линукс, а валв — под макось и пс3.
                    • +1
                      А всякие конторы, реально смотрящие на мир (Вальв, Близзард, ИД и т.д.) пишут себе под Винду очередные Варкрафты да Халф-Лайфы
                      Лол, все дела. Скриншот прилагается.


                      Это Мак, папка с играми, все нативные. Starcraft прошел и удалил, только сейвы остались.
                    • +1
                      Кстати, есть еще Age of Empires III под Мак, издательства, сюрприз, Майкрософта.
                    • +2
                      Мил человек, разберитесь сначала в том, как устроены различные платформы. Затем, как пишутся игры.
                      А после, что практически все игровые движки высокого уровня используют абстрактный рендер, а он может использовать как OpenGL, так и D3D. Примеры таких движков: Unreal Engine, CryEngine (OpenGL с 3 версии по-моему), Source, да и любые кросс платформенные движки.
                      Если вы думаете, что это дешевые инди-проекты, то с вами нет смысла разговаривать по этой теме.

                      OpenGL — это изначально кросс платформенное API, так что если не писать мультирендер, то надо писать на нем, если хотите что-то кроме Windows.
                    • НЛО прилетело и опубликовало эту надпись здесь
                • +2
                  1) DirectX есть только на Xbox, а он не есть все приставки.
                  Небезызвестная PS3 DirectX не поддерживает, а вот OpenGL ES с радостью.

                  2) Наверное проще все-таки исправить только некоторые функции, чем перелопачивать всю систему рендеринга.

                  >иф (хБокс) { рисовать_вот_так() }.
                  Ээ не знаю, кто так пишет, и где вы такое увидели. Посмотрите внимательнее на кросс платформенные решения. Если проект задумывается как кросс платформенный, то разработчики впринципе не задумываются о том, какой рендер будет использоваться. Пишется некая абстракция рендера, либо используется OpenGL, хотя 1 вариант лучше

                  3) Ну тут соглашусь. Правда, какие игры вы берете в расчет: ААА-проекты (кросс платформенные) или проекты студий (как правило, Windows)?

                  OpenGL изначально использовался как стандарт промышленной графики, и там он до сих пор лидер. Крупные графические станции работают в большинстве на Unix-системах, следовательно OpenGL, либо программные методы.
                  Кстати, 3D Max, AutoCAD, Maya кросс платформены и работают на платформах отличных от Windows. Или вы считаете их мелкими проектами?
                  • 0
                    «Пишется некая абстракция рендера» — а она разве не содержит кода типа иф (хБокс) { рисовать_вот_так() }.?
                    • +1
                      Ну как делал я:
                      Абстрактный класс рендера, от него наследуются классы рендеров для отдельных API. Так например сделано в CryEngine, Orge, остальные не уверен.
                      При использовании данной схемы логика приложения не меняется, а просто меняется класс/библиотека.

                      А вообще, вы думаете, что программа компилируется один раз и выполняется на всех системах сразу? Такие условия могут быть, разве что, в директивах компилятора.
                      • +1
                        ну, т.е. этот if таки будет, хоть и всего один, в фабрике класса-рендера. Но всё равно будет.
                        • +1
                          Ну если так посудить, то условия будут везде, где используются низкоуровневые функции (окна, ввод и т.д.).
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • +1
                            хм… Тоже вариант.

                            Однако, иногда разные рендеры доступны на одной платформе, тогда программе всё ж приходится выбирать в рантайме.
                            • +1
                              Доступны, но они сделаны в пределах 1 платформы и выбираются, скорее всего, исходя из настроек.
                              Для Xbox нет смысла такое делать, так как там всего 1 рендер, а вот PC очень даже.
            • +5
              Обвинять всех вокруг в фанатизме при малейшем намёке на использование технологии конкурентов — первый признак фанатизма.
        • +7
          >работает на телефоне, консоли и ПК.

          а нужно, чтобы работало на телефонах, консолях и маках. Тогда это можно будет уверенно назвать кроссплатформенным
          • –5
            Ну да, три девайса с различной архитектурой — неуверенная такая кроссплатформенность.
            Зашибись, у вас тоже позиция: «ААХХХ M$ — КОРПОРАЦИЯ ЗЛА!!!»?

            Смысл им конкурентов то поддерживать.
            • +4
              А смысл разработчику поддерживать технологию которая не лучше, но имеет больше ограничений?

              Повторюсь — если вам надо писать под Windows — используйте то с чем лучше знакомы вы или доступные вам специалисты.

              Если надо не только под Windows — то появятся другие критерии выбора. И вполне возможно что надо будет и два дровера поддерживать — это на самом деле не так сложно как кажется. Но один проще и удобнее сопровождать ;-)
            • +1
              предпочитаю называть это экосистемой.

              >Смысл им конкурентов то поддерживать.
              в случае WP7 им нужно скорее заманить разработчиков с существующих платформ. XNA тут скорее помеха
  • +8
    Прочитал «на одном дыхании».
  • +1
    Никогда если честно не замечал того, какие войны идут между OpenGL и D3D (впрочем и занимался в данной области достаточно мало). Можно сказать — Вы представили изнанку этого мира.
    Очень интересно, а главное, вписывается в то, какими мне помнятся старые «машинки» и часть истории развития 3D :)
  • +3
    Чистая правда. Разработка OpenGL всегда была очень консервативным делом, промышленный стандарт, большое количество компаний, которые преследуют свои интересы. Невозможность и нежелание договориться почти убили OpenGL. В то время как Microsoft все решали быстро и единолично, хоть и не всегда правильно.
    • +1
      Хоть-какое решение, принятое сейчас и реализованное через 3 месяца намного лучше идеального решения, принятого через 2 года и вообще никогда не реализованного. Microsoft успела и сделала. Остальные могут ругаться дальше.
  • +4
    Автор закончил на самом интересном месте). Хотелось бы услышать какой-то прогноз.
  • +9
    Статья хорошая. =)

    Для непосвященных в эту «войну» людей она действительно все очень последовательно раскрывает.

    Но лично мне кажется что можно было немного упомянуть о покупке 3dfx ее тогдашним конкурентом — Nvidia.
    Многие кстати наработки 3dfx, все еще актуальны и всплывают только сейчас от лица N.
    Например SLI…
    Также в Voodoo ускорителях впервые появилось сглаживание (фильтрация) текстур.

    Еще один момент. Было бы замечательно если бы автор довел историю до конца до OpenGL 4.x и рассказал о том каков он сейчас.

    Также популярность OpenGL на различных мобильных платформах дает о себе знать.
    И хоть OpenGL ES != OpenGL, все равно OpenGL ES на 90% тотже OpenGL.
    А смотря на современные характеристики железа на втором айПаде — я могу говорить что не загорами игры уровня второго Halo (первого — Nova 2). При всем при том что GLSL уже полноценно поддерживает на PowerVR чипах.

    И последний штрих. Maс OS X. У кого вопросы — заходим в Steam и смотрим список игр под эту платформу. =)

    PS: Пишу на OpenGL > 6 лет. =)
    • +6
      А расскажите про OpenGL 4.0?
      • +12
        Эту прерогативу я бы хотел оставить автору. Он начал варить кашу — пусть доваривает =)
        Вкратце могу сказать что к этой версии ARB расшевелились и дело пошло быстрее.
        И в данный момент Огл поддерживает все современные фитчи железок от обоих компаний.

        А то что лидеры разработки графического железа стараются постоянно улучшать драйвера под этот API сигнализируют подобные новости:
        www.geeks3d.com/20110617/test-incredible-performance-boost-in-opengl-tessellation-with-recent-catalyst-drivers/#more-7921
        • +3
          Не знаю честно говоря будет ли автор продолжать (я то только перевёл его рассказ), так что я присоединяюсь к просьбе раскрыть тему полнее :)
          • +6
            Сори, большой конфуз =) Не заметил что это перевод.
            Но дабы отстреляться могу вбросить ссылку на вики: ru.wikipedia.org/wiki/OpenGL
            В ней сухо описано новые возможности появившиеся в поколении 4.х

            Также есть хорошая статья на эту тему на англ:
            rastergrid.com/blog/2010/11/suggestions-for-opengl-4-2-and-beyond/
            (может найду время и сделаю перевод как нибудь =) )

            Вкратце скажу, что последние версии OpenGL по возможностям не менее круты чем D3D11, а с выходом спецификации 4.2 есть шанс стать у руля.

            Ключевым на мой взгляд моментом было доведение до ума Long Peak начиная с которого появилась возможность использовать новый тип контекста, который убирает ряд старого не нужного функционала и изменяет поведение конвейера, что повышает быстродействие API вцелом. =)
            • +1
              Да это же просто отличная новость. Получается, единственное, что осталось сделать разработчикам игр — массово поддержать OpenGL? (любителям графона на ПК это придется по душе :)

              Кстати, ребята из Unigine используют в своих бенчмарках и играх как D3D, так и OGL.
    • +9
      Ну и совсем последние штрихи Linux и WebGL, наступают по всем фронтам.
    • +3
      3dfx SLI это несколько другая технология (Scan Line Interleave)
      Фильтрация текстур появилась задолго до основания 3dfx
      • +3
        Поправлюсь, 3dfx имела наработки по использованию двух карточек в паре. По аналогии SLI от Nvidia.
        Я не имел ввиду что она также и называлась — название было другое.

        На счет фильтрации. Ну естественно, что фильтрация была изобретена намного раньше. Может еще до изобретения компьютеров.
        Но аппаратно ускоренная фильтрация текстур доступная на десктопах появилась у них. Непомню чтобы у первых 3Dfx ускорителей были конкуренты которые добились подобного раньше =)
        • 0
          название было именно такое SLI — ScanLine Interleave
          • +2
            а у nvidia SLI — Scalable Link Interface
          • +1
            Погуглил. Да походу название такое же. Но в любом случае — цель одинаковая заставить несколько карт пахать на одном поле сразу =)
            • +2
              Всмысле название разное а аббревиатура такая же =)
        • +1
          S3 ViRGE
          ATi Rage
          1995г
          правда 3d там было тормозное, но фильтрация была =)

  • +10
    Кстати вот ссылочка:
    blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
    Где подробно рассказыватся как Мелкомягкие постарались в свое время с пропагандой против OpenGL
  • +2
    Застал войну в самом разгаре(времена GF4-6800)
    Честно говоря не знаю что проблемы были у openGL — вроде особых то и не было.
    В начале выходили NV расширения, буквально через месяц приходил EXT или ARB.
    Под ДХ тоже самое приходило через годик — с выходном новой мажорной версии.
    Да, приходилось мухлевать и танцевать иногда — но так же интереснее!
  • +2
    Очень интересно почитать, что случилось с OpenGL с выходом 2.0. Я, помню, писал игры под OpenGL в те времена, когда он реально был круче Direct3D, когда Кармак говорил, что на Direct3D он писать не будет. Помню, когда появились первые спеки OpenGL 2.0 — эх, было время!
    • +1
      А что теперь случилось? Бросили писать игры или бросили писать под OpenGL? =)
      • +1
        Тогда я бросил писать игры, и как то больше не возвращался :(
        • +1
          вернитесь! :)
          • +2
            Ушли те времена, когда можно было командной из 5-6 ребят сделать игру на собственные средства, не спать ночами, искать издателя и думать о деньгах в самый последний момент.

            Сейчас процесс абсолютно обратный — сначала думаем как отбить деньги (то есть как можно меньше денег вбухать и получить как можно больше), потом найти издателя, а потом уже придумать идею и найти команду.

            Пропали те времена энтузиазма, новых технологий (я помню, когда С++ был просто bleading edge технологией), новых решений (что сделал 3dfx с рынком — это просто не передать).

            Сейчас надо найти бабло, лучше лямов 10 долларов (минимум, и то, 6-7 лямов это маркетинг) — а дальше по накатанной. Даже Кармак уже не тот — продался беседке. Хотя он, по некоторым моим связям, вообще немного подзабил на гейм дев.
            • +2
              Да ну, и сейчас такое есть. Вон тот же Marcus Persson со своим Minecraft или Toady One с Dwarf Fortress. Искать средства надо на AAA-игру.
              • +3
                Ну раз пошла такая пьянка, я могу вспомнить и super meat boy. Но тем не менее, это игры вообще другого уровня — одного, двух человек, которые пробились в топ или своей простотой и убойным экшенем (super meat boy), или потому, что вас раскручивали в социальных сетях (minecraft).

                Я говорю о тех временах, где не было категорий AAA игр. Вспомните, сколько людей делали duke nukem 3d? quake? warcraft и за какие деньги? Эти игры были открытием каждый в своей нише — то было время, когда можно было сделать что то за копейки в гараже, и все вокруг говорили wow, просто офигенный WOW, и ваше имя навсегда входило в историю.

                А что сейчас? Мерило игры — сколько денег вбухают. Вбухают $100 000 000, будет супер блокбастер. Вбухают $10 000 000 — получится середнячок.
                • +1
                  Сейчас не только AAA входят в историю, если это считать критерием. Инди вообще снова в моде. По крайней мере Notch и Toady точно сделали открытия в своих нишах.

                  Да и $100 000, по моему, не гарантируют сейчас блокбастера. На одних деньгах там не выедешь.
                  • +1
                    Хорошо — какие открытия сделали эти indie? Это опять таки другая тенденция — уровень порога стал максимально низким, издать indie игру очень просто — либо через app store, либо через xbox live. Издатель вообще не нужен. Но это игры уровня casual.

                    Кто то из indie сделали открытие в жанре fps/strategy/rpg и т.д., после которого вся индустрия (или большая часть) пошла по стопам indie разработчиков? Кто то сделал революцию уровня dune 2000/warcraft? doom/quake? diablo?
                    • +1
                      Индустрия имхо пока просто не успела пойти за ними. Другие разработчики — да, та же Terraria за Minecraft. Я не хочу сравнивать «уровни революции», поскольку это дело субъективное, но моё мнение — свой вклад инди-разработчики вполне внесли. По крайней мере в жанре песочниц после Black and White ничего нового толком не появлялось. MC, DF и Terraria его неплохо встряхнули.

                      И да, не всё из упомянутого — casual. Тот же Dwarf Fortress это полная его противоположность :)

                      Вообще сейчас сложнее сделать такие же открытия как в начале эры компьютерных игр. Все low hanging fruits уже обобраны.
                      • +2
                        «Вообще сейчас сложнее сделать такие же открытия как в начале эры компьютерных игр. Все low hanging fruits уже обобраны.'
                        Я как раз про это и говорю. Время ушло.
                        • 0
                          Время лёгких открытий ушло, это да, согласен. Но новое придумать ещё можно имхо, и нужно для этого не $100.000.
                          • +2
                            Придумать то можно, а вот сделать так, чтобы об этом новом узнала широкая аудитория — вопрос бюджета
            • +3
              Даже Кармак уже не тот — продался беседке. Хотя он, по некоторым моим связям, вообще немного подзабил на гейм дев.

              Он теперь ещё и ракеты запускает link.
        • +3
          эх, я тоже вспомнил молодость(9-10 класс) :) когда запоем изучал доки по directx, радовался gourand освещению, мечтал сделать progressive lod для ландшафта и читал бесконечные холивары на геймдеве openGL vs Direct3D…
  • +1
    Мало что понял, но чтиво увлекательное. Автор, пиши еще.
    • +1
      вот именно :) во время чтения очень жалел, что нифига не понимаю в этих их GLSL, вертексных шейдерах, конвеерах и т.д., а то было бы так интересно! :D
  • +7
    В 95 году на сцену вылазил еще один игрок со своей графической 3Д библиотекой — Intel.
    Проект назывался 3DR/3DG/3DW. Почувствовав угрозу, Microsoft договорился с Intel и проект прикрыли.

    Помню игра Falcon под 3DR летала на 20-25% быстрее конкурентов. В то время все разработчики игр плевались на DirectX и боготворили OpenGL.

    Под 3DR было программировать почти так же приятно, как под OpenGL.
  • +5
    Дааа, ностальгия…
    Вначале был OpenGL… PC потом SGI…
    Затем D3D3, (впоследствии ковыряя сорцы Mesa…, баа дак ведь API D3D3 повторяет потроха GL)
    К счастью, пока изучал D3D3 вышел D3D5 ( Immediate Mode такой-же неудобный как в 3-ке, Но есть Retained Mode ..)
    D3D6 — пропустил
    D3D7 — вот это был прорыв, всё так же просто как в OpenGL, но здесь появился D3DX с его библиотекой для работы с текстурами, матрицами и векторами) (Tnt2 Ultra рвёт как тузик грелку ElsaGloriaXXL)
    D3D8 — пропустил, ибо на переправе коней не меняют.
    D3D9 — Ооо да, HSLS… GF FX 5800 Ultra… дааа

    Хотя в защиту OpenGL есть небольшой историй:
    Был проект написанн ещё на OpenGL 1.2, работал долго и счастливо, приносил радость заказчеку… но в оди прекрасный момент ему понадобилась одна фича… и сделать эту фичу без шейдеров ну никак… пара дней и к дремучему проекту прикручен GLSL все довольны… А попробуйте прикрутить например дисплейсмент к D3D5 проекту.

    даа, были времена…
  • +4
    А сто на счет OpenGL 4.x? Это возможность реванша или предсмертные судороги?

    Единый API для графики, звука и пользовательского ввода.
    И так родился DirectX.
    Но в плане графики сначала все-таки был WinG.
  • +1
    ух блин, Вам бы книги писать… так дух захватывает «печальная» история
  • +5
    У Microsoft в то время была ещё большая проблема: Windows.

    Да проблема-то, в сущности, никуда и не делась. :-)
  • +3
    OpenGL будет жить и за его будущее не стоит переживать. Но сегодня появляются игровые движки которые представляют слой абстракций над D3D/OpenGL, что забавно так как сами D3D/OpenGL являлись абстракцияйми над аппаратной частью ускорителей. так что сегодня можно писать на удобных игровых движках которые сами возьмут на себя работу на тем по верх какой библитеки работать. Это сильно облегчает жизнь разработчикам, особенно тем кто разрабатывает инди-игры. Для разработчиков больших игр не сложно и с драйверами напрямую поработать, у них бюджеты позволяют.

    Как бы ни было но производители железа уже давно по факту аппаратно реализуют обе библиотеки. А аппаратное ускорение это самое главное в графической библиотеке.
    • 0
      Библиотеки?

      Ок.
      • +2
        А что это по вашему?
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            А API располагается где, и что из себя представляет?
            Правильно, библиотеку(и). В частности для Windows OpenGL представлена библиотекой opengl32.dll.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Ну, если расшифровать, то OpenGL = Open Graphics Library — открытая графическая библиотека.
                А где эти реализации располагаются? Разве не в библиотеках?
                А где располагаются остальные функции OpenGL, если не секрет?
                • НЛО прилетело и опубликовало эту надпись здесь
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +1
                      И да, я согласен с вами.
                      Спасибо, что помогли разобраться.
                  • +1
                    Хм, возможно я что-то недопонимаю, но только что проверил, что при импорте OpenGL32.dll (только эта библиотека) у меня выдалось следующее:

                    15:46:13.590 Устройство: GeForce 9600M GT/PCI/SSE2
                    15:46:13.590 Версия OpenGL: 3.3.0
                    15:46:13.590 Производитель: NVIDIA Corporation

                    Либо драйвер сам подставляет свою реализацию, либо я не знаю.
                    В идеале, хотелось бы узнать, что на самом деле там происходит.

                    И да, мне это действительно интересно. В статьях часто пишут весьма размыто, так что от человека с объяснениями узнать лучше.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +1
                        Да, интересно они сделали, конечно.
                        Спасибо, что прояснили ситуацию.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.