Что выбрать GDI vs DirectX vs OpenGL?

От API требуется только доступ к памяти поверхности (вида void * pData, и битблт. Пишу своё простенькое 3d API, что бы разобратся, поэтому на чём писать без разницы, главное скорость... Планируется (это так, для справки) простенький лист фэйсов, из листа вершин, который загружается из файла, в доме который построил Джэк... затем своими функциями отсечение, проецироваине, освещение; уже после реализации этого, какие нить покруче штуки...
Вопрос в том, что использовать для вывода... С OpenGL'ом я знаком, но знаю что для вывода он использует DirectDraw, по нему у меня есть кинга Ламота, так что тоже проблем нет, !но непомню где прочитал, что изза остановки разработки DirectDraw, GDI стал опережать по скорости его... незнаю правда это или нет... но если так то можно в GDI создавать картинку рисовать в неё а потом копировать на экран... с GDI я благо хорошо знаком.
Не используются возможности API, потому что хочу отойти от представления объекта в полигональном виде и использовать алгоритм рейкэстинга... а в современных API это реализвать не получится...
Спасибо.

 

b0oh

Напиши все три реализации. При грамотном подходе это 10 минут на каждую платформу.

Всетаки кастинга или трейсинга?

Да сколько угодно.

 

b0oh
Чувствую, что ты не в чем не разбираешься. OpenGL не использует DirectDraw.
GDI не опережает DirectDraw. Только GDI+ при условии аппаратной поддержке позволяет выполнять некоторые функции быстрее.

API позволяет.

BitBlt реализован везде аппаратно. Раз уж ты собрался свой вывод делать. То тебе по сути должно быть без различно на все лишь бы копирование шло на максимальной скорости.

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

 

окей, опять меня опустили...
BitBlt везде везде реализован аппаратно? Так что неважно при помощи чего я буду копировать изображение в видеопамять? будет ли это GDI'ный BitBlt или же DirectDraw...
Такой вопрос... если я создаю изображение средствами GDI оно находится в оперативной памяти или же в памяти видеокарты, ведь насколько я понимаю копирование участков памати произойдёт быстрее из видеокарты в видеокарту, и если картинка выделяется в оп. памяти каким образом можно реализовать что бы память выделялась в видеокарте...
Спасибо...

 

b0oh

Считай что везде. Разница есть, но не существенно.

Чтобы что-то скопировать из видео памяти в видео память это нужно туда поместить. Так что все равно из основной в видео память копировать надо.

 

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

 

CodeTao
К примеру у меня на GDI BitBlt на экран выполняется за 2.3-10 (640*480-1280*1024) миллисекунды. Что составляет 100-400 кадров в секунды при условии моргания монитора 75Гц все перекрывается. Дело не в скорости копирования. А в том что построение изображения у него займет существенно больше времени.
У меня AGP 3x Частота 66МГц шина 64 Бита 66 000 000 * 64 / (1280*1024*32)=100 кадров/с вывод быстрее не получиться копировать. Осталось только снизить накладные расходы, чтобы копирование шло не за счет ЦП, а за счет ГП.

 

Проблема в том что если ты не используешь ни OpenGL ни DirectX, а все через делаешь через GDI, да еще в оконом режиме, то изображение сначала маштобируется, потом проходит через пласт контекстов и тока после этого передается на видеокарту. У меня был курсовой где надо было конкатенировать две бмп-хи, да и выводить на экран, все было хорошо пока не начинал такскать окно по экрану или изменять пропорции, даже не хилых компах были видны мерцания, я перешел на dx, прога сильно не изменилась(правда конечная картинка уже хранилась в поверхность), все тот же bitblt но уже через интерфейс поверхности - и нериализованные в качестрве фич глюки пропали. Пропускная способность шины конечно хорошо, но тормознутось GDI майкросовт не собирается убирать.

 

На что конкретнее, DirectDraw?

 

CodeTao
Что, на это можно сказать. Плохому танцору и яйца мешают. Никаких мерцаний я не замечал даже на 300МГЦ проце при правильной реализации.

 

CodeTao

А ты по WM_ERASEBKGND InvalidateRect делал? ))))))

 

_DEN_
Это не обязательно, т.к. можно просто не давать системе обрабатывать WM_ERASEBKGND, а переходить сразу к WM_PAINT.

 

asmfan

Чего?... )

 

перед перерисовкой стирается бэкграунд по дефолту.

 

Я как раз на 366 пне и оплаживал программу... Ну на счет мерцания я конечно загнул, но прорисовка видна и на 1.5гиге при изменении параметров(+ картинка изменяется не плавно а скачками - я использовал бегунок для изменения соотношения). И что б ты не говорил но при переходе на DDraw все же стало отображаться гораздо лучше. Единственный грех в том курсовике был что я для отображения стационарной картинке использовал два BitBlt, а не один, но впринципе это на быстродействии не сказывалось.

PS: В оригиналноей метафоре были ноги.

2 _DEN_:

 

asmfan

Эээээйййй, чуввваааак... Чувввак, ну ты чоооо?

WM_ERASEBKGND, да будет тебе известно, ничего не стирает, а оповещает о том, что бекграунд был потерт. Именно по нему и надо делать InvalidateRect. Когда ты таскаешь окошко или ресайзишь его, WM_PAINT не приходит.

 

.

 

_DEN_
Масяня, ты чтоль?)

 

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

Код (Text):

1.   bh, pData - битмап в памяти куда рендерится картинка.
2.   HBITMAP CompatibleBitmap = CreateDIBSection(0, (BITMAPINFO*)bh, DIB_RGB_COLORS, &pData, 0, 0);
3.   ...
4.  
5.   SetStretchBltMode(hdc, HALFTONE); // для билинейной интерполяции
6.   HDC memDC = CreateCompatibleDC(hdc);
7.   HBITMAP hOldBitmap = (HBITMAP)SelectObject(memDC, CompatibleBitmap);
8.   StretchBlt(hdc, ix, iy, iw, ih, memDC, 0, 0, w, h, SRCCOPY);
9.   SelectObject(memDC, hOldBitmap);
10.   GdiFlush();
11.   DeleteDC(memDC);

По скорости способ летает по сравнению с неаппаратным GDI масштабированием и это явно заметно. С DX я не сравнивал, но какие-то нежелательные действия GDI с картинкой все-таки делает, я наталкивался на случай, когда если в 24битной картинке лежит битмап из 16 уникальных цветов, то визуально масштабирование изменяется, я уже не помню как, давно это было, стоит изменить 1 пиксел в pData и вся картинка сразу меняется. Тоесть похоже производится анализ картинки, не берусь утверждать что это не из-за дров видяхи. В DX все чисто.

 

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

CodeTao
Отрисовка при копировании бывает видна из-за отсутствия синхронизации копирования с кадровой развёрткой, поэтому я через 7 интерфейс ДХ определял обратный ход по кадру (GetScanLine или на крайняк WaitForVerticalBlank), а для копирования юзал GDIшный StretchDIBits чтобы не связываться с самостоятельной реализацией смены глубины цвета и никаких проблем на современных машинах не наблюдается , правда на PII 266 МГц бывает что StretchDIBits не успевает перекодировать цвет за время кадра ) тогда проблема решается двоймым копирование StretchDIBits в промежуточный буфер затем синхронизированный (через ДХ) BitBlt в экран