api, скорость, производительность, компилер ?

Значит стоит задача писать маленькие, быстрые, и как можно на большем колве виндов/видях/процов работоспособные win32 бинари.В освновном 2d графика (3д немного тоже,но основное 2д - быстрый скролинг битмапов, fade it/out, работа с шрифтами, быстрый блитинг,alpha. Текстуры не обязательно, но предпочтительно) +звук (xm/mod/mo3/mp3). Без всяких дополнительных dll'ок (кроме тех конечно которые в виндах есть практически у всех (opengl,d3d8,winmm,etc). Какая либо переносимость на какието другие платформы не требуется (в смысле жестко win32).



Под рукой есть 2 тестовых тачки:



a. p3 2.3mhz/gf-fx5700 128mb/512ram

b. celeron 750mhz/s3 savageix 8mb/128ram



На обеих winxp/dx8/opengl.



Попробовал с ходу примеры nehe (opengl). На (a) тормоза просто нереальные.На(b)нормально.Но для текстурированного вращения куба (которые можно в целом и на старых 486тых с 2 метровыми видяхами делать вполне) это уж слишком жирно. Ради интереса посмотрел внутрь opengl.dll, она под ddraw.dll.Т.е.уже как я понимаю,говорить о том,что быстрее opengl или directx смысла нет, directx явно будет быстрее (?)В подтверждение этому посмотрел аналогичные примеры под dx8.И на (a) и на (b) все как нужно. Т.е. более быстрое api далеко не opengl, а directx. Поправте если я в чем то ошибаюсь.



Теперь, что касаемого самого dx8.Что лучше: использовать ddraw (как в старых директах) или уже не парится и пользовать d3d (в нем вроде как уже ddraw функции тоже включены теперь ?) Обязательно подразумевается, что выбор не должен уменьшить скорости/совместимости, а наоборот повысить (со старыми версиями директа, виндов и древними видяхами/процами).



Возможно стоит использовать opengl и dx8 одновременно ? В смысле для того и того где надо скорость и прочее - dx, а вот для этого и этого, где нужно чтото там сделать, чего не может быстро и хорошо сделать dx, то opengl ? А может вообще и dx и opengl в сад, а юзать какую-нибудь хитро-сныканную dll которая совсем самый низ и все что надо в ней есть ? (главный момент чтобы работало везде).



О звуке ответ в принципе понятен, это либо minifmod, либо самому под winmm писать ? Но может есть еще какой способ увелиивающий скорость, но не теряющий совместимости ?



Да, до кучи вопрос отцам вышедшим с 286тых и адлибов с коваксами. Помните такие форматы как rol, amd, rad (rad player которые все юзали в реал моде) ? Есть какая либо возможность сейчас их играть именно под виндами ? В смысле что если я делаю exe 16 битный старый с rad player'ом, то оно эмулится и даже музыка играет (правда только на одной винде, со второй отсос). Может есть какие конверторы уже в mod/xm тотже fm файликов ?



И в заключении так сказать Что касаемо скорости кода и компилятора. Само собой, что при моих запросах либо асм (fasm/masm?), либо может быть watcom с самодельным стабом ? О vc даже не спрашиваю (кстати может где есть кемто

урезанная версия, чтобы были чисто бинари нужные аля линкера,компилера, либы и инклуды?) borland тоже не ахти как с размером бинарника будет я думаю.. Я конечно не говорю о том, что потом все пожать upx'ом и тд, я про изначальный размер бинаря.



В общем вопрос более теоретический чем конкретный.Хотелось бы просто обсудить все это

 

Попробовал с ходу примеры nehe (opengl). На (a) тормоза просто нереальные.На(b)нормально.

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



Ради интереса посмотрел внутрь opengl.dll, она под ddraw.dll.

=))))))0 Вот мне всегда интересен был смысл этих фраз. Объясни пожалуйста. Нашел запись в таблице импорта и сделал заключение, так что ли?



Т.е.уже как я понимаю,говорить о том,что быстрее opengl или directx смысла нет, directx явно будет быстрее (?)

Я худею.



