unnamed, согласен насчет алгоритмов упустил :)

Кармак ваще молодец, респект ему и уважуха (: Не перевелись еще умные люди на этой планете...

> Я считаю что 3D программист должен знать оба API.
Надо знать не сколько API, а саму суть 3D графики, алгоритмы, архитектуру GPU, что такое шейдера и с чем их едят, ну а остальное - дело нажимное (:

С дровами похоже дело в том, что M$ может достаточно сильно давить на вендоров, чтобы DX-дровы работали
А для OpenGL таких сил практически нет - вот разьве что Кармак перед выходом DooM III очень активно общался с ATI/NVIDIA на эту тему и пробивал чтобы все что ему надо работало
Есть надежда для для ET:Quake Wars он тоже чего-то пробьет :)))

Я считаю что 3D программист должен знать оба API.
Просто неизвестно что будет с каждым через несколько лет. Если 1 из них умрет(в чем я сомневаюсь ни 1 из них не умрет :) ) то ему не надо будет делать переход с 1 на другой. А вот то что драйвера плохие это плохо... если это стандарт графический его обязаны держать все производители.

Хоть Кармак это и признал, но он по-прежнему использует OpenGL. И его игры работают нормально.

Та хоть драйверы, хоть железо - факт остается фактом - работает КРИВО. А тот же функционал на DX - работает отлично. Даже Джон Кармак в своих блогах о DX писал - "Microsoft designed really good API"... Мое мнение - венда со своим иксом - для игр, желе - в первую очередь в производстве (визуализация различных процессов и прочее, благо желе летает на таком железе, которое микрософту и не снилось)

У ATI одна проблема - драйверы
А все остальное - печальное следствие

unnamed, да кстати у ATI иногда с OpenGL бывают большие проблемы...

> А чем расширения снижают скорость ?
Тем, что нужно наколбасить кучу левого кода, один код - для одного вендора, другой - для другого... И не факт, что оно будет корректно работать... Взять тот же фреймбуффер... Код подобный

glBindFramebufferEXT()
glBindRenderbufferEXT()

На nVidia работает, а на ATI (не помню с каким каталистом) вылетает... Оказуеццо, надо строчки местами поменять, или поставить более старые драйвера - тогда все чики-пики... В случае с DX таких проблем нету...

А чем расширения снижают скорость ?
Тем более, что сейчас по-большому счету есть только два производителя GPU - в худшем случае два набора расширений.

"Ясен красен (: Лучше не получить ничего, чем получить тормоза из-за софтверной эмуляции (: "
Не надо передергивать - я имел в виду совсем другое - что возможности D3D заранее заданы M$ и даже если ваше железо и дрова к нему поддерживают новую возмождность (те. геом. шейдеры), то из-под DX9 Вы никак ими не воспользуетесь.

Масчет Mac OS X - полностью согласен - IMHO самая лучшая система сейчас, если бы под нее еще и игрушек побольше (если бы игры длелали на OpenGL проблем с портированием было бы куда как меньше) и по нормальным ценам

