А оно нам надо?

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

IMHO

Во во. Заняться им явно нечем, лучшеб уж тогда наоборот OpenGL -> Direct3D.

PS: Хотя вообще-то и так те, кто желает своим творениям лучшей участи, чем виндавоз - пишут геймушли либо OGL only, либо OGL as well, живой тому пример - ID Software ;)

2anonymouse

1. ID software - уже не живой пример :(

2. Это и есть Direct3D over OpenGL

2Toster

Не эмулятор, а вроппер. Чувствуешь разницу ??

>Не эмулятор, а вроппер. Чувствуешь разницу ??
боюсь не выйдет. МС как всегда, занимается в основном прыжками в сторону. так что враппер будет наполовину эмулятором. либо будет глючить по черному...

2 anonymous (*) (2002-02-13 18:30:47.0)

Думаю один в один не получится сделать, придется делать прослойку
которая хранит промежуточное представление, так что часть быстродействия потеряется.

2anonymous:

>1. ID software - уже не живой пример :(
Не понял.. он умер чтоль ?!

>2. Это и есть Direct3D over OpenGL
Я говорил о OpenGL over Direct3D. Может особого смысла в этом и нет, но производители 3D-акселераторов в первую очередь все-таки уделяют поддержке новых фич именно для Direct3D. Как ни крути, а виндавоз самая массивная гейм-платформа на сегодняшний день.

Нифига не понял :) как обычно...
А MESA это что? Или, допустим OGL в Qt?

Как физически делается отрисовка - в общем и целом понятно, OGL - это API, а эта хрень зачем? Типа, надстройка?

2asoneofus: это чтобы врякое уродливое дерьмо рисующее через D3D погло рисовать это свое дерьмо на платформе, где D3D нету, но есть OGL, то-бишь реализация дерьма через конфетку, чтобы дерьмо разползалось на другие платформы :(

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

Единственное применение этому враперу найдется только в wine,
более он никому не интересен....

2 McMCC: Почему не интересен. Очень даже интересен тем, кто забился по глупости на OpenGL на Windows а теперь хочет помаленьку перелазить на Direct3D чтобы еще и на XBox игры продавать и фичи последних видеокарт не напрягаясь сильно использовать.

> Почему не интересен. Очень даже интересен тем, кто забился по
> глупости на OpenGL на Windows а теперь хочет помаленьку перелазить
> на Direct3D чтобы еще и на XBox игры продавать и фичи последних
> видеокарт не напрягаясь сильно использовать.
Это как же именно он им поможет?
Кто-хочет вместо OpenGL Direct3D использовать, должен весь engine переписывать. Ибо разные они "по самое некуда".
Хорошо бы смотрелась игра написанная под OGL, работающая в XBox под D3D с линуксовым wrapper'ом 8)

2asoneofus: к X-серверу 3D прикручивать это наверное большой fun можно поиметь :) повторяю, есть OGL, есть поделка D3D, есть тупой софт пользующий поделку, дык вот, странным людям хочется гонять поделки на своих правильных OGL системах, кто-то решил реализовать D3D через OGL, так понятно?

"Очень даже интересен тем, кто забился по глупости на OpenGL на Windows а теперь хочет помаленьку перелазить на Direct3D"
Блюзман, ну ты бы хоть сначала читал, что ли.. Это враппер С д3д НА ОГЛ, а не наоборот... И нужен он тем, кто по дурости забился на д3д и теперь перелазит на ОГЛ.
2 Олл.
И вообще, я бы д3д так уж интенсивно обсирать не стал - на момент своего создания очень даже нужная была винтелам либа. ОГЛ - по сути уже сделанный движок, разработчикам остаеться только им пользоваться. При чем, как-либо чего-нибудь заменить в движке с целью ускорения весьма проблематично. А в иные годы полный ГЛ писюки по просту не тянули. Желающие могут где-нить надыбать старую системку с каким-нибудь STrio3D :-)))) Ну или что-нибудь на Rage 128 :-))))) и посмотреть на фэпээсы в GLQuake (это еще первый, кто не знает..). Потому сначала делали все под Глайд, потом постепенно и с немалой кровью переползли на д3д. Это сейчас, выкидывая на помойку второй гефорс ультра можно пальцы закатывать и д3д обсирать. Да, действительно, для всяких "дезигнеров" и прочей творческой публики это бяка. Слишком глубоко к железу лезть надоть. А для РЕАЛЬНЫХ игр, ктороые должы РАБОТАТЬ на таком железе - очень даже выход. Ну и плюс ко всему - он как ни как от разработчика ОС.
А линуху щас с такими либами - явные траблы. Реально ГЛ, что имееться в линухе - только один: имени НВидиа. Не кидайте в меня помидорами - знаю я, что он и для Радеона и для Матраса имееться. Вот только писать под это РЕАЛЬНУЮ игру ни один псих не будет. Ну разве что какой-нибудь любитель "Tux Race" сваяет :-))))) OpenML еще явно далеко за горами, так что остаеться регулярно ребутиться в винды. И обидно ведь - с DRI линух просто идеальная игровая ОС для писюков...

2LamerOk:

1. мир не заканчивается на писюках

2. мир не сводится к игрушкам

3. то, что в иные годы на писюке небыло железячных ускорителей никак не позволяет говорить о преимуществе API D3D над OGL, более того, куча игрушек писалась на своих движках и что? что это доказывает? имхо только то, что разработчикам пришлось как-то выкручиваться из неудобной позы, и ни как не о том, что этот их движок претендует на универсальный многоплатформенный движок пользующий апаратное 3D-ускорение

