Неужто dx лучше, нежели openg

opengl используется допустим в doom3. Кроссплотформеность...а с dx ты только на продуктах mc сможешь использовать. ИМХО дело вкуса

Ну... Сравнивать их придеться только частично, за отсутсвием в OpenGL таких вещей как DirectInput, DirectSound и т.д. ДХ это ж не только графика.

>Ну... Сравнивать их придеться только частично, за отсутсвием в OpenGL таких вещей как DirectInput, DirectSound и т.д. ДХ это ж не только графика.

SDL, OpenAL

сравнение некорректно, ибо как тут уже сказали, Dx - это и переферия и звук и 3d и куча всего, а OGL - просто 3D.

Но даже если сравнивать D3D и OGL, то OGL просто рвет d3d, как тузик грелку :)) по куче важных параметров. Например OGL заточен изначально на работу с сетью ( мы можем считать на одной машине, а рендерить на другой). В OGL довольно четкая структура команд и нет ничего лишнего,
при этом очень много низкоуровневых операций с конвеерами и т.д., в D3d напротив - куча лишнего, каждая новая версия ломает API, запутанные и избыточные команды ..но есть уже написанные функции для рутинных действий )загрузк tga например )

ну так это понятно, но ведь все равно это уже не OGL, а сторонние либы

>ну так это понятно, но ведь все равно это уже не OGL, а сторонние либы

что значит сторонние? их нельзя использовать совместно с ogl?

тогда уж давай сравнивать Direct3D с OpenGL

>Ну... Сравнивать их придеться только частично, за отсутсвием в OpenGL таких вещей как DirectInput, DirectSound и т.д. ДХ это ж не только графика.

>SDL, OpenAL

Ага, а DirectSound сравнивать с ALSA?

ЗЫ. Кстати, ALSA сдесб выиграет :) Хотя бы по latency.

>тогда уж давай сравнивать Direct3D с OpenGL вот и я об этом говорю - другое сравнение некорректно. Нет, конечно можно попробовать начать сравнивать Dx с OGL+SDL+OAL+.. но какой смысл ?

Типичный подход MS - всё в один флакон. Выгодно для разработчика, но накладно для пользователя

Проблема в том, что d3d развивается, а opengl стоит на месте. Те же шейдеры когда появились в железе, через opengl реализовывались через различные расширения (разные у каждого производителя), только в 2.0 более менее исправили положение.

По поводу архитектуры. ИМХО стандрат на opengl описывает только API а как оно там реализуется внутри это дело каждого производителя, отсюда например и тормоза opengl под виндами на ATI платах и более быстрая работа по сравнению с d3d у nvidia.

>Проблема в том, что d3d развивается, а opengl стоит на месте.

прекрати курить всякую дрянь

>Те же шейдеры когда появились в железе, через opengl реализовывались через различные расширения

а директЫкс сосал причмокивая.

>По поводу архитектуры. ИМХО стандрат на opengl описывает только API а как оно там реализуется внутри это дело каждого производителя

ты думаешь, что кривойЫкс описывает - как там должно быть внутри железки? Ты сильно ошибаешься

>отсюда например и тормоза opengl под виндами на ATI платах и более быстрая работа по сравнению с d3d у nvidia.

тормоза у ATI исключительно из-за криворукости атишных программеров. Отличий на уровне драйвер<->железка у ogl и dx гораздо меньше, чем на уровне приложение<->апи

давай все таки различать d3d и dx, если уж сравнивать весь dx с opengl то opengl будет "сосать причмокивая" по понятным причинам.

>ты думаешь, что кривойЫкс описывает - как там должно быть внутри железки? Ты сильно ошибаешься

"как оно там реализуется внутри" -> внутри библиотеки, а не железки.

Я сильно подозреваю, что написать драйвер для d3d существенно проще чем полностью заново реализовывать opengl для конкретной карточки, что собственно и подтверждает ситуация с ATI.

Судя по всему, d3d действительно лучше. Да и человек, который в этом хорошо разбирается, вот что сказал:

>создает условия, что бы писать драйвера и игры было удобно. Не винда ессно, микрософт. Несколько лет назад поливна игр выпускалась под opengl, половина под directx. Много ты видел впоследнее время игр под opengl? А ведь по возможностям они примерно равны. Но чем дальше, тем использовать DX проще. >И игры поддерживает, помнится цитал байку о том, что когда вышла 95 винда, цива1 (вроде) на ней падала, поскольку повторно использовала уже удаленную память. Разослать пачт все пользователям в то время было не реально, поэтому в 95 для цивы добавили специальный аллокатор. Дабы любителей популярной в то время игры не испытывали неудобств.

взято из ixbt источников. http://forum.ixbt.com/topic.cgi?id=15:10586-260

там люди не глупые, во всяком случае.

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

>помнится цитал байку о том, что когда вышла 95 винда, цива1 (вроде) на ней падала, поскольку повторно использовала уже удаленную память. Разослать пачт все пользователям в то время было не реально, поэтому в 95 для цивы добавили специальный аллокатор. Дабы любителей популярной в то время игры не испытывали неудобств.

Да-да, человек, сказавший такую ересь, непременно очень знающий. В M$, конечно, идиоты есть, но до такого даже они не додумались бы. Да и класть M$ хотели на сторонних девелоперов. Сколько даже 16-битных прог для win3.x не работало в win95? А тут про досовскую циву1 говорят...

да, к сожалению dx более распространен чем opengl :( и виновата в этом дурацкая политика вендоров - пихать разные расширения только под свою железку. dx мэйнтейнится негрософтом, и все вынуждены плясать под его дудку, что для разработчиков плюс - не нужно думать, какая видяха стоит у пользователя. Но это быдлоразработчики, и к сожалению, их большинство.

>В M$, конечно, идиоты есть, но до такого даже они не додумались бы. Да и класть M$ хотели на сторонних девелоперов. Сколько даже 16-битных прог для win3.x не работало в win95? А тут про досовскую циву1 говорят...

См. http://www.joelonsoftware.com/articles/APIWar.html

Перевод: http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html

Можете помочь ;-)

http://local.joelonsoftware.com/mediawiki/index.php/Russian

Учитывая огромное кол-во популярного досовского и Win16 софта, не работающего под w95, я всё же склонен считать это байкой.

Хотя, возможно подсуетились сами разработчики SimCity в плане $$$, на что M$ и повелась, такое тоже не стоит исключать, тогда эта история и может быть правдивой.

В любом случае, правда это, или нет, и если да, то что двигало M$, мы всё равно не узнаем, так что давайте прекратим пустой флейм на эту тему.

>помнится цитал байку о том, что когда вышла 95 винда, цива1 (вроде) на ней падала, поскольку повторно использовала уже удаленную память. Разослать пачт все пользователям в то время было не реально, поэтому в 95 для цивы добавили специальный аллокатор. Дабы любителей популярной в то время игры не испытывали неудобств.

Эмуляция старых багов присутствует во всех NT-based виндах. Поэтому они должны здохнуть, ибо ловить и тащить за собой паровоз старых глюков - это просто йопнуться надо быть каким умным. Если-б так автомобили делали то все-бы сейчас на квадратных колёсах ездили и с паровыми двигателями.

> Да-да, человек, сказавший такую ересь, непременно очень знающий. В M$, конечно, идиоты есть, но до такого даже они не додумались бы. Да и класть M$ хотели на сторонних девелоперов. Сколько даже 16-битных прог для win3.x не работало в win95? А тут про досовскую циву1 говорят...

Лехко делаются такие костыли. И костыль такой был, по крайней мере я его находил лично. И не только для цивилизации. В 95 винде даже поддержка LFN через костыль была сделана. А ныне, во всех NT based системах которые еще стоят на суппорте в ntdll находится костыль для starforce, штук пяти шароварных протекторов (аспротект в их числе) и еще кое какого говна по мелочи.

Доказательство. Цитата с форума реверсеров. 

А все ли уже посмотрели на файлик ntdll.dll в SP2 к XP 
Не вооруженным ;) глазом видны строчки 

Code:

.aspack 
.pcle 
.sforce 

Функция LdrpCheckNxIncompatibleDllSection... возвращает BOOL Вердикт ставится по имени секции! 

Code:

.text:7C91D51A                 push    8               ; size_t 
.text:7C91D51C                 push    offset a_aspack ; char * 
.text:7C91D521                 push    esi             ; char * 
.text:7C91D522                 call    _strncmp 
.text:7C91D527                 add     esp, 0Ch 
.text:7C91D52A                 test    eax, eax 
.text:7C91D52C                 mov     [ebp+var_8], eax 
.text:7C91D52F                 jz      short loc_7C91D55B 
.text:7C91D531                 push    6               ; size_t 
.text:7C91D533                 push    offset a_pcle   ; char * 
.text:7C91D538                 push    esi             ; char * 
.text:7C91D539                 call    _strncmp 
.text:7C91D53E                 add     esp, 0Ch 
.text:7C91D541                 test    eax, eax 
.text:7C91D543                 mov     [ebp+var_8], eax 
.text:7C91D546                 jz      short loc_7C91D55B 
.text:7C91D548                 push    8               ; size_t 
.text:7C91D54A                 push    offset a_sforce ; char * 
.text:7C91D54F                 push    esi             ; char * 
.text:7C91D550                 call    _strncmp 

Чуть выше можно увидеть 

Code:

.text:7C91D3F3                 call    _LdrpCheckSafeDiscDll@4 ; LdrpCheckSafeDiscDll(x) 

Да, вдогонку. Конкретно этот костыль был вствален из-за появления в SP2 такого чудесного костыля как DEP (Data Execution Protection) который один хрен обходится на раз-два из-за феноменально долбанутого мелкомяхкого ядерного аллокатора, зато несовместимостей за собой потащил что аж костылей в ведро натыкали... А стек все равно прекрасно срывается.

>давай все таки различать d3d и dx, если уж сравнивать весь dx с opengl то opengl будет "сосать причмокивая" по понятным причинам.

ты иногда фантастически тупишь :)

>Я сильно подозреваю, что написать драйвер для d3d существенно проще чем полностью заново реализовывать opengl для конкретной карточки, что собственно и подтверждает ситуация с ATI.

ситуация с ATI подтверждает только то, что кодеры ATI не умеют писать дрова :) Потому что _принципы_ и базовые алгоритмы, по которым работают 3d-акселераторы _одинаковые_ и в случае d3d и ogl. Разница только снаружи (в API. Расшифровать, что такое API или не надо?)

>взято из ixbt источников. http://forum.ixbt.com/topic.cgi?id=15:10586-260

человек, написавший это - не понимает вообще нихера :)

>там люди не глупые, во всяком случае.

4.2. Тот ещё рассадник

Хм.... под Linux DirectX реализуется как SDL + OpenGL ну можно ещё по желанию добавить OpenAL... Чистый OpenGL это только 3D графика... хотя там есть GLU и GLUT созданные для облегчения программирования....

ты идиот или как? это API по твоему напрямую к железу обращается без всякого промежуточного слоя?

в случае с d3d имеем железо<->драйвер<->библиотека<->API<->пользовательские приложения

в случае с opengl слоя "библиотека" нет вот и пишут эту библиотеку сами производители и кто во что горазд со всеми вытекающими. в случае с d3d разработчик пишет только драйвер.

Господа! не надо спорить о каких то там API.

С тех пор как производители видеокарт стали поддерживать opengl, мелкософт переделала d3d API и он версии не знаю с какой (с 8й наверное) совпадает с opengl.

Пример:

void glLoadIdentity(void void)

HRESULT ID3DXMatrixStack::LoadIdentity(VOID)

ой! void один раз конечно же)

void glLoadIdentity(void)

Да и реализация opengl уже есть внутри драйвера видеокарты.

Так что если d3d вдруг быстрее, то процентов на 70 дело в кривых руках писателей приложения...

>ты идиот или как? это API по твоему напрямую к железу обращается без всякого промежуточного слоя?

идиот тут походу только ты

>в случае с opengl слоя "библиотека" нет вот и пишут эту библиотеку сами производители и кто во что горазд со всеми вытекающими. в случае с d3d разработчик пишет только драйвер.

чудила. OpenGL - это и есть "библиотека"

и взаимодействует ogl с железкой через драйвер.

учи матчасть, прежде чем лужи газифицировать.

и кто по твоему эту библиотеку пишет?

>и кто по твоему эту библиотеку пишет?

вендор карточки. Так же как и в случае d3d. Поинтересуйся хоть составом пакета дров видяхи для вантуза. Можешь даже в сырцах примера из ddk порыться - что там нужно писать

>давай все таки различать d3d и dx, если уж сравнивать весь dx с opengl то opengl будет "сосать причмокивая" по понятным причинам.