> И почему Вы считатет , что гибкость расширений идет в ущерб игре ???
Не игре, а скорости разработки. Качество игры - в первую очередь зависит от моска и прямоты рук разработчегов (:

> ТОлько не надо про проверку расширений - в D3D тоже надо запрашивать возможности и если что-то железо не тянет, Вы этого и не получите.
Ясен красен (: Лучше не получить ничего, чем получить тормоза из-за софтверной эмуляции (:

> Просто даже если железо и тянет в D3D я могу соответствующей возможности и не получить, а вот в OpenGL - запросто.
В OpenGL - тоже запросто можно и не получить нужной возможности (: Например, если стоят старые драйвера (:

> Всякие m_pd3dDevice вызывают просто омерзение - каким надо быть дебилом, чтобы это уродство придумать.
А вот это уже к DirectX не имеет никакого отношения (: Использовать быдло-венгерский идиотизм можно везде... Вот мой стиль: E_ENUMERATION_NAME, CSomeClass::DoSomething(), SStructName, _class_member, struct_member, local_variable... Мне нравится (: Какие будут предьявы? (с) мопЭд (:

> Насчет висты - а почемуя должен для игр ставить висту - только потому что эти твари захотели еще бабла срубить ? Если бы игры делались на OpenGLэтих проблем не было бы. И я мог бы играть в игры под Linux без проблем
Да никто никому ничего не должен (: Мое мнение - венда для игр/десктопа, уникс и его производные - на сервера (: Я 4 года занимался сексом с FreeBSD, Gentoo, ASP, Mandriva, SuSe, MacOSX - и мне в один прекрасный день надоело, решил остаться на венде (: Из всех осей больше всего понравилась MacOSX - уникс с человеческим лицом... Но лень переучивать себя, лень изучать все с нуля (: Лучше вместо этого сделать работу, а в оставшееся время на заработанные деньги пойти погулять (: Хм... Ну вообще каждому свое (:

> А насчет ShaderModel - не надо меня жалеть, это в микрософтовском убожестве есть куча ассемблеров каждый под свою модель.
Это не "куча убожеств", а в первую очередь ограничения видеокарты... Если чип не поддерживает условные переходы, то хоть застрелитесь, не получится сделать ветвление/циклы и т.д.

> В OpenGL есть GLSL. Проверить аппартные ограничения шейдеров из-под OpenGL тоже просто.
Как проверить? Мне вот интересно, причем давно...

> Так что это не нужно - поверьте, за OpenGL стоялим и стоят настоящие профессионалы в графике.
А вот я не говорил, мол "OpenGL делают пионеры и дилетанты" ///:

Вот почему-то в большинстве примеров на OpenGL glGetError практически никогда не проверяется.
Всякие m_pd3dDevice вызывают просто омерзение - каким надо быть дебилом, чтобы это уродство придумать.

Насчет висты - а почемуя должен для игр ставить висту - только потому что эти твари захотели еще бабла срубить ?
Если бы игры делались на OpenGLэтих проблем не было бы. И я мог бы играть в игры под Linux без проблем

И почему Вы считатет , что гибкость расширений идет в ущерб игре ??? ТОлько не надо про проверку расширений - в D3D тоже надо запрашивать возможности и если что-то железо не тянет, Вы этого и не получите.
Просто даже если железо и тянет в D3D я могу соответствующей возможности и не получить, а вот в OpenGL - запросто.

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

И про инстансинг - почитате на форуме opengl.org есть обсуждение этого и рассказ о попытке реализации инстансинга в OpenGL анаогичного D3D/
В кратце - он в таком виде не нужен. Просто OpenGL рабюотает нормально и без него, а вот D3D без него оказывае5тся в жопе почему-то.
Т.е. аккуратное переписывание D3D инстансинга под OpenGL ничего не дало - в OpenGL и так нормально сделан вывод примитивов. Безо всяких ограничений D3D.

Алекс Боресков, кстати насчет расширения формата mp3 тоже можно подумать может попадется формат с 4 каналами, а по вашему пррмеру возможно не загрузится.
unnamed
чистый Direct3D(без D3DX) == OpenGL
единсвенный минус найденный мной в OpenGL это отсутствие геометрического инстансинга, в Direct3D он поддерживается аппаратно. Зато Direct3D имеет ограничение на число примитивов выводмых за 1 вызов
методамиа DrawIndexedPrimitive. А вот OpenGL пофигу сколько примитивов выводится за 1 вызов glDrawElements.
Помню выводил за 1 вызов ландшафт в пол милиона полигонов на достаточно старой карте Radeon 9200 SE, а вот Direct3D начал ругаться на D3DCAPS9.MaxPrimitiveCount. еще в методе DrawIndexedPrimitive больше параметров чем в glDrawElements, и выводить по кускам геометрию сложней т.к. параметров передавать больше. вообще в плане рендеринга геометрии OpenGL намного лучше.
Зато Direct3D более удобно в плане шейдеров.
Все это мое мнение.

> А так, что HRESULT никогда не нужно проверять ?
glGetError и прочие вызовы тоже нужно проверять (=

> А как с наследованием, я могу от D3D-ного объекта унаследовать?
А зачем? (: У меня есть интерфейс к железу. Работает? Работает. Нужно что то еще? В таком случае на его основе педалим свое (:

> Поэтому для геометрических шейдеров нужен именно DX10, DX9 тут не годится.
Как я уже говорил - не такая уж и проблема поставить себе висту для игр (=

> Т.е. эти библиотеки гораздо более гибкие - это IMHO очень важный плюс
+1. Гибкие. В ущерб скорости разработки игры (: Кстати, как в желе обстоят дела с определением ShaderModel? (: (простите за "терминологию ПрямогоИкса") Никак? Мне вас жалко (:

Я не говрил, что "DX - одна из крупнейших ошибок M$ (" - наоборот, для них это выгодная вещь.
DX построен на COM''е, просто есть некоторые способы облегчения работы, когда всякая COMовская гадость прячется.
А так, что HRESULT никогда не нужно проверять ?
А как с наследованием, я могу от D3D-ного объекта унаследовать ?

А про модельки - это M$изобретает у4родский велосипед - вон полно известных форматов моделек и редкоторов к ним - хотя все кваковские форматы. Полно примеров и уроков по их использованию - просто береь готовый код и юзаешь модели.
Причем модели из реальных игр, а не что-то абстрактное, в серьезных ирах не применяемое

И еще один момент - OpenGL, OpenAL - они предоставляеют механизм расширения. Т.е. я могу использовать геометрические шейдеры, если у меня есть соответствующее железо. Из любой версии OpenGL.
И тоже самое относится еще ко многому другому
А в КривомХ этого нет - можно только то, что разрешил M$.
Поэтому для геометрических шейдеров нужен именно DX10, DX9 тут не годится.
Т.е. эти библиотеки гораздо более гибкие - это IMHO очень важный плюс