> И вообще, я бы д3д так уж интенсивно обсирать не стал
Дык никто и не заставляет ;)
> ОГЛ - по сути уже сделанный движок
Очень грубо и совершенно не точно.
> При чем, как-либо чего-нибудь заменить в движке с целью ускорения весьма проблематично
Кому заменить? Разработчику игр? Так он и D3D ковырять не может. Фирмам, девелоперам видео? Дык флаг в руки и вперед, на написание быстрых драйверов :)
> А в иные годы полный ГЛ писюки по просту не тянули.
Они точно также кашляли и от D3D. Мощности не те были.
> Да, действительно, для всяких "дезигнеров" и прочей творческой публики это бяка. Слишком глубоко к железу лезть надоть
Дезигнеры юзают готовые пакеты, а вот программеров, которые их пишут, это не должно останавливать. Близость железа для программера не минус, а плюс скорее.
> Реально ГЛ, что имееться в линухе - только один: имени НВидиа. Не кидайте в меня помидорами - знаю я, что он и для Радеона и для Матраса имееться. Вот только писать под это РЕАЛЬНУЮ игру ни один псих не будет. Ну разве что какой-нибудь любитель "Tux Race" сваяет :-)))))
Ага. И Кармак очередной свой шедевр портанет. А так конечно - "отстой" полный 8). (шутю я)

P.S.: DirectX 8.1 - весьма достойный API для игр. Однако сколько ж ему расти пришлось :)

>Во во. Заняться им явно нечем, лучшеб уж тогда наоборот OpenGL -> >Direct3D.
Это на хрена же такой гемор-то?
Производительность от этого не увеличится.

D3D по фишкам подобрался близко-близко с Open GL, однако
кое-где еще проигрывает. Говорил недавно с человеком, занимающимся
3d графикой, но навскидку имен функций сейчас назвать не могу (завтра
спрошу - не будет лень, напишу).

Кстати, на xbox, если кто не помнит, есть Open GL (от nvidia, разумеется). А directx там некий directx api, а не directx 8.1

>более убогого 3D чем D3D просто трудно придумать...

Почему?

> не веришь мне --- почитай по мнения людей занимающихся этим... хотя-бы из ID.

Угу, т.е. Кармака. У него свое мнение, у людей из других игродельческих контор свое. Это не истина в последней инстанции.

Я юзал и то и другое. По возможностям они примерно равны.

Мне как-то один чел говорил, что для игр он предпочитает использовать D3D, а для вспомогательных прог типа всяких редакторов - OGL

Да вообще все так называемые 3d игры - это же бред! Да чтобы получить картинку на экране, от которой не тошнит, надо не ускорителями пользоваться, а считать самому(также, чтобы картинка была одинаковая и здравая). А это пока, на PC, к сожалению, по крайней мере десятки секунд) на кадр. Т.о. пока, если хочешь писать трехмерную игру - пользуйся проволочной графикой либо примитивной двумерной. Может, я не прав, может не видел игр с качественной картинкой? Просто Microsoft Train Simulator так уж рекламировали, типа реалистичная, замечательная картинка, но мне кажется, такая дрянь сойдет для Flight симулятора, где рельсы, подвижной состав видны из самолета с тысячи метров, но не в 3 метрах от тебя. Правда MS Train Simulator оказался вообще хреновой игрушкой - я не понял, они вообще когда-нибудь видели, как тормозит грузовой поезд, они представляют себе устройство паровоза хотя бы в общих чертах? Сомневаюсь... Да и скучно ездить по дороге в одиночестве(почти).

>1. мир не заканчивается на писюках
В контексте разговора о д3д - насколько я знаю, заканчиваеться. Или я отстал от жизни и его уже портировали на Альфу, Мак и Амигу ??? :-))))

>2. мир не сводится к игрушкам
В контектсе разговора о д3д... :-))))

>"этот их движок претендует на универсальный многоплатформенный
движок ..."
Я, конечно, придурок, но не до такой же степени, что бы говорить подобное :-))))) Моя мысль заключалась в том, что д3д - это ЗАКОНОМЕРНОЕ явление в истории писюков и хаять его - глупо. Ну или по крайней мере не очень умно :-))))


2 DigiMind

"> ОГЛ - по сути уже сделанный движок
Очень грубо и совершенно не точно."
Да, я это знаю, но при абстрагировании всегда приходится жертвовать конкретикой :-))))

>"Кому заменить? Разработчику игр? Так он и D3D ковырять не может."
А д3д ему и ковырять не надо. ГЛ - это набор функций для ЧЕСТНОГО расчета всей геометрии и последующей отрисовки. И как-либо эту процедуру упростить попросту нельзя. Ну можно конечно пользоваться ГЛ только для отрисовки плоских примитивов - но в этом случае и ГЛ не нужен. А практически все игрушки до 2000 г. занимались в первую очередь тем, как бы поменьше чего считать и как бы более "грязнохакнуть" расчет сцены. И д3д для отрисовки таким образом расчитанных сцен очень даже подходит. Естественно такой подход требует знания того, что д3д может сделать аппаратно за счет ускорителя, а чего лучше сделать в самом движке. Так вот, если ты посмотришь на практически все игрушки выпущенные до 99-2000 гг., то обнаружишь у них у всех одно общее свойство - они сначала определяют, какая железка у тебя стоит и, если стоит не знакомая им, заботливо предупреждают тебя об этом.

>"Дезигнеры юзают готовые пакеты,"
Я говорил не о тех дезигнерах, которые в фотошопе и 3дмаксе работают, а об игровых дизайнерах. К слову - Ромеро именно дизайнер, а не программер :-)))

>"И Кармак очередной свой шедевр портанет."
В том то и дело, что портанет один только Кармак. А остальные по прежнему под д3д писать будут :-(((

2 komar
>"Да чтобы получить картинку на экране, от которой не
тошнит, надо не ускорителями пользоваться, а считать самому"
Конечно !!! И в модемах микропроцессоры не нужны - пускай все цпу выполняет !!! :-)))) Винмодемы - в массы !!! Пень 4 - минимум для работы в инете !!! :-))))) Хочешь посмотреть на результаты таких "считать самому" - посмотри на дельтафорс с ее воксельным движком, на конфигурации, на которых она более или менее нормально идет и на годы выпуска.
>"может не видел игр с качественной картинкой?"
Ну посмотри на NFS:PU, более известный в народе как NFS 5. Меня не тошнило :-)))))) Считаеться образцом красотвы в 3д, хотя я бы не был столь категоричен. :-)))))

2LamerOk: Да, у того NFS скриншоты получше, чем у M$ Train Simulator, ибо M$ опять сам себя обосрал с качеством игры(и не только в графике). Но понимаешь, тут такими мелочами не поможешь. Да, действительно, любое дело, которое жестко realtime, должно быть максимально, лучше - полностью, если возможно, аппаратным, никто не спорит. Но речь о чем: если у тебя на экране, допустим, 1000 различных объектов, каждый содержит по 1000 отдельных поверхностей(деревца, кустики, водоем типа водопад), ну 1М поверхностей на кадр современные крутейшие ускорители потянут, в смысле, нарисуют. Но учитывая, что, во-первых, в результате "поворота головы" игрока эти объекты резко сменятся, что при движении они опять же сменяются полностью за доли секунды, наконец, они еще и движутся, ты должен уже точно на своем CPU выбирать эти объекты из памяти, создавать и отдавать их описание ускорителю, после чего спокойно "отдыхать" и давать замечательные команды типа нарисовать тот-то объект там-то. Но если посчитать, объектов нужно делать порядка 100k в секунду, в них 100M поверхностей. А если ты можешь делать только раз в 5 больше процессорных инструкций в секунду, как тогда с этим справиться? Никак.. Ускоритель, вообще говоря, должен был бы быть совершенно настоящим отдельным компьютером, и грузить не описания объектов как набора точек, поверхностей и их атрибутов, а родной код этого, конечно, дико специализированного процессора. Конечно, компилятор нужно сделать, для этого компьютера. Желательно иметь там устройство хранения, сопоставимое по емкости с жестким диском(в общем-то обычное ОЗУ подойдет, наверное) для этих процедур. Ведь на обычном основном процессоре делается масса других вещей, не менее тяжелых, чем питание ускорителя данными в реальном времени.

А как ты думаешь, почему те, кто делают мультики в 3dsmax, так обреченно ждут часами получения картинок? Ведь взяли бы другую программу попроще, она бы все почти в реальном времени мультик бы на ускорителе вывела, записать это на видак, и потом _теле_зрителей не затошнит, ничего, насладятся! Ан нет...

> Но речь о чем: если у тебя на экране, допустим, 1000
<skip>
Можно нескромный вопрос? Вы когда-нибудь смотрели внутри, как 3D-engine работает? А то что-то из вышеописанного ничего не понятно.
> А как ты думаешь, почему те, кто делают мультики в 3dsmax, так обреченно ждут часами получения картинок?
Потому что эти мультики рендерятся при помощи сильно навороченного ray tracing'а с мощным просчетом освещения и пр.

... Которое в реалтайме пока не делается.

Мой товарищ сделал диплом и потом развил его. В общем есть сервер или целая сеть серверов, ты конектишься к какому-то, скармливаешь описание сцены, сервер при возможности раскидывает работу по другим машинам, и через время получаешь готовую картинку. Идея не нова, но прикольно.

2Havoc. В общем таких вещей уже множество понаписанно. На них под линуксом и фильмы делаются (Hollow Man - первое что приходит на ум).

> В общем есть сервер или целая сеть серверов Для этой широко используемой идеи даже название есть - render farm :)

Не тупи. Врапперы OpenGL поверх ублюдочного D3D давно уже есть. А вот теперь непонятно за каким хером делают наоборот - ублюдочный D3D поверх правильного OpenGL.

Почему DirectX ублюдочен, надеюсь, ты и сам понимаешь.

2DigiMind: >Потому что эти мультики рендерятся при помощи сильно навороченного ray tracing'а с мощным просчетом освещения и пр. Догадался, да! Об этом и речь, значит такое качество нужно в играх, а не то, которое там есть по вынужденной причине. Следовательно, (мое личное мнение) нечего пытаться сделать красивый линолеум, в ущерб более важным вещам в игре, т.е. обсчету "физики", сетевому взаимодействию, наконец, той же графике, в части борьбы с "искажениями пространства", которые имеют место в упомянутой M$-игре и почти всех ее конкурентах. А чего там "ничего не понятно", можно поподробнее? А то я не 3d engine'ами занимаюсь, только какой-нибудь из них уж точно не так устроен, нету пока такой технологии. Это было, извините, просто мое тупое рассуждение: если столько-то кусков поверхностей изменилось(изменило расположение в пространстве), "прикладной" программист должен о каждом сообщить 3d engine, а тот - ускорителю(если ты это понимаешь под 3d engine), и процесс этот идет не в одну стадию, благодаря "абстракции и эмуляции", и явно не за 1 такт процессора для одного куска поверхности. Извиняюсь заранее за такое выражение "кусок поверхности", в разных местах все равно разная терминология. А если у кого-то все в мире неподвижно - ну это его проблемы (в смысле, разработчика игры). А по поводу того, что пресловутую "абстракцию" проще было бы сделать через специфический язык программирования, не понял? Это к тому, что в реальности пусть эти крутые ускорители помогли бы в наименее интеллектуальных частях программы, но с возможностью, чтобы это писал тот же разработчик, а не только производители железа, как есть сейчас. Просто кажется, что большинство людей все равно недоиспользуют мощность ускорителей, обидно, а тем кто использует, хуже не будет.

2LamerOK: ну я тоже могу переформулировать все твои сентенции и _ни одна_ из них не в пользу D3D, хотя я конечно говорил от своего опыта(не игры, визуализация моделирования в околонаучных областях)

ну все, можно напиться, антихрист со мной согласился :)

пойду напьюсь под Metal Storm/Face the Slayer '83 :)

2 komar
"у того NFS скриншоты получше" А посмотреть на саму игру, а не на ее скриншоты не пробовали ????

"Но учитывая, что, во-первых, в результате "поворота головы" игрока эти объекты резко сменятся.." Все нынешние 3д движки ПОЛНОСТЬЮ ОТРИСОВЫВАЮТ КАЖДЫЙ КАДР, вне зависимости от того крутит ли игрок головой/мышью :-))) Максимум, на что это влияет - подгрузка новых текстур.
"Но если посчитать, объектов нужно делать порядка 100k в секунду, в них 100M поверхностей..." Вы знаете современные игры, где до 100 _К_ объектов !!!????? Да еще и с 1000 __М__ полигонов ????? Я - нет :-))))) В современных игрушках даже на самых детализованных объектах обычно по две-три сотни полигонов. Я уж не говорю про 100К объектов :-))))
"Ускоритель, вообще говоря, должен был бы быть совершенно настоящим отдельным компьютером..." Вообщето, так оно и есть. Донельзя специализированный самостоятельный компьютер. Равно как, скажем, и модем.
"грузить не описания объектов как набора точек, поверхностей и их атрибутов, а родной код этого, конечно, дико специализированного процессора"
С выходом 2-ого гефорса шейдеры к вашим услугам. Они же обещались и в Радеонах (есть ли - не знаю).
"Желательно иметь там устройство хранения, сопоставимое по емкости с жестким диском(в общем-то обычное ОЗУ подойдет, наверное).." 32 или 64 метров мало ????!!!! Это почти столько же сколько системной памяти на самих машинах...
"Ведь на обычном основном процессоре делается масса других вещей, не менее тяжелых, чем питание ускорителя данными в реальном времени."
Должен вас огорчить :-)))) Питание данных ускорителем практически не нагружает цпу. Сейчас, как правило, процы только расчитывают геометрию и, иногда, освещенность. А основная муть по рендерингу уже как лет 5 выполняеться видюшками...
"А как ты думаешь, почему те, кто делают мультики в 3dsmax, так обреченно ждут часами получения картинок? Ведь взяли бы другую программу попроще, она бы все почти в реальном времени мультик бы на ускорителе вывела, записать это на видак, и потом _теле_зрителей не затошнит, ничего, насладятся!"
Гхм... Простите, это какой-то ваш личный опыт или досужние домыслы ???? Для ТЕЛЕзрителей, по крайней мере тех, что смотрит через пал подойдет практически любое дерьмо. В качестве примера можно посмотреть на РТР и московские кабельные каналы... Для HDTV и тому подобных фишек требуеться качество получше, но не так что бы уж сильно.. РЕАЛЬНО качество расчетов нужно только для кинотеатров и дивиди. И тогда все делают не на каких-то 3дстудио, а на SGI все считают... Ну или вот линушные кластеры используют.. :-)))))

"Догадался, да! Об этом и речь, значит такое качество нужно в играх, а не то, которое там есть по вынужденной причине. Следовательно, (мое личное мнение) нечего пытаться сделать красивый линолеум,.." Так я не понял - оно (качество) нужно или его не надо пытаться сделать ???? Как бы что-нибудь одно... :-)))))))

"А то я не 3d engine'ами занимаюсь..."
Это заметно :-))))))))))

"а тот - ускорителю(если ты это понимаешь под 3d engine)" Нет, боюсь (правда не сильно :-))) ), что DigiMind понимает под 3д движком то же, что понимают под ним и все остальные - программу расчета и отрисовки проэкции на плоскость объектов в 3-ех мерном пространстве. Кроме того все движки осуществляют также расчет взаимодействия этих объектов между собой, обрабатывают ввод пользователя и т.п., но это уже не суть, просто одна только отрисовка объектов мало кого интересует :-)))))

"в разных местах все равно разная терминология." Терминология везде одна и та же, если вы ее не знаете - это еще не значит, что она везде разная или ее не существует :-)))))

"пусть эти крутые ускорители помогли бы в наименее интеллектуальных частях программы" Я еще не слышал о том, что бы с их помощью расчитывали pathfind'инг и т.п. :-))))))

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

Ув. тов. Комар :-)))) По моему вы не очень хорошо себе представляете, что такое собственно 3д движки и чего они делают на писюках.
Возможно мое мнение ошибочно и вне всякого сомнения глубоко субъективно, но мне кажеться что вам, для осмысленного продолжения дискуссии следует немного более детально ознакомиться с предметом обсуждения. А ваша идея отказаться от графики вообще в пользу физики и иных вещей не кажеться мне конструктивной :-)))))

2 Антихрист
"непонятно за каким хером делают наоборот - ублюдочный D3D поверх правильного OpenGL." С тем, что бы по возможности облегчить перенос уже существующих под д3д приложений на платформы с поддержкой ГЛ (следует читать так - винодвые игрушки портировать под линух) и помочь разработчикам вновь создаваемого софта переехать с д3д на ГЛ. Последнее на самом деле более важно, потому как практически вся индустрия 3д игрушек на писи завязана на косом игреке. А это, вопреки распространенному мнению, очень консервативная отрасль.

2 Аноним
"_ни одна_ из них не в пользу D3D" Я и не пытался высказаться (упаси боже) _в пользу_ д3д. Я хоть и олигофрен, но все же нахожусь на стационарном лечении :-)))) Я лишь пытался объяснить отдельным индивидуумам причины возниконовения и существования д3д на писи. Возможно, что зря :-)))))) И вот уж никак не думал, что это вызовет такую ммм... активную реакцию :-))))

>Ускоритель, вообще говоря, должен был бы быть совершенно настоящим отдельным компьютером, и грузить не описания объектов как набора точек, поверхностей и их атрибутов, а родной код этого, конечно, дико специализированного процессора.Конечно, компилятор нужно сделать, для этого компьютера.
В OpenGL1.0+ это называется "Display List" см. glNewList(list,GL_COMPILE);
шейдеры- это скорее "инлайн ассемблер" для этого "компилятора" (у RadeOn8500 есть)
>А как ты думаешь, почему те, кто делают мультики в 3dsmax, так обреченно ждут часами получения картинок?
почему обреченно? при желании они вполне могут упростить модели и текстуры оказавшиеся на горизонте,
заменить медленный/универсальный рай-трасинг на кучу быстрых алгоритмов отдельно для каждого обьекта
и, через несколько дней, получить ту-же картинку почти в реалтайм

>"шейдеры- это скорее "инлайн ассемблер" для этого "компилятора""
Ну я надеюсь не дожить до тех времен, когда в видеоускорители будут встраивать интерпретаторы :-)))))) И для какого такого "компилятора" ???? Наверное имелось в виду "для процессора" ??? :-))))) Или вы полагаете, что программа переводящая ассемблерный код в двоичный не являеться компилятором и использована самостоятельно быть не может ???? :-))))))))

И по поводу ГЛ - нельзя ли по подробнее, чего он собственно компилит при использовании "Display List" ??? Инструкции для видеоускорителя ???

2LamerOk: ""_ни одна_ из них не в пользу D3D" Я и не пытался высказаться (упаси боже) _в пользу_ д3д."

ну так тогда если с этим никто не спорит, то из-за чего весь сыр-бор? :) хотя по мне так и для своей цели/истории возникновения D3D убожество. ну да хрен с ним раз все согласны :)

>Ну я надеюсь не дожить до тех времен, когда в видеоускорители будут встраивать интерпретаторы :-))))))
по моим представлениям, OpenGL работает примерно в такой последовательности:
cadr()
{
to_da_se();
glBindTexture(GL_TEXTURE_2D, textureIdentifArray0[6]);
glBegin(GL_TRIANGLES);
glTexCoord2f(0,0); glVertex3i(255,-255,44);
glTexCoord2f(0,1); glVertex3i(0,-255,66);
glTexCoord2f(1,0); glVertex3i(255, 0,82);
glEnd();

glPushMatrix();
glTranslatef(x1,y1,0);
glBindTexture(GL_TEXTURE_2D, textureIdentifArray0[13]);
glEnable(GL_BLEND);
glColor4f(r,g,b,a);
glBegin(GL_TRIANGLE_STRIP);
glTexCoord2f(0,0); glVertex3i(255, -255,456);
glTexCoord2f(0,1); glVertex3i(0,-255,45);
glTexCoord2f(1,0); glVertex3i(255, 0,14);
glTexCoord2f(1,1); glVertex3i(0, 0,55);
glEnd();
glPopMatrix();

glFlush(); /*CPU информирует GPU об окончании описания сцены,
GPU, скорее всего, рисует еще только первый треугольник,
остальные команды записаны в памяти ускорителя в виде какого-нибудь байткода*/

AI();
Phisic();
Interfas();
etc();

glFinish();//если к этому моменту GPU еще не достроил сцену, выполнение программы CPU приостанавливается
}
если я не прав- кинте докой(а то все описывают результат, а не способ его получения)

>И по поводу ГЛ - нельзя ли по подробнее, чего он собственно компилит при использовании "Display List" ??? Инструкции для видеоускорителя ???
glNewList(listID,GL_COMPILE);
куча glКомманд
glEndList();
после чего можно выполнить эту "кучу glКомманд", уже хранящихся в памяти ускорителя, с помощью glCallList(listID);


P.S.
функция создания вертиксных шэйдеров у гефорца получает аргумент вида
const unsigned char Shader1[]=
{"!!VSP1.0"
"MOV R0.xyz,c[0];"
"MOV R1.xyz,c[1];"
"MUL R1,R0,C[16].x;"
//(...)
"END"
};

у RadeOn8500 выглядит все-таки привычнее....

>если я не прав- кинте докой
Да все вроде так, только вот glFinish() в игрушках на писи не используют - очень накладно выходит, да и обработку графики встраивают паралельно с остальными расчетами - получаеться более эффективно.

А гл лист по сути просто функция из ГЛ вызовов ???

>остальные команды записаны в памяти ускорителя в виде какого-нибудь байткода
В том то и прикол, что у писюшных видюшек никакого байткода до шейдеров не было :-)))))) Все через видеодрайвер.

>у RadeOn8500 выглядит все-таки привычнее....
Шейдеры же должны быть единообразными ???? Т.е. "кроссплатформенно-аппаратно-ускорительно-фирмапроизводительно-независимыми " ???

>"Но учитывая, что, во-первых, в результате "поворота головы" игрока эти объекты резко сменятся.." Все нынешние 3д движки >ПОЛНОСТЬЮ ОТРИСОВЫВАЮТ КАЖДЫЙ КАДР, вне зависимости от того крутит ли игрок головой/мышью :-))) Максимум, на что это влияет - >подгрузка новых текстур. Мда-а, интересно, как это можно полностью отрисовать, не имея в руках ни текстур, ни собственно места в памяти для двумерной проекции? Ну конечно на сферические координаты спроецировать теоретически можно, но обычно не нужно. А про поворот головы, если непонятно, объясняю подробнее. 1. Поезд едет с такой скоростью, что объекты сменять приходится полностью за несколько секунд(и автомобиль тем более). 2. В данной ситуации поворот головы роли не сыграет, но, согласись, если игра несколько другая, и сбоку, и сверху, и снизу, и сзади копошится огромное количество чисто декоративных забавных тварей, то не надо тебе в программе вообще касаться их движений, тем более - сообщать обо всем устройству, если их пока не видно, когда башка повернется, все равно далеко уползут.

>Вы знаете современные игры, где до >100 _К_ объектов !!!????? Да еще и с 1000 __М__ полигонов ????? Я - нет :-))))) В современных игрушках даже на самых >детализованных объектах обычно по две-три сотни полигонов. Я уж не говорю про 100К объектов :-)))) >Должен вас огорчить :-)))) Питание данных ускорителем практически не нагружает цпу. Сейчас, как правило, процы только >расчитывают геометрию и, иногда, освещенность. А основная муть по рендерингу уже как лет 5 выполняеться видюшками... Да-да, именно так. Пока я тоже не видел таких игр, и, как Вы конечно понимаете, именно поэтому ЦПУ и не нагружен питанием ускорителя. Кстати, я думал, что просто подразумевается, что ускоритель надо питать данными геометрии, а не готовым растровым изображением, как Вам почему-то показалось по моей фразе (ибо сказано было именно ускоритель, а не видеокарта).

Ну что же Вы все не поймете основную мысль: ну не обеспечивают пока ускорители требуемого качества не только для кино, но и для некоторых игр, по крайней мере тогда, когда немногочисленный коллектив авторов забивает на все ради "трехмерной графики", а она тогда уже и ни к чему, если основа игры куцая. Ибо результат, которого дотигают при двух сотнях полигонов на объект, не стоит того. Вот и все, я не призываю отказываться от графики совсем, играть в текстовом режиме как-то не в кайф.

>"а тот - ускорителю(если ты это понимаешь под 3d engine)" Нет, боюсь (правда не сильно :-))) ), что DigiMind понимает под 3д >движком то же, что понимают под ним и все остальные - программу расчета и отрисовки проэкции на плоскость объектов в 3-ех мерном >пространстве. Кроме того все движки осуществляют также расчет взаимодействия этих объектов между собой, обрабатывают ввод >пользователя и т.п., но это уже не суть, просто одна только отрисовка объектов мало кого интересует :-))))) Почему же "нет", это как раз "да", ибо я понимаю под ним именно эту программу. Правда, я как-то думал, что уж проекцию и расчет освещенности конкретных поверхностей делает аппаратная часть. Нестыковка только в том, что я просто не называю 3d engine части программы, не имеющие отношения к собственно графике. Кстати, многие фирмы делают коммерческие в т.ч. бесплатные на опред. условиях, продукты, называя их именно 3d engine, и эти изделия, вообще-то, ни хрена ничего не делают кроме графики, это как раз для игр, когда программисту не хочется лишнего напрягаться. А что касается остальной части, т.е. не графики в игре, то ей-то я занимаюсь, не надо тут своих предположений. Просто у кого-то все ds=v+a/2*dt*dt, а эф равно ка икс, у кого- эмуляция релейной схемы, просто все это не графика. И эту часть уместнее называть просто "компьютерная игра", пусть мы все и живем в трехмерном пространстве.

>"в разных местах все равно разная терминология." Терминология везде одна и та же, если вы ее не знаете - это еще не значит, что >она везде разная или ее не существует :-))))) Смотри не порви рот! :-(00) Кое-кто предпочитает называть треугольники полигонами, хотя у них именно 3 угла. Другие тебе назовут треугольником многоугольник(по привычке, наверное). Потом, для криволинейных поверхностей просто нечего перечислять все методы их построения. И так далее. Ну не может быть устоявшейся терминологии в развивающейся области.

>Для ТЕЛЕзрителей, по крайней мере тех, что смотрит через >пал подойдет практически любое дерьмо. Ну этот линолеум я и в телевизере узнаю! Если только специально помех добавить, авось сойдет.

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

2Anonymous (*) (2002-02-16 06:56:25.0): >>Ускоритель, вообще говоря, должен был бы быть совершенно настоящим отдельным компьютером, и грузить не описания объектов как >набора точек, поверхностей и их атрибутов, а родной код этого, конечно, дико специализированного процессора.Конечно, компилятор >нужно сделать, для этого компьютера. >В OpenGL1.0+ это называется "Display List" см. glNewList(list,GL_COMPILE); Нет, не это. Или подскажешь, как передать параметры списку? Типа "угол открытия пасти бегемота", чтобы потом нарисовать всего бегемота за 1 раз. Сейчас, я знаю, скажут, "держи карман".

2Anonymous (*) (2002-02-17 06:43:02.0): const unsigned char Shader1[]= {"!!VSP1.0" "MOV R0.xyz,c[0];" "MOV R1.xyz,c[1];" "MUL R1,R0,C[16].x;" //(...) "END" }; Все-таки одно из трех, или Вы забыли * после char, или запятые между строками, или убрать {}, или уже четвертое? Это вообще язык C, что ли?:). Вообще, что за дикость, в реалтайме лишним разбором синтаксиса заниматься? Что, попроще было нельзя?

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

"Мда-а, интересно, как это можно полностью отрисовать, не имея в руках ни текстур, ни собственно места в памяти для двумерной проекции?"
А почему не имея ???

"на сферические координаты спроецировать теоретически можно" Причем здесь сферические координаты ?? Или вы прямо на голову собираетесь изображение проецировать ???? :-)))))

"А про поворот головы, если непонятно, объясняю подробнее"
Я так понял из вашей фразы: "в результате "поворота головы" игрока эти объекты резко сменятся, что при движении они опять же сменяются полностью за доли секунды, наконец, они еще и движутся", что вы полагаете, будто изменение точки зрения (игрока) или изменение объектов (т.е. их "движение") приводит к новому перерасчету изображения. Так вот - это не так. Все изображение перерасчитываеться с нуля по новой для каждого кадра. Т.е. расчитываем кадр и выводим на экран. Потом снова расчитываем кадр и снова выводим на экран. И так далее...

"и сбоку, и сверху, и снизу, и сзади копошится огромное количество
чисто декоративных забавных тварей, то не надо тебе в программе вообще касаться их движений ... если их пока не видно"
А вы полагаете что их (при расчете/отрисовке кадра) кто-то касаеться ???

"Пока я тоже не видел таких игр, и, как Вы конечно понимаете,
именно поэтому ЦПУ и не нагружен питанием ускорителя."
Нет, не по этому :-)))) Он не нагружен, потому что уже давным давно используеться агп шина. Процессор просто информирует видеочипсет о том, откуда и сколько данных ему надо збрать. Все данные ускоритель забирает САМ, так что действуют только видеоускоритель, чипсет и память. А если у чипсета еще и самостоятельный контролер памяти для обработки запросов от видео, то процессор вообще ничего не заметит.

"Кстати, я думал, что просто подразумевается, что ускоритель надо питать данными геометрии"
А зачем они ему ??? Расчеты геометрии появились только у ГеФорса (ну и сейчас еще у некоторых видюшек), да и то этой возможностью не пользуеться ни один движок и ни одна игрушка. Ну разве что демки от НВидиа :-)))))

"я думал, что просто подразумевается, что ускоритель надо питать данными геометрии, а не готовым растровым изображением"
Ну вот эта фраза меня окончательно и убедила в том, что вы вообще ничего в этом вопросе не понимаете.

"ибо сказано было именно ускоритель, а не видеокарта)."
А между ними есть разница В КОНТЕКСТЕ НАШЕГО РАЗГОВОРА ??? :-))))))

"Ну что же Вы все не поймете основную мысль:"
Вы знаете, я до сих пор не могу ее понять :-))))

"ну не обеспечивают пока ускорители требуемого качества"
Еще в прошлый раз хотел спросить - КЕМ требуемого качества ??? Меня так вполне устраивает в подовляющем большинстве случаев :-)))

" не только для кино, но и для некоторых игр, по крайней мере тогда, когда немногочисленный коллектив авторов забивает на все ради "трехмерной графики","
То есть, если авторы хотят сделать сильную 3д часть, то ускорители не обеспечивают ??? А если забивают - то все ок ???

" а она тогда уже и ни к чему, если основа игры куцая."
Куцая - если хотят сделать хорошую 3д часть, и не куцая если на 3д забивают ???? Не знаю, кто как - но я по прежнему не могу вас понять. Не судьба, видно... :-))))

"играть в текстовом режиме как-то не в кайф."
Кому как. Я в свое время не мало посидел в MUD'ах и думаю еще в скорости вновь в них залезу :-)))))

"Правда, я как-то думал, что уж проекцию и расчет освещенности конкретных поверхностей делает аппаратная часть" Ну вот это и есть одно из ваших основных заблуждений. Хотя уже довольно давно в большинстве ускорителей есть и расчет геометрии и освещения, как правило они там не столь хороши, как хотелось бы разработчикам (да и к тому же хочеться охватить и пользователей более старых ускорителей).

" просто не называю 3d engine части программы, не имеющие отношения к собственно графике."
Я в данном треде то же, но из соображений политкорректности все таки добавил и эту часть, так как вопреки вашему мнению ("эти изделия, вообще-то, ни хрена ничего не делают кроме графики") подавляющая часть 3д движков все таки еще чего-то делает. Ну да это не суть :-))

"не графики в игре, то ей-то я занимаюсь, не надо тут своих предположений"
А вам их кто-то предлагает ??? В любом случае спасибо, учтем на будущее... :-))))))

"Кое-кто предпочитает называть треугольники полигонами, хотя у них именно 3 угла."
В контексте разговоров о 3д полигонами называют именно треугольники, так просто исторически сложилось.

"Другие тебе назовут треугольником многоугольник(по привычке, наверное)."
Ну я с такими индивидумами не сталкивался. Видимо, вам не так повезло, как мне... :-))))))

"Ну не может быть устоявшейся терминологии в развивающейся области."
Для терминологии важно не развиваеться ли область, а насколько давно она существует. 3д существует достаточно давно, что бы не испытывать проблем с терминами.

"Это вообще язык C, что ли?:)"
Это именно язык С. Ну может еще плюсы или другое надмножество. И, как видно, вы его не очень хорошо знаете... :-))))

"Вообще, что за дикость, в реалтайме лишним разбором синтаксиса заниматься?"
Скорее всего все шейдеры будут скомпилированны ДО начала работы оснвного цикла программы, если вообще не компилятором, так что ничего ужасного лично я тут не вижу :-)))))

2LamerOk
>В том то и прикол, что у писюшных видюшек никакого байткода до шейдеров не было :-)))))) Все через видеодрайвер.
Карточки класса до Voodoo3 линию не могли провести без обращения к CPU,
ни к чему, кроме непрерывного переключения контекста, попытка заставить такую карту
работать паралельно с CPU привести не могла, и был для них лучшим API простой как 2 копейки glide и OpenGL в виде врапера
и тогда действительно:
>Да все вроде так, только вот glFinish() в игрушках на писи не используют - очень накладно выходит, да и обработку графики встраивают паралельно с остальными расчетами- получаеться более эффективно.
только было это очень давно- больше года назад, а уже на Voodoo5 3dfx обещала с glide завязать и выпустить нормальную OpenGL...

>А гл лист по сути просто функция из ГЛ вызовов ???
с точки зрения результата/стандарта- да,
а нужны они потому, что скомпилиные в в этот лист gl команды могут быть частично предвыполнены, переведены в удобную для исполнения 3d картой форму (не обязательно байткод, кстати) и загружены в набортную память акселератора
>Шейдеры же должны быть единообразными ???? Т.е. "кроссплатформенно-аппаратно-ускорительно-фирмапроизводительно-независимыми " ???
ну должны, только Nvidia так заточила свои шейдеры под GF3, что даже GF4MX уже оказался с ними не совместим(вертексных на нем не будет, насколько я знаю), стандартом скорее всего станет вариант от ATI

2komar
>Или подскажешь, как передать параметры списку? Типа "угол открытия пасти бегемота", чтобы потом нарисовать всего бегемота за 1 раз. Сейчас, я знаю, скажут, "держи карман".
извратится через glPushMatrix(); например, можно...
только у меня сложилось впечатление, что ты перечитался рекламы Nvidia(особенно периода борьбы с 3dfx)
и всерьез думаешь, что GPU- это такой CPU, только в 50 раз быстрее и в 4 раза дешевле...А програмировать не дают:)..

>Вообще, что за дикость, в реалтайме лишним разбором синтаксиса заниматься? Что, попроще было нельзя?
ну, это 2Nvidia, у ATI:

xform = glGenVertexShadersEXT(26);
glBindVertexShaderEXT( xform+0);
glBeginVertexShaderEXT();
{
GLuint eyeVertex;
eyeVertex = glGenSymbolsEXT( GL_VECTOR_EXT, GL_LOCAL_EXT, GL_FULL_RANGE_EXT, 1);
glShaderOp2EXT( GL_OP_MULTIPLY_MATRIX_EXT, eyeVertex, modelview, vertex );
glShaderOp2EXT( GL_OP_MULTIPLY_MATRIX_EXT, GL_OUTPUT_VERTEX_EXT, projection, eyeVertex );
// (...)
glShaderOp1EXT( GL_OP_MOV_EXT, GL_OUTPUT_COLOR0_EXT, color);
}
glEndVertexShaderEXT();
впрочем, кода здесь выйдет даже больше, а менять описанее шейдеров в реалтайме действительно нужно редко

2LamerOk
>Расчеты геометрии появились только у ГеФорса (ну и сейчас еще у некоторых видюшек),
на игровом рынке- да
> да и то этой возможностью не пользуеться ни один движок и ни одна игрушка. Ну разве что демки от НВидиа :-)))))
используя OpenGL обойти стандартные, написанные производителем -читай аппаратные, функции довольно сложно, в играх этого никто не делает,
в DX8 по моему, то-же

>Хотя уже довольно давно в большинстве ускорителей есть и расчет геометрии и освещения, как правило они там не столь хороши, как хотелось бы разработчикам (да и к тому же хочеться охватить и пользователей более старых ускорителей).
а больше/лучше всем/всегда хочется

2komar
>но, согласись, если игра несколько другая, и сбоку, и сверху, и снизу, и сзади копошится
>огромное количество чисто декоративных забавных тварей, то не надо тебе в программе вообще касаться их движений, тем более - сообщать обо всем устройству, если их пока
>не видно, когда башка повернется, все равно далеко уползут.
куда это они уползут, если "не надо тебе в программе вообще касаться их движений":)
а ваобще, вопросу "Как, не расчитывая координат определить, где находится обьект(в кадре или нет)?" посвящена масса литературы...

>Расчеты геометрии ... на игровом рынке- да
Ну мы вообще то говорим о 3д в контексте косого игрека, и следовательно писюшек. Я что-то слышал о том, что выпускаются профессиональные ускорители для писи, но не слышал, что бы они где-то использовались :-)))))) А про SGI, звездные войны и терминатора я знаю :-))))))))))

> "стандартные, написанные производителем -читай аппаратные, функции"
Я бы читал более внимательно :-))))) Написаные производителем - вовсе не значит аппаратные :-))))) Что железка поддерживает и поддерживает хорошо - сделают аппаратно, а остальную байду будет по прежнему выполнять проц. Просто не в программе юзера, а в дровах от производителя. :-))))))

> "в играх этого никто не делает, в DX8 по моему, то-же"
До недавнего времени в играх ВООБЩЕ расчет освещености не делался - использовались всевозможноые карты освещенности. Эта мода последнего времени. Ну и опять таки не знаю как в новых играх, а еще год-два назад никто расчеты освещенности на железо (т.е. видюшку) не клал, использовали какой-нибудь элегантный dirty-hack, коих для этой цели было множество...

>Это именно язык С. Ну может еще плюсы или другое надмножество. И, как видно, вы его не очень хорошо знаете... :-)))) Пардон, наврал-с. Первое со вторым, конечно, только вместе( вместо "или" читай "и"), про третий(бывш. четвертый) вариант вообще чисто теоретически.