В подтверждение этому посмотрел аналогичные примеры под dx8.И на (a) и на (b) все как нужно. Т.е. более быстрое api далеко не opengl, а directx. Поправте если я в чем то ошибаюсь.

Ой, как же ты ошибаешься. Это потдверждает лишь то, что они работают отдельно!!!



Что лучше: использовать ddraw (как в старых директах) или уже не парится и пользовать d3d

ddraw умер, 2d api сейчас эмулиться через 3d. Оно и понятно, как бы аппаратное ускорение это не шутка.



Возможно стоит использовать opengl и dx8 одновременно ?

Для больших проектов это не имеет смысла. Хотя я видел одну 4k, которая для аппаратного умножения матриц юзала gl, а для шейдеров и прочего - d3d, там видимо кода инита меньше.



А может вообще и dx и opengl в сад, а юзать какую-нибудь хитро-сныканную dll которая совсем самый низ и все что надо в ней есть ?

Ниже уровнем вроде ничего нет. Ниже только драйвера.



(главный момент чтобы работало везде).

Вообще-то opengl - сдандарт для 3d api. (ни разу не реклама) =)))



О vc даже не спрашиваю

А чем интеловский копмпилер плох? Как сказал volodya, в чем я с ним согласен, если алгоритм оптимален и быстр, то мне плевать на мегабайты мусора в exe'шнике. Поэтому, если размер не играет самое решающее значение, по vc еще никто не отменял, хотя fasm - мой любимый ассемблер.

 

kas1e

А почему не стандартный FMOD, ведь он и форматы разные поддерживает и эффектов, AFAIK, в нём больше? А если нужен минимальный размер, но без потери качества, то есть молодой, но перспективный uFMOD (на правах рекламы - с совместимостью проблем быть не должно.



jekyll

Ага, я даже видел мобильник с OpenGL! Но раз под винду...

 

to jekyll:



Про (a) и (b) само собой перепутано. Тормоза на пипетке, быстро на тузике. Вопрос в том, почему на пипетке opengl тормозит сильнее dx'а раз в 10.



>=))))))0 Вот мне всегда интересен был смысл этих фраз. >Объясни пожалуйста. Нашел запись в таблице импорта и >сделал заключение, так что ли?



Я зделал заключение такое: если в opengl либе, по какойто причине указан ddraw.dll, то для чего то это ей нужно. Т.е. тут без выводов : в openg32.dll есть запись ddraw.dll - зачем ? Это первый вопрос. А второй - почему у меня на одном и томже железе, примеры с вашего сайта под dx летают (masm), а под opengl (fasm) не просто тормоза, а вообще слайдшоу.



>Я худею.

Не понимаю в чем худение это. Зачем в opengl либе вообще знать о директ икс либах ?





>Ой, как же ты ошибаешься. Это потдверждает лишь то, что >они работают отдельно!!!



Почему opengl медленее dx тогда ? Я не спорю, я просто хочу узнать почему на одном и томже железе opengl тормознее во много раз.



ps. насчет icc8, интел за него вроде 400 баксов хочет, может в курсе где 'нормальную' версию слить ?



to quantum:

а что за uFMOD ?



pss. И может в курсе есть гденить vc последний в минимальном наборе, чтобы токо линкер,компилер, либы и хидеры, минимум в общем.

 

IMHO:



Поскольку речь идёт о виндосе и в основном 2D, про OGL можно даже не думать.

DX будет быстрее: это часть GDI API, как user, так и kernel. OGL сверху, хотя скорость в 3D различаться (заметно) не должна.

Аппаратное ускорение - это хорошо, но (в 2D) будут случаи, когда это будет проигрывать софту.



>

Теоретически, эти интерфейсы будут вести к одному и тому же коду, практически же можно столкнуться с проблемами на старом железе. Вообще, не очень-то просто установить DX8+ на 95 (микрософт заявляет, что это вообще невозможно). DX7 должен работать везде, хотя на 98SE по умолчанию идёт DX6.



>

Можно ещё под DirectSound, если будет DX использоваться.



>