Да ну? Ты где такую траву взял и почём? И по каким причинам? Монполизма?

>Я сильно подозреваю, что написать драйвер для d3d существенно проще чем полностью заново реализовывать opengl для конкретной карточки, что собственно и подтверждает ситуация с ATI.

Да только d3d по скорости будет гораздо тормознутее. А насчёт проще... Фиг знает.

>Судя по всему, d3d действительно лучше

Дерьмо этот директ хэ. Много занимает и тормозит. Да ещё и одна компания контролирует спецификации. Вывод: директ хэ объективное дерьмо.

>под Linux DirectX реализуется как SDL + OpenGL ну можно ещё по желанию добавить OpenAL...

В смысле как аналог? Или как сам Direct Хэ? =)))))))) А вообще под Линуксом он реализован в виде Cedega.

>в случае с opengl слоя "библиотека" нет

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

>вендор карточки. Так же как и в случае d3d.

вендор карточки пишет d3d9.dll/d3d8.dll и тд? не смеши мои тапочки

>Да только d3d по скорости будет гораздо тормознутее.

как уже я говорил выше смотря с чьей реализацией opengl сравнивать.

John Carmak сказал: "Энжин direct3d хм ... настолько х$$$ов, что требует в 4 раз больше кода и в 2 раза больше времени, чтобы получить половину производительности...".

в каком году он это сказал?

Согласен, это было давно.

Но факт, что он постояно следит за развитием Direct3D, ходит на мелкомягкие саммиты, но использовать продолжает OpenGL.

>вендор карточки пишет d3d9.dll/d3d8.dll и тд? не смеши мои тапочки

мля. Ну ты и чудак. В случае ogl вендор пишет драйвер _и_ реализацию библиотеки. В случае d3d _такой_ же объем кода он вынужден писать, обзывая это драйвером. Хотя в реальности это и драйвер, и кучка dll-ок

>как уже я говорил выше смотря с чьей реализацией opengl сравнивать.

ты сравниваешь плохой код с хорошим кодом, и на основании плохого кода делаешь вывод о том что d3d лучше. Жесть

>в каком году он это сказал?

он и про девятый хренИкс говорил нечто подобное. Погугли - почему d3/q4/etc юзают ogl. А потом удавись - ибо ты задрал выеживаться в темах, в которых нихера не соображаешь

ты сравнивал этот объем кода? давай назови объем кода в строках реализации opengl+драйвер и драйвера для d3d от nvidia.

Вполне возможно и программисты nvidia которые писали драйвер для d3d криворукие и поэтому он работает медленее (но не так фатально как в случае с ATI ибо вся библиотека уже написана микрософтом :) )

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

>один факт быстрой работы opengl у одного вендора тоже ни о чем не говорит.

а то, что опенсорцевые дрова для радеонов быстрее чем проприетарщина от ATI - тоже ни о чем не говорит?

по поводу архитектуры, и что там писать нужно. Драйвера от вендора заменяет часть dx и d3d-библиотек на свои. Можешь посмотреть в dxinfo :)

ни о чем не говорит. есть тесты этих дров на тяжелых играх типа doom3 ?

>ни о чем не говорит. есть тесты этих дров на тяжелых играх типа doom3 ?

тяжелые игры не идут по той простой причине, что карточки, для которых есть спеки - устарели.

и "ни о чем не говорит" - это ты мимо лужи пукнул. То что у опенсорсников хватило мозгов написать дрова лучше, чем у производителя карточки - довольно показательный факт. Для примера - есть закрытые дрова для интелевских карточек и есть открытые. Закрытые быстрее. Из этого можно сделать вывод, что в интел работают хорошие программисты. Собственно, это не новость. А то что в ATI работают криворукие - уже последняя собака знает :)

>тяжелые игры не идут по той простой причине, что карточки, для которых есть спеки - устарели.

я не в курсе на какие карточки есть спеки? случайно не на r9600 и ниже? ты будешь смеяться, но под виндами на r9600 дум3 и производные отлично идут на средних настройках. может дело в кривых драйверах под линух, написанных на коленке васей пупкиным ? :)

Частичные спеки(но достаточные для реализации 3Д) есть только до radeon9250, но учитывая, что у меня dri на такой карточке не завёлся, их тоже не шибко хватает.