Если это треккерная музыка, то всё это берёт начало с того же Amiga mod и конверторы наверняка можно найти / написать. Если это FM, то можно реализовать (найти готовый) эмулятор Adlib и добавить к нему свой проигрыватель. В худьшем случае придётся реверсировать этот rad player. но всё это возможно, играет же музыка со Спектрума (см. аттач



>

fasm заметно более гибкий и многопроходный - оптимизирует по размеру переходы. masm imho более ограничен, да и проблемы какие-то с ним возникают странные :-(



>

watcom это OpenWatcom?

Про MSVC зря не спрашиваешь, очень неплохой компилятор, если интересует размер и уметь пользоваться.

borland нужно сразу вычёркивать из списка кандидатов. intel C++ в общем случае лучше по скорости кода, но размер может сильно раздуть :-(

Говорят, GNU C весьма неплох, но под виндосом наверное не очень актуален, тем более, что микрософт свой компилятор даёт бесплатно + PSDK.



>

На сайте интел и лежит нормальная, только лицензия нужна, но обсуждение вареза запрещено правилами форума.





1260486236__cpsp.rar

 

to stas:



Насколько я понял, проблема в том, что у меня на слабой тачке у саваджа нет апаратного ogl, и он бедный софтварно на 750 мегеровом проце пытается, потому и текстурный куб в нормальном разрешалове уже встает практически. По идее отличий в 3д быть не должно если для карты есть дрова чтобы апаратно ogl делать .. Видимо на саваджах на это забили. Надеюсь на гефорсах то хоть оно апаратное ? Почему то меня эта запись в opengl32 про ddraw прибила просто.



В общем выходит так - если писать чтото под dx8, то там где он встанет , и если все нормально написано, работать все и будет. При желании можно делать версию для dx7



Интерсно просто, как велико количество карт на которых апаратно есть под винду ogl дрова , в противовес апаратной поддержке dx ? Как я понимаю все меньше и меньше, и ms от ogl вообще скоро откажется ?





По поводу музыки, я про fm, да. Rad Player уже в сорцах сам по себе, а то что он работает это досовская эмуляция,

и не на каждой винде почемуто .. Вариант эмуля адлиба найти в сорцах под винду, укоцать как нужно и сделать свой плэер самое оно скорей всего. А атач супер. Я аж в детство улетел И внутрях токо 2 ссылки на kernel32 и user32, прям как надо Именно такого плана и хочу, мелкие 2д интрушки аля старых cractro всяких амижных, и такой вот дебильноватой музыкой чтобы мало по размеру, быстро работало и создовалось впечатление легкости, как на амиге когда под aga херачили. Я-бы и под дос с радостью, да только это уж совсем не в какие ворота



По поводу watcom - да, open который. Там удобно, что можно прям _asm { поехали }, но как вижу в твоих сорцах vc и по размеру сделал файло в 5 килов всего (правда upx на нем обломился, а там пустого места то тоже хватает, кила 2-3 можно всяко ), и __asm также практически. Вчера хотел попробовать vc, качнул с ms VCToolkitSetup.exe 2003 на 32 метра. Запускаю исталяху, он мне 1601: Error installing Microsoft(R) .NET FrameWork. В сам архив залез install explorer'om, вытащил 5 файлов, среди них инишники, msi,но какието не ini и не msi совсем. Короче так я его и не поставил, все думаю может гдето, ктото уже собрал нормальный архив этого vc с минимум необходимого ?



ps. Кстати fasm'ом либы или обджы делать можно которые потом в vc прилинковывать ?

 

kas1e >

afaik он там есть, может нет каких-нить расширений или ещё чего. А может реализация кривая :-/



>

Аппаратная часть у карточек всё равно одна, следовательно и возможности предоставляемые этими API тоже почти одинаковы. А если посмотреть в доки DDK, то можно увидеть DirectDraw DDI, Direct3D DDI, а про OGL ничего не сказано. Отсюда я делаю вывод - OGL прослойка поверх D3D.



>

Я ещё думаю сделать проигрыватель ZXS формата (sound tracker со Спектрума), как только найду немного времени и

"живой" ST проигрыватель для опытов. Ещё есть файлы AY (ZXAYEMUL с Amiga ?) их наверное тоже можно как-то приспособить. Это всё правда не для Adlib, а для AY. Обычный размер 1 - 3 Кб, пакуются ещё раза в 2-3 .



OpenWatcom я не видел, во времена ДОСа по слухам их компилятор был одним из лучших, но времена меняются.. не знаю даже стОит ли его качать и смотреть..



VCToolkitSetup сначала устанавливает .NET framework, если его ставить на комп, где это уже есть, то должен пропустить этот шаг. Вообще, ошибка странная, видно что-то в виндосом не в порядке. Я могу вырипать компилятор и намылить - но толку от него одного не очень много, нужно ещё тучу инклудов из platform SDK, DX SDK, ...



>

Да, он может делать MS COFF объектники. Синтаксис у него отличается от MASM - подобен NASM и ideal в TASM.

 

kas1e

На сайте лежит в разделе "Исходники".

 

kas1e

> качнул с ms VCToolkitSetup.exe 2003 на 32 метра. Запускаю исталяху, он мне 1601: Error installing Microsoft(R) .NET FrameWork.



Ну дык на 98-ю винду он и не поставится

Если это на 2k, то обнови MSI инсталлер.



Quantum

Ты переместился в какой-то другой часовой пояс





S_T_A_S_

> Про MSVC зря не спрашиваешь, очень неплохой компилятор, если интересует размер и уметь пользоваться



Что-то он меня разочаровывает :-( Хотя может новые те что NET и получше, но моя 6-ка преподносит сюрпризы..

 

Дык тот старый и совсем драный =)

Вот с 14й версией (2005 бета1) что-то не пойму, как там можно без crt что-то скомпилить :-(

 

asterix



Винда первая - xp sp1 eng, msiexec - v 2.00.2600.0

Винда вторая - xp sp1 rus, msiexec - v 2.00.2600.1106



на обоих такая ошибка.

 

kas1e

Я точно не помню, но кажется у меня была тоже какая-то ошибка, но после перезагрузки винды и перезапуска инсталлятора всё установилось.

 

asterix

поставил msi installer 3тий, все ок стало. А то, что нету windows.h хотябы в инклудах, это шутка аля качайте psdk на 250 мегов ?

 

Quantum

Ага, я даже видел мобильник с OpenGL! Но раз под винду...

Есть такое, OpenGL ES называется.



S_T_A_S_

Поскольку речь идёт о виндосе и в основном 2D, про OGL можно даже не думать.

DX будет быстрее: это часть GDI API, как user, так и kernel. OGL сверху, хотя скорость в 3D различаться (заметно) не должна.

Не пойму я что-то, откуда такие выводы.



Простой эксперимент.

1. Берем голую машину, ставим винду со стандартными дровами, смотрим какую-нить интрушку под ogl. Что же мы видим - отстой полный, тормоза и все такое, хотя директовые будут работать на ура.

2. Ставим свеженькие драйвера для видяхи - замечу особенно, никаких свежих директов нам не нужно. И о чудо! Все летает, все красиво, в шоколаде усе!!!



А теперь внимание вопрос. Где здесь половая связь между DirectX и OpenGL? И в какой позе они совокупляются кто сверху, кто снизу?

 

> Ставим свеженькие драйвера для видяхи



В последнее время попасть на нормальные драйвера например от nVidia - лотерея.. Качнул давеча самые свежайшие для win98, поставил, запустил NFSpeed Underground 2, машинки получились белые без текстур, экран постоянно дёргается из-за срыва синхронизации, вобщем не знаю что они там намутили, откатился на скачанные летом(хотя в игрушке настоятельно рекомендовали свежайшие) и всё прекрасно заработало с последним Directx9c, предыдущие, до этих удачных, тоже глючили..

 

jekyll



По хорошему все и должно быть как ты говоришь, а на деле с opengl почему то запар больше выходит (во всяком случае на сколько я знаю nvidia cо своими гефорсами сейчас более распротранена,и раз на ней дрова часто не такие правильные как должны быть, то вывод такой - что с opengl правильно настроенным встретить тачку тяжелей, чем с правильно настроеным directx ). Как пример совсем рядом - пост последний астерикса, и то что у меня на савадже с нормальными дровами opengl видимо не через дрова работает. Конечно можно сказать всем, что мол - раз не настроено, извиняйте. Но вопрос как раз именно про большую совместимость с тем как оно чаще всего на данный момент бывает. Само собой что можно сказать: руки в 屁股 у кого , и кто не может настроить opengl нормально, те идут в сад. Однако всеже выходит (вроде как), что юзеров с директами (нормально функционирующими) сейчас больше, согласен ?



И про вопрос, зачем в opengl32.dll есть упоминание ddraw.dll ты не ответил Кстати самое смешное, что в ddraw.dll, есть упоминание о gdi32.dll



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



А про половую связь вывод даже просто такой, от балды: Согласись,что ms выгоднее продвигать свой directx виндовый весь такой, чем чейто там opengl? (Отсуда хотябы уже можно прикинуть, что с opengl на винде запар будет в будущем всяко больше даже чем сейчас) Я имею ввиду не конкретные видяхи и дрова, а именно "винда на тачке юзеров".



В общем главный вывод: Если писать под dx (сейчас имеется ввиду), то вам гарантирован больший процент "аппаратной" так сказать совместимости, чем если писать под opengl. Не согласен ?

 

Если кому интересно, то ситуация выглядит примерно так (с gamedev подсказали).



ddraw.dll юзают все кому не лень,как менеджер видеопамяти. Т.е. только одну DirectDrawCreate, поскольку оно возращает указатель на com интерфейс через который далее и работают. Т.е. при использовании каких бы там не было правильно написаных дров поддерживающих api glя, рендер будет все равно на поверхности ddraw _программно_.



Далее, если дрова стоят нормальные (например от nvidia),то весь так сказать "хардварный" ogl лежит в nvoglint.dll(там уже есть упоминание про opengl32.dll,который потом заюзает ddraw.dll )



Вывод: любые правильно написанные дрова, юзают ms'овский ddraw. Что в общем как и должно быть, и соответвенно под dx если писать, скорость будет выше. + о вопросе размера. Если использовать dx, то раздел импорта при юзанье dx'а должен быть меньше , т.к. com.

 

с opengl правильно настроенным встретить тачку тяжелей, чем с правильно настроеным directx

А вот черт его знает. Тут надо опрос, статистику, а так говорить совершенно бессмысленно.



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

Это nVidia гады, свои дрова на юзерах испытывает. Про последние могу сказать вот что, скачал у друга поставил, так 2 андерграунд вообще отказался работать. А у меня все нормально. Ну и что за драйвера такие спрашивается?



Однако всеже выходит (вроде как), что юзеров с директами (нормально функционирующими) сейчас больше, согласен ?

Про это я уже говорил выше. Давайте опрос проведем.



И про вопрос, зачем в opengl32.dll есть упоминание ddraw.dll ты не ответил

Точного ответа я не знаю, могу лишь предположить что он используется на финальной стадии смены буферов.



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

Что может быть проще.

Asus fx-5700. detonator 6.6.9.3



Согласись,что ms выгоднее продвигать свой directx виндовый весь такой, чем чейто там opengl?

Что верно, то верно. Но и OpenGL им приходится поддерживать, даже документацию в MSDN обновляют.



Если писать под dx (сейчас имеется ввиду), то вам гарантирован больший процент "аппаратной" так сказать совместимости, чем если писать под opengl. Не согласен ?

Винда и гарантии? Ты нечего не путаешь?

 

jekyll >

\DDK\help\graphics.chm



>

Почитай системные требования





kas1e >

Не только импорт, но и сами вызовы COM-методов занимают меньше места.





jekyll >

Идеалогия COM интерфейса гарантирует обратную совместимость с предудущими версиями, он собственно, для этого и создавался.

 

S_T_A_S_

\DDK\help\graphics.chm

Он большой? Кинуть сюда сможешь?



Почитай системные требования

Чьи? Интры что ли?



Идеалогия COM интерфейса гарантирует обратную совместимость с предудущими версиями, он собственно, для этого и создавался.

Всегда ли это так?