Ваткин Сергей

Dempski Kelly

Watson Johnny

Поздняков Константин

DirectX 8. Начинаем работу с DirectX Graphics

GameDev.ru

DirectX 8: Начинаем работу с DirectX Graphics

Автор: voxatu

(пример написан на основе первого "родного" туториала к DirectX SDK 8.0)

Ну, наконец-то мы дошли до самой сути, а именно - до начала работы непосредственно с DirectX! Сейчас напишем вместе прогу, которая создаст класс, окошко, инициализирует объекты Direct3D и… в итоге у нас получится — сами увидите что :-) Советую СКАЧАТЬ ПРИМЕР в архиве и читать дальше, имея исходники перед глазами. Чтобы открыть пример, необходимо сначала разархивировать его в отдельную директорию, затем нажать File->Open Workspace и открыть файл "D3D Init.dsw" из этой директории. Ну… поехали.

Сначала необходимо написать include'ы, описать глобальные переменные, которые мы будем использовать в программе, а также объявить прототипы функций:

//Включаем все функции, необходимые для работы с D3D.

//<windows.h> уже включен в этом файле

#include <d3d8.h>

#include <stdio.h> //В дальнейшем нам понадобится функция sprintf()

LPDIRECT3D8 g_pD3D = NULL; //Понадобится нам, чтобы создать D3DDevice

//Это наше устройство rendering'а (Rendering Device)

LPDIRECT3DDEVICE8 g_pd3dDevice = NULL;

WNDCLASSEX wclass;

//Объявляем прототипы функций

VOID Init(HWND); //Инициализация D3D

VOID Render(); //Рендеринг сцены

VOID Sweep(); //Очистка после выполнения программы

//Обработка сообщений, поступивших окну

LRESULT CALLBACK MessageProc(HWND, UINT, WPARAM, LPARAM);

Что же такое Render? "Render" с английского переводится как: "переводить", "просчитывать", "визуализировать". Все объекты, которые находятся на нашей виртуальной сцене, хранятся в памяти в виде отдельных блоков: источники света, каркас, состоящий из вершин (точка в 3-D пространстве), текстуры, и т.д. Но видеокарта не может все это показать на экране, т.к. может вывести только последовательность разноцветных точек. Rendering Device как раз и выполняет эту функцию, т.е. преобразует всю нашу сцену в "понятный" для видеокарты вид.

В своих статьях я не буду переводить некоторые английские термины на русский язык, а буду их "руссифицировать" (например, я не буду переводить "rendering device", как "делательное устройство" или "устройство просчёта", а буду просто говорить "устройство рендеринга" или вообще "девайс для рендеринга" (всякое может случиться %) )). Дело не в том, что я не могу подобрать тому или иному английскому термину русский эквивалент. Просто иногда лучше пользоваться "родными" названиями (мы же не называем "Visual C" Визульным Си =-)). Едем дальше…

В нашей программе будет пять функций: функция WinMain(), Init(), Render(), Sweep() и функция обработки сообщений MessageProc(). Каждая функция представляет собой некий блок программы, который выполняет исключительно свою операцию. Например Init() будет инициализировать Direct3D (в дальнейшем, просто D3D), Render() — рендерить сцену, а Sweep() — производить очистку после выполнения программы. Я постарался, как можно больше упростить программу, поэтому урезал некоторые моменты (например, обработку ошибок, которые могут возникнуть при инициализации). В последующих программах мы будем стараться "честно" учитывать все возможные ошибки и обрабатывать их. Итак, рассмотрим подробнее, что же делают наши функции.

Функция WinMain()

Самая главная функция. Именно с нее начинается выполнение любой программы, написанной под Windows. В нашем случае она делает вот что:

Описываем переменные.

HWND hWnd; //Handle окна

MSG msg;

Затем идет настройка параметров класса, регистрация класса в системе и создание окна, представляющего этот класс.

//Настраиваем параметры класса wclass перед его регистрацией в системе

wclass.cbSize=sizeof(wndclassex);

wclass.style=CS_DBLCLKS;

wclass.lpfnWndProc=&MessageProc;

//Функция обрабатывающая сообщения

wclass.cbClsExtra=0;

wclass.cbWndExtra=0;

wclass.hInstance=hInst;

wclass.hIcon=LoadIcon(NULL, IDI_APPLICATION);

wclass.hCursor=LoadCursor(NULL, IDC_ARROW);

wclass.hbrBackground=GetSysColorBrush(COLOR_APPWORKSPACE);

wclass.lpszMenuName=NULL;

wclass.lpszClassName="InitClass";

wclass.hIconSm=NULL;

//Выходим, если не удалось зарегистрировать класс

if (!RegisterClassEx(&wclass)) return 0;

//Теперь создадим окно и занесем его handle в hWnd

hWnd =

CreateWindow("InitClass", "D3D Init", WS_SYSMENU|WS_OVERLAPPED|WS_MINIMIZEBOX,  100, 100, 420, 300, NULL, NULL, hInst, NULL);

Подробное описание структуры WNDCLASSEX и параметров функции CreateWindow() смотри в статье JM'а "Введение в программирование под Windows". Стоит обратить внимание на то, что мы после всех манипуляций будем иметь в hWnd дескриптор окна, в котором затем сможем отображать нашу сцену.

Теперь обратимся к функции инициализации D3D:

Init(hWnd);

Остается только показать на экране наше окно

ShowWindow(hWnd, nCmdShow);

//Рисуем окошко

UpdateWindow(hWnd);

и организовать цикл обработки сообщений окну

while (GetMessage(&msg, NULL, 0, 0)) //Цикл обработки сообщений

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

return (msg.wParam);

Функция Init()

Теперь, когда у нас есть окно, мы готовы к инициализации объекта Direct3D. Зачем он нужен? Как только будет создан объект Direct3D, мы сможем использовать метод IDirect3D8::CreateDevice() для создания устройства Direct3D (предварительно настроив его параметры), т.е. нашего устройства рендеринга. Параметры устройства задаются непосредственно перед его созданием с помощью структуры D3DPRESENT_PARAMETERS, и передаются в метод IDirect3D8::CreateDevice(). Рассмотрим этот процесс подробнее. Итак, создаем объект Direct3D:

g_pD3D=Direct3DCreate8(D3D_SDK_VERSION);

Единственным параметром функции Direct3DCreate8 является UINT SDKVersion, который должен быть D3D_SDK_VERSION. Это необходимо для того, чтобы при компиляции программы были использованы правильные заголовочные файлы [*.h] (замечание: если после создания объекта были подключены новые адаптеры, необходимо повторно инициализировать объект Direct3D, чтобы использовать их). Если в процессе инициализации произошла ошибка, то Direct3DCreate8 возвращает NULL (т.е. пустой указатель).

Уже пора определиться, что же будет делать наша программа :).

После запуска она создаст и прорисует окошечко, в заголовке которого будет показано текущее разрешение графического адаптера, а в рабочей области — отрендеренная сцена. В данном примере сцена не будет содержать никаких объектов, поэтому отрендерится только темно-синий фон.

Заголовок окна ("window name" стоило перевести как "имя окна", но тогда как-то несолидно звучит :) ) будет содержаться в строке символов str (т.е. str указывает на первый символ строки). Чтобы сформировать str, необходимо узнать ширину (Width) и высоту (Height) текущего видеорежима, а затем воспользоваться стандартной Си'шной функцией sprintf(), которая осуществляет форматированный вывод в строку. Как же узнать ширину и высоту текущего видеорежима? Для этого воспользуемся методом IDirect3D8::GetAdapterDisplayMode, который возвращает текущий режим видеоадаптера в структуру D3DDISPLAYMODE. Затем из структуры "выуживаем" необходимые параметры Width и Height, формируем строку str. Остается только изменить заголовок нашего окна с помощью стандартной WinAPI функции SetWindowText():

D3DDISPLAYMODE dm;

//В переменной dm будет храниться текущий видеорежим

//Заголовок нашего окна. Будет генериться в зависимости от текущего видеорежима

char str[128];

g_pD3D->GetAdapterDisplayMode(D3DADAPTER_DEFAULT, &dm);

Width=dm.Width;

Height=dm.Height;

sprintf(str," (D3D Init) Current adapter mode: [%dx%d]", Width, Height);

SetWindowText(hWnd, str);

Наконец, займемся непосредственно инициализацией D3D. Как было сказано выше, нам понадобится переменная-структура типа D3DPRESENT_PARAMETERS. Опишем эту переменную и выделим для нее память:

//Структура понадобится для создания D3DDevice

D3DPRESENT_PARAMETERS p_p;

ZeroMemory(&p_p, sizeof(p_p));

Меняя поля структуры p_p, мы можем гибко настраивать параметры нашего трехмерного приложения. На этой стадии определяется, будет ли наше приложение оконным или полноэкранным, задается частота обновления экрана (только для полноэкранного режима), необходимое количество бэк-буферов (BackBuffer) и т.д. Бэк-буфер — это область памяти для хранения одного неактивного в данный момент (т.е. визуально скрытого от пользователя) видеоэкрана. В бэк-буфер можно рендерить сцену, в то время, как пользователь видит на экране другую картинку, и практически моментально выводить содержимое бэк-буфера на экран.

Мы создаем оконное приложение (об этом говорит строка p_p.Windowed=TRUE;), поэтому необходимо установить формат бэк-буфера таким же, как и формат текущего видеорежима (как ты помнишь, он у нас хранится в переменной dm.Format). Поле SwapEffect задает способ обмена между франт-буфером (FrontBuffer, т.е. тот, который сейчас активен) и бэк-буфером. Существуют несколько значений этого параметра. Мы будем использовать D3DSWAPEFFECT_DISCARD ("discard" переводится с английского, как "сбрасывать", "отбрасывать"), т.е. после вывода на экран содержимое бэк-буфера заполняется "шумами" ("noise"). Реализуем задумки в программный код:

p_p.BackBufferFormat = dm.Format;

p_p.Windowed=TRUE;

p_p.SwapEffect=D3DSWAPEFFECT_DISCARD;

Последний шаг, который осуществляет наша функция Init() — создание устройства. Для этого воспользуемся методом IDirect3D8::CreateDevice().

Укажем следующие параметры:

a. D3DADAPTER_DEFAULT — используется стандартный видеоадаптер

b. D3DDEVTYPE_REF — визуализация будет происходить исключительно программными средствами Direct3D

c. hWnd — собственно, идентификатор окна

d. D3DCREATE_SOFTWARE_VERTEXPROCESSING — обработка точек будет происходить исключительно программными средствами

e. &p_p — указатель на структуру, описывающую параметры создающегося устройства

f. &g_pd3dDevice — адрес указателя на интерфейс IDirect3DDevice8, который будет создан

Вот, что должно получиться:

g_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_REF, hWnd,  D3DCREATE_SOFTWARE_VERTEXPROCESSING, &p_p,&g_pd3dDevice);

Функция Render()

Эта функция как раз рендерит сцену. Принцип ее действия:

a. Очищается бэк-буфер, и в него рендерится сцена (итого, в бэк-буфере окажется темно-синий экран, т.к. сцена не содержит объектов)

b. Происходит передача данных во франт-буфер

c. Содержимое франт-буфера "выбрасывается" на экран

Очистить сцену можно вызвав метод IDirect3DDevice8::Clear(). Его первые два параметра мы обнуляем, т.к. хотим очистить экран (на самом деле не экран, а рабочую область окна, но так проще писать :) ) целиком. Значение третьего параметра (D3DCLEAR_TARGET) говорит о том, что очистка должна происходить цветом, заданным четвертым параметром (в нашем случае D3DCOLOR_XRGB(30, 60, 120)). Последние два параметра в нашем случае игнорируются. Поэтому, пишем:

g_pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(30, 60, 120), 1.0f, 0);

Подготовка завершена, переходим к рендерингу в бэк-буфер:

g_pd3dDevice->BeginScene();

g_pd3dDevice->EndScene();

Методы IDirect3DDevice8::BeginScene() и IDirect3DDevice8::EndScene() показывают, в каком месте начинается, а в каком заканчивается процесс рендеринга. Все методы рендеринга, вызванные вне зоны ограниченной данными операторами, игнорируются.

Последний шаг - передача видеоданных на экран через франт-буфер. Это осуществляется с помощью метода IDirect3DDevice8::Present().

g_pd3dDevice->Present(NULL, NULL, NULL, NULL);

Первые два параметра задают прямоугольные области источника (бэк-буфера) и места назначения (франт-буфера), поскольку копируется целиком вся область, то эти параметры выставлены в ноль. Третий параметр - указатель на принимающее окно, в клиентскую часть которого происходит выполнение метода Present(). Поскольку мы используем структуру D3DPRESENT_PARAMETERS, то третий параметр выставляем в NULL. Четвертый параметр — никогда не используется, его всегда нужно выставлять в NULL :-)

Функция Sweep()

Самая короткая по программному коду функция. Осуществляет "подчистку" после нашей работы.

g_pd3dDevice->Release();

g_pD3D->Release();

UnregisterClass("InitClass", wclass.hInstance);

Все просто. Сначала освобождаем устройства рендеринга, затем объект D3D. После этого остается лишь удалить класс окна и все!

Функция MessageProc()

Стандартная функция всех Windows приложений (название функции может быть любым), которая обрабатывает поступившие окну сообщения.

switch (msg) {

case WM_DESTROY:

Sweep();

PostQuitMessage(0);

break;

case WM_PAINT:

Render();

ValidateRect(hWnd, NULL);

break;

default:

return DefWindowProc(hWnd, msg, wParam, lParam);

break;

}

Если окну поступает сообщение WM_DESTROY, то происходит "подчистка" функцией Sweep(), а обращение к функции PostQuitMessage(0) говорит системе, что наше приложение завершило работу. Если же окну поступило сообщение WM_PAINT (например, когда пользователь передвинул окно мышкой), то все окно должно быть немедленно перерисовано, что и делает наша функция Render(). Остальные сообщения обрабатываются стандартным образом. Как мне приятно описывать эту функцию :-) И не потому, что она последняя в данной статье. Просто в ней все красиво, т.к. ранее мы подготовили базу для ее работы.

Ну, вот и все. Надеюсь, что ты почерпал из этой статьи для себя что-то новое и интересное… Не пугайся, если программа показалась тебе слишком большой и сложной. Это не значит, что для рисования треугольника придется добавлять к ней такой же большой кусок кода. Просто дописать пару десятков строчек кода и делов-то :-) Ты сделал самый сложный шаг — первый. Теперь будет легче. Позже будем учиться отрисовывать трехмерные объекты, научимся использовать матрицы трансформации, устанавливать источники света, накладывать текстуры… Но об этом уже в следующих статьях…

Удачной тебе компиляции!

Примечание: Если будешь писать программу сам, помни, что для ее компиляции нужно подключить библиотечные файлы [*.lib]. Lib'ы подключайются так:

a. Project->Settings…

b. Открой вкладку "Link"

c. В строке "Object/library modules" добавь в начало d3d8.lib

d. Должно получиться примерно следующее: "d3d8.lib kernel32.lib user32.lib gdi32.lib…"

Автор: voxatu.

DirectX 8: Создание и текстурирование простого трехмерного объекта

Автор: voxatu

Ты уже умеешь инициализировать Direct3D, а значит можно на этой базе создавать трехмерные объекты. Чтобы было совсем интересно, натянем на наш трехмерный объект текстуру и заставим его вращаться!!! Кроме того, воспользуемся фильтрацией текстур и MipMapping'ом, чтобы получить более реалистичный результат почти без потери быстродействия. Попутно, научимся работать со вспомогательной библиотекой Direct3DX. Пример можешь скачать ЗДЕСЬ.

Итак, приступим. За "трехмерный объект" возьмем правильную четырехугольную пирамиду, а за текстуру — подредактированную фотографию каменной стены (первоначальный вариант текстуры взят с сайта http://www.3dcafe.com/, на котором собрано огромное количество различных бесплатных для скачивания изображений).

Функции WinMain(), MessageProc() и InitD3D() будут очень похожи на аналогичные функции программы из предыдущей статьи, поэтому я буду объяснять, в основном, только модифицированные их части. Структура программы немного изменилась. Теперь более грамотно обрабатываются ошибки, которые могут возникнуть при выполнении той или иной части программы.

Рассмотренные функции исходника:

Функция WinMain()

Функция Initialization()

Функция InitD3D()

Функция InitTexture()

Функция InitScene

Функция DoMatrices()

Функция RenderScene()

Функция Deinitialization()

Функция MessageProc()

Функция WinMain()

Главная функция нашего приложения. Практически аналогична одноименной функции из предыдущей статьи. Единственное, что сильно изменилось — цикл обработки сообщений. Также, вынесены в отдельные функции инициализация и деинициализация приложения.

if (Initialization(hWnd)) {

ShowWindow(hWnd, nCmdShow);

UpdateWindow(hWnd);

MSG msg;

ZeroMemory(&msg, sizeof(msg));

while(msg.message != WM_QUIT) {

if (PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE)) {

TranslateMessage(&msg);

DispatchMessage(&msg);

} else RenderScene();

}

}

Deinitialization();

Если инициализация проходит успешно, окно приложения отображается на экране и начинается цикл обработки сообщений, иначе деинициализация и выход из программы. Функция PeekMessage() проверяет очередь сообщений для текущей нити процесса и, если таковые имеются, помещает одно из них в структуру MSG. Флаг PM_REMOVE говорит о том, что сообщение из очереди удаляется, т.е. на нас возлагается ответственность его корректной обработки в любом случае. Это мы и делаем в следующих двух строчках. Если же очередь сообщений пуста, вызывается функция RenderScene(), которая, согласно ее названию, рендерит очередной кадр сцены. Как только поступает сообщение WM_QUIT, происходит деинициализация приложения (функция Deinitialization()).

Функция Initialization()

Осуществляет грамотную (т.е. с учетом ошибок) инициализацию D3D, текстур и сцены. Замечу, что все функции нашего приложения, в которых может возникнуть ошибка, имеют тип BOOL. Рассмотрим программный код:

CurrentFilter = D3DTEXF_NONE;

if (!InitD3D(hWnd)) return FALSE;

if (!InitTexture()) {

MessageBox(NULL, "Не найден файл текстуры!", "Ошибка", MB_ICONERROR);

return FALSE;

}

if (!InitScene()) return FALSE;

return TRUE;

Что такое CurrentFilter? Забегая вперед, скажу, что наша программа будет использовать фильтрацию текстур, причем можно будет переключаться между различными фильтрами. Неплохо для первой программы с использованием D3D? ;-) Итак, первая строка кода говорит, что по умолчанию фильтром является D3DTEXF_NONE, т.е. фильтрация не используется. Затем вызываются три функции дополнительной инициализации, причем, если хотя бы в одной из них возникнет ошибка, функция Initialization() вернет значение FALSE, что в свою очередь остановит выполнение программы (вспомни функцию WinMain()) и приведет к деинициализации. Если функция InitTexture() возвращает значение FALSE, значит не удалось найти файл текстуры и перед аварийным завершением программы необходимо вывести предупредительное сообщение: MessageBox(NULL, "Не найден файл текстуры!", "Ошибка", MB_ICONERROR);

Функция InitD3D()

Согласно названию, эта функция инициализирует D3D %) Перед созданием устройства рендеринга, необходимо настроить параметры D3DPRESENT_PARAMETERS. К параметрам, которые мы использовали в предыдущем приложении добавилось лишь две строки:

p_p.EnableAutoDepthStencil = TRUE;

p_p.AutoDepthStencilFormat = D3DFMT_D16;

Первая говорит о том, что при рендеринге будет использоваться Depth Buffer ("буфер глубины"), причем D3D будет управлять им автоматически. Когда разберешься с программой, попробуй поэкспериментировать: запусти программу в исходном виде, а затем проверь, что получится, если эти две строки удалить. Depth Buffer еще называют Z-Buffer'ом.

Рассмотрим принцип его использования на примере. Представь себе человека на фоне кирпичной стены… Теперь мысленно переведи эту "сцену" в Direct3D (для этого, необходимо задать человека и стену в виде набора текстурированных полигонов) и заставь его эту сцену отрендерить. То, что мы увидим на экране — всего лишь двумерная проекция нашей сцены. Т.о., D3D спроектировал на плоскость экрана стену и человека. Причем, мы увидели человека на фоне стены, а не стену на фоне человека, т.к. он стоит ближе к нам Ж-) Как же D3D "узнает" что именно проектировать на экран раньше, чтобы не было бессмысленных перекрытий? Для этого используется Z-Buffer! Z-Buffer представляет собой массив Z-координат каждой точки этой поверхности (будем называть ее числовой составляющей (ЧС) Z-Buffer'а). Ось Z направлена в плоскость экрана (от тебя). Каждой точке сопоставлен единственный элемент ЧС. Перед началом рендеринга Z-буфер может быть заполнен в каждой точке значением равным максимально возможным расстоянием от наблюдателя до объекта сцены. После этого, для каждого полигона в сцене выполняются следующие действия:

a. определяется область, которую будет занимать полигон при проектировании на плоскость экрана

b. для каждого пикселя этой области сравнивается Z-координата точки-прообраза, принадлежащей исходному полигону, с соответствующим значением ЧС

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

Вот и весь принцип.

Далее в программе создается устройство рендеринга:

if (FAILED(g_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,  D3DCREATE_SOFTWARE_VERTEXPROCESSING, &p_p, &g_pD3DDevice))) {

if (FAILED(g_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_REF, hWnd,  D3DCREATE_SOFTWARE_VERTEXPROCESSING, &p_p, &g_pD3DDevice))) return FALSE;

}

Здесь программа пытается выбрать наиболее оптимальный режим для работы. Сначала она пробует создать аппаратное устройство рендеринга, т.е. когда все обсчеты графики ведет исключительно видеокарта (D3DDEVTYPE_HAL), но если это не удается (причин может быть много, но чаще всего она одна — старая видеокарта) D3D работает в режиме программной эмуляции, что прискорбно отражается на скорости и качестве графики. Едем дальше: Задается режим "выбраковки" тыльных сторон полигонов (подробней мы рассмотрим это дальше — в функции InitScene()):

g_pD3DDevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);

Включаем равномерное освещение всей сцены:

g_pD3DDevice->SetRenderState(D3DRS_LIGHTING, FALSE);

Включаем поддержку Z-Buffer'а

g_pD3DDevice->SetRenderState(D3DRS_ZENABLE, TRUE);

Может возникнуть вопрос, для чего может понадобиться отключение Z-Buffer'а. Одно из применений — вывод на экран текста, который должен перекрывать все остальное.

Хотелось бы также подробней рассказать про функцию SetRenderState() интерфейса IDirect3DDevice8, которую мы уже встречали ранее. Эта функция вообще незаменима, т.к. с ее помощью можно задать огромное количество различных настроек, влияющих на процесс рендеринга. Вот описание этой функции:

HRESULT SetRenderState(D3DRENDERSTATETYPE State, DWORD Value);

State — тип изменяемого параметра

Value — новое его значение

Функция InitTexture()

Эта функции выполняет только одно действие — загружает текстуру из файла в память для дальнейшего использования. Загрузка текстуры вручную заняла бы у нас довольно обширный кусок программного кода - этому будет посвящена отдельная статья. Поэтому, используем функцию D3DXCreateTextureFromFile(), которую программисты Microsoft написали за нас :) Префикс "D3DX-" этой функции, говорит о том, что она взята из библиотеки D3DX. Эта вспомогательная библиотека включает в себя очень много полезных функций, как для математических операций (в основном, работы с матрицами), так и для загрузки изображений, формирования стандартных геометрических объектов (сфера, куб и т.п.) и многого другого. Тем не менее, эти функции написаны для общих задач. Когда ты будешь писать конкретную программу, требующую быстродействия, советую не использовать D3DX, а писать аналоги его функций самому.

Вот описание функции D3DXCreateTextureFromFile():

HRESULT D3DXCreateTextureFromFile(LPDIRECT3DDEVICE8 pDevice, LPCSTR pSrcFile, LPDIRECT3DTEXTURE8* ppTexture);

pDevice — указатель на устройство рендеринга

pSrcFile — текстовая строка, содержащая путь к файлу-текстуре

ppTexture — адрес переменной, которая будет содержать указатель на текстуру

Функция InitScene()

Здесь происходит инициализация единственного объекта в сцене — четырехугольной пирамиды.

Как известно, в основании правильной четырехугольной пирамиды (SABCD) лежит квадрат (ABCD). Если сторона квадрата a, то высота пирамиды h=a/sqrt(2). Теперь, зная a, мы можем задать в трехмерном пространстве координаты всех пяти вершин пирамиды. В DirectX используется левосторонняя (left-handed) система координат (СК). Направление оси Z в левосторонней и правосторонней СК можно определить, пользуясь правилом соответственно левой и правой руки. Вот, как с помощью этого правила найти куда направлена ось Z в левосторонней СК: вытяни левую руку ладонью вверх и собери четыре пальца (все, кроме большого) вместе в плоскости ладони. Большой палец расположи перпендикулярно остальным четырем (тоже в плоскости ладони). Отлично! (Ты смог это! - прим. редактора ) Теперь, если направить ось X вдоль четырех пальцев, а ось Y - вверх, то большой палец укажет направление оси Z.

Координаты вершин пирамиды в пространстве можно записать следующим образом (не обращай пока внимание на последние 3 параметра каждой вершины):

float a=6.0;

#define vertA {-a/2, a/2, 0.0f, 0xffffffff, 0.0f, 1.0f,}

#define vertB {-a/2, -a/2, 0.0f, 0xffffffff, 0.0f, 0.0f,}

#define vertC {a/2, -a/2, 0.0f, 0xffffffff, 1.0f, 0.0f,}

#define vertD {a/2, a/2, 0.0f, 0xffffffff, 1.0f, 1.0f,}

#define vertS {0.0f, 0.0f, (float)(a/sqrt(2)), 0xffffffff, 0.5f, 0.5f,}

В D3D трехмерную модель можно задать различными способами. В нашем случае будем использовать TRIANGLELIST для которого фигура задается последовательностью треугольников. Когда задается треугольник, Direct3D сам определяет его лицевую и тыльную стороны по порядку следования вершин в массиве. При рендеринге, D3D автоматически "выбраковывает" тыльные стороны треугольников. Это заметно повышает скорость работы приложения. Но необходимо указать D3D в каком именно порядке задаются вершины лицевой стороны треугольников. Это делается с помощью той самой волшебной функции SetRenderState().

Итак, чтобы описать culling (выбраковку) тыльных сторон треугольников, вершины которых расположены в массиве по часовой стрелке (clockwise), необходимо написать следующее:

g_pD3DDevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);

Для хранения вершин в D3D используются Vertex Buffer'ы (в дальнейшем, VB. Не путать с Visual Basic'ом :)). В зависимости от конкретной программы, VB'ы могут быть разных форматов. Например, если требуется написать программу, которая рисует на экране набор одноцветных точек, то для задания любой из точек требуется три числа, содержащих ее координаты в пространстве. Если точки должны отличаться по цвету, вводим четвертый параметр — цвет точки. Вроде бы все просто… Единственная сложность — мы как-то должны "сообщить" D3D в каком именно формате хранятся вершины в массиве, чтобы в процессе рендеринга не возникло путаницы. Впервые это нужно сделать в момент создания VB, затем перед рендерингом. Формат задается в виде комбинации флагов D3DFVF_*, полный список которых приведен в документации к D3D8. Нам же понадобятся лишь 3 флага:

#define D3DFVF_MYVERTEX (D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1)

D3DFVF_XYZ — вершина задается тремя координатами в пространстве (а может задаваться и четырьмя — при D3DFVF_XYZRHW)

D3DFVF_DIFFUSE — вершина содержит цвет, который влияет на рассеяние света

D3DFVF_TEX1 -—вершина содержит две текстурные координаты

Т.к. запись

D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1

интерпретируется компилятором в точности, как и

D3DFVF_XYZ | D3DFVF_TEX1 | D3DFVF_DIFFUSE

значит порядок расположения данных в памяти в этом месте программы не задается. На программиста накладываются обязательства следовать схеме расположения данных, приведенной в руководстве D3D8 (раздел "About Vertex Formats").

Ну, надеюсь с этим все ясно. Теперь нужно занести вершины всех полигонов пирамиды в память. Для этого создаем массив из вершин и заполняем его данными:

MYVERTEX Vertices[] = {

vertS, vertA, vertD,

vertS, vertB, vertA,

vertS, vertC, vertB,

vertS, vertD, vertC,

};

Следующий шаг — нужно создать буфер вершин (VB) требуемого размера и формата. Пирамида будет отображена на экране так, что ее нижнего основания не будет видно, значит можно обойтись лишь 4-мя полигонами вместо 6-ти. Здесь я следовал правилу, которое прочитал в руководстве DX: "Remember, the fastest polygons are the ones you don't draw" (что в переводе означает: "Помни, наиболее быстрые полигоны — это те, которые ты не рисуешь"). Создание VB производится функцией CreateVertexBuffer:

HRESULT CreateVertexBuffer(UINT Length, DWORD Usage, DWORD FVF, D3DPOOL Pool, IDirect3DVertexBuffer8** ppVertexBuffer);

Length — длина VB в байтах

Usage — дополнительная информация о VB, которую D3D использует для создания оптимального VB

FVF — формат вершин, которые будут храниться в VB

Pool — в какой памяти создавать VB (можно создать его как в видеопамяти, так и в RAM)

ppVertexBuffer — адрес переменной, которая будет содержать указатель на созданный VB

Всего для хранения полигонов пирамиды используется 4*3*sizeof(MYVERTEX) байт (4 полигона, по 3 вершины в каждом).

if (FAILED(g_pD3DDevice->CreateVertexBuffer(4*3*sizeof(MYVERTEX), 0, D3DFVF_MYVERTEX, D3DPOOL_DEFAULT, &g_pVB))) {

return FALSE;

}

Остается заполнить буфер вершинами. Для операций заполнения в DX (не только в D3D) используется пара команд Lock() и Unlock(). Команда Lock() возвращает адрес памяти, по которому расположен первый байт буфера. При этом вся память, отведенная под буфер как бы "запирается", и становится недоступной для других приложений. Операция "отпирания" памяти производится командой Unlock(). После запирания памяти, скопируем данные с помощью Си'шной функции memcpy().

VOID* pVertices;

if (FAILED(g_pVB->Lock(0, sizeof(Vertices), (BYTE**)&pVertices, 0))) return FALSE;

memcpy(pVertices, Vertices, sizeof(Vertices));

g_pVB->Unlock();

Функция DoMatrices()

Я считаю, что это — самая сложная для понимания функция. Разговор о матрицах выходит за формат данной статьи, т.к. это очень обширная тема. Советую почитать статьи JM'а по этому поводу (скажу по секрету — он фанат матриц ;o)). Но вкратце, я все равно расскажу о матрицах :-)

У нас есть трехмерное пространство сцены, которое содержит вершины всех объектов, есть камера - глаз, с помощью которого мы видим это пространство, а также плоскость экрана монитора, на которую осуществляется проектирование. Все это ("мир", камера, операция проектирования) может быть выражено тремя матрицами: World Matrix (мировая матрица), View Matrix (видовая матрица) и Projection Matrix (проекционная матрица).

Вычислять эти матрицы "вручную" довольно сложно, поэтому воспользуемся функциями D3DX. Для матриц создан специальный тип данных D3DMATRIX. В библиотеке D3DX он расширен до типа данных D3DXMATRIX, в который добавлены арифметические операции с матрицами, и некоторые другие удобные свойства.

• Функция D3DXMatrixIdentity() строит единичную матрицу.

• Функция D3DXMatrixRotationZ() строит матрицу вращения относительно оси Z на заданный угол.

• Функция D3DXMatrixLookAtLH() строит видовую матрицу. Параметры этой функции задают точку, в которую будет смотреть камера. Постфикс -(LH) говорит о том, что матрица будет действительна для левосторонней системы координат (аналогично -(RH) для правосторонней)

• Функция D3DXMatrixPerspectiveFovLH() строит проекционную матрицу.

Для того, чтобы "заставить" устройство рендеринга использовать только что созданные нами матрицы, существует функция SetTransform():

HRESULT SetTransform(D3DTRANSFORMSTATETYPE State, CONST D3DMATRIX* pMatrix);

State — тип матрицы, которую нужно изменить (мировая, видовая, проекционная и т.д.)

pMatrix — указатель на "матрицу-заменитель" :)

Вот что нам требуется от каждой из матриц:

a. Мировая

Сделаем так, чтобы пирамида с течением времени равномерно вращалась вокруг оси Z:

D3DXMATRIX matWorld;

D3DXMatrixIdentity(&matWorld);

D3DXMatrixRotationZ(&matWorld, GetTickCount()/1024.0f);

g_pD3DDevice->SetTransform(D3DTS_WORLD, &matWorld);

b. Видовая

Камера должна смотреть на пирамиду сбоку, причем не должно быть видно нижнего основания пирамиды (помнишь, мы выбросили два полигона основания?):

D3DXMATRIX matView;

D3DXMatrixLookAtLH(&matView, &D3DXVECTOR3(5.0f, 5.0f, 6.5f), &D3DXVECTOR3(0.0f, 0.0f, 1.0f), &D3DXVECTOR3(0.0f, 0.0f, 1.0f));

g_pD3DDevice->SetTransform(D3DTS_VIEW, &matView);

c. Проекционная

D3DXMATRIX matProj;

D3DXMatrixPerspectiveFovLH(&matProj, D3DX_PI/3, 1.0f, 1.0f, 100.0f);

g_pD3DDevice->SetTransform(D3DTS_PROJECTION, &matProj);

Здесь D3DX_PI/3 - это поле зрения (field of view) камеры. Попробуй поэкспериментировать с этим параметром.

Функция RenderScene()

Собственно, здесь и происходит рендеринг сцены. Как всегда, он начинается с очистки окна и Z-Buffer'а:

g_pD3DDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(100, 100, 100), 1.0f, 0);

Затем, подготавливаем D3D к началу сцены.

g_pD3DDevice->BeginScene();

Пересчитываем матрицы:

DoMatrices();

Теперь настроим текстуру. И вообще, здесь подходящее место для того, чтобы вкратце рассказать о том, что такое текстура и текстурные координаты! Итак… Текстура — это графическая картинка, которая используется для натягивания на трехмерный (и не только) объект, что придает ему реалистичный вид (правда, это зависит от текстуры и от того, кто и на что ее натягивает :)) ). При текстурировании объекта, каждая его вершина должна иметь текстурные координаты, т.е. числа от 0 до 1, задающие привязку к конкретному месту текстуры. Рассмотрим пример, т.е. нашу четырехугольную пирамиду. Она была выбрана не случайно именно четырехугольной! Представь себе квадратный (для простоты), очень эластичный лист резины, на котором изображена каменная стена (текстура). Теперь "схвати" его за центр и тяни вверх (при этом края квадрата должны оставаться на месте). Т.к. лист эластичный, он легко поддастся и начнет растягиваться. Вместе с ним будет растягиваться и изображение стены. Тяни до тех пор, пока лист не превратится в правильную четырехугольную пирамиду без нижнего основания. Заморозь полученный объект, чтобы он не вернулся в первоначальное положение. Все! Еще раз вернемся к месту, где задаются вершины пирамиды:

float a=6.0;

#define vertA {-a/2,  a/2, 0.0f, 0xffffffff,  0.0f, 1.0f,}

#define vertB {-a/2, -a/2, 0.0f, 0xffffffff, 0.0f, 0.0f,}

#define vertC {a/2, -a/2, 0.0f, 0xffffffff,  1.0f, 0.0f,}

#define vertD {a/2, a/2, 0.0f, 0xffffffff,  1.0f, 1.0f,}

#define vertS {0.0f, 0.0f, (float)(a/sqrt(2)), 0xffffffff, 0.5f, 0.5f,}

0xffffffff (белый цвет) — цветовой "вес" вершины. Белый цвет означает, что текстура в данной вершине будет того же цвета и яркости, что и в оригинале. Если заменить цвет на 0x00000000, то вершина будет черной и при рендеринге вокруг нее образуется черное пятно. Попробуй! =)

Последние два числа являются текстурными координатами. Вернемся к мысленному эксперименту с квадратным листом… (до того, как мы его деформировали) Возьмем его левый верхний угол за начало координат. Ось X направим вправо, ось Y — вниз. Тогда правый нижний угол будет иметь координаты (1, 1). Как ты уже догадался, центр квадрата (проекция вершины S пирамиды на плоскость основания) имеет координаты (0.5, 0.5). Вот так задаются текстурные координаты.

Вернемся к программе. У нас будет одноуровневая текстура, первым и единственным уровнем которой будет загруженная ранее g_pTexture:

g_pD3DDevice->SetTexture(0, g_pTexture);

При рендеринге на текстуры могут накладываться фильтры, что сглаживает многие недостатки. Изюминкой программы является то, что тип фильтра можно менять прямо во время исполнения (клавишами F1, F2, F3, F4). Кроме того, как я обещал в начале статьи, используем MipMapping! Но для начала расскажу, что он собой представляет…

MipMap - это цепочка текстур, каждая последующая из которых является менее детализированным вариантом предыдущей. Уменьшение детализации на один уровень достигается путем сокращения длины и ширины текстуры в два раза. Цепочка генерируется до тех пор, пока размер одной из сторон текстуры не становится равным 1. Допустим, что текстурированный объект удаляется от наблюдателя. Сначала на него накладывается текстура с максимальным разрешением, затем, по мере удаления, текстура переключается на свой менее детализированный вариант. Согласись, на далекий объект, который занимает на экране всего один пиксель, глупо натягивать текстуру размером 100 Kb. Таким образом, благодаря некоторым дополнительным затратам памяти на MipMap-текстуры, заметно увеличивается быстродействие рендеринга и, вообще говоря, его качество. Во время переключения между детализациями, визуально может быть заметен скачок. Его можно сгладить, используя фильтрацию, что мы и сделаем (напомню, что текущий тип фильтра хранится в переменной CurrentFilter):

g_pD3DDevice->SetTextureStageState(0, D3DTSS_MAGFILTER, CurrentFilter);

g_pD3DDevice->SetTextureStageState(0, D3DTSS_MINFILTER, CurrentFilter);

g_pD3DDevice->SetTextureStageState(0, D3DTSS_MIPFILTER, CurrentFilter);

Перед рендерингом из VB, необходимо задать сам буфер и формат вершин, что делается следующими двумя строками:

g_pD3DDevice->SetStreamSource(0, g_pVB, sizeof(MYVERTEX));

g_pD3DDevice->SetVertexShader(D3DFVF_MYVERTEX);

И, наконец! Все готово для рендеринга! Делается это всего одной функцией DrawPrimitive(). Первый параметр говорит о том, в каком виде хранятся в VB вершины. В нашем случае, объект задается последовательностью треугольников (D3DPT_TRIANGLELIST). Второй параметр говорит о том, с какой по номеру вершины из VB начинать отрисовку. Третий параметр — количество примитивов (в нашем случае треугольников), которые требуется отрендерить.

g_pD3DDevice->DrawPrimitive(D3DPT_TRIANGLELIST, 0, 4);

Завершаем сцену:

g_pD3DDevice->EndScene();

Отображаем бэк-буфер на экране:

g_pD3DDevice->Present(NULL, NULL, NULL, NULL);

Функция Deinitialization()

Для освобождения большинства (если не всех) видов ресурсов в D3D используется функция Release():

if (g_pTexture != NULL) g_pTexture->Release();

if (g_pVB != NULL) g_pVB->Release();

if (g_pD3DDevice != NULL) g_pD3DDevice->Release();

if (g_pD3D != NULL) g_pD3D->Release();

Также, перед завершением работы нужно освободить ранее зарегистрированный класс окна:

UnregisterClass("PyramidClass", wclass.hInstance);

Функция MessageProc()

Программа будет обрабатывать только два типа сообщений: WM_KEYDOWN (нажата клавиша) и WM_DESTROY (уничтожено окно приложения).

При поступлении сообщения WM_KEYDOWN получаем виртуальный код нажатой клавиши:

case WM_KEYDOWN:

int VK;

VK = (int)wParam;

Из клавиш, обрабатываем только Esc, F1, F2, F3, F4. При нажатии на Esc программа должна завершиться, как ни парадоксально это звучит :)) Если нажата клавиша F1-F4, должен смениться тип фильтра (переменная CurrentFilter) и заголовок окна:

switch(VK) {

case VK_ESCAPE:

PostQuitMessage(0);

return 0;

//...

case VK_F2:

CurrentFilter = D3DTEXF_POINT;

SetWindowText(hWnd, "D3D Pyramid (Filter=D3DTEXF_POINT)");

break;

//...

}

При поступлении сообщения WM_DESTROY, выполняются действия, аналогичные производящимся при обработке клавиши Esc:

case WM_DESTROY:

PostQuitMessage(0);

return 0;

Приехали! В принципе, вышеизложенного материала достаточно для самостоятельного написания простых 3D-приложений (для написания игры необходимо, как минимум, уметь работать с матрицами). Рекомендую поэкспериментировать с примером к данной статье. Попробуй поиграть настройками D3D, параметрами функций. Дай волю своему воображению! И, конечно же, попытайся написать что-нибудь сам (например, вращающийся треугольник или куб). Только так можно научиться. Накапливай опыт…

Удачи!

Примечания:

1. Помни, что для компиляции программ, использующих D3DX, необходимо подключить библиотечный файл d3dx8.lib (вместе с d3d8.lib)! Еще раз напомню, как это можно сделать:

a. Project->Settings…

b. Вкладка "Link"

c. В строке "Object/library modules" добавь в начало "d3d8.lib d3dx8.lib"

d. Должно получиться примерно следующее: "d3d8.lib d3dx8.lib kernel32.lib user32.lib gdi32.lib…"

2. Программе необходим файл texture.jpg — он должен лежать в той же директории, что и exe'шник.

Полезные статьи:

Автор: voxatu.

Первые шаги под DirectX 8. (Часть 1)

Автор: Сергей Ваткин.

Первым делом вам нужно убедиться, что на вашей машине установлен компилятор C++ и DirectX8 SDK. Если у вас нет DirectX8 SDK, его можно скачать с сайта Microsoft, учтите только, что скачиваемый файл занимает примерно 140 Мб.

Дальше необходимо немного подстроить вашу среду разработки, а именно указать рабочие пути к DirectX, то есть к заголовочным файлам (.h — файлам) и файлам статических библиотек (.lib). Например, В Visual C++ это делается следующим образом. Меню Tools/Options вызывает диалоговое окно Options. В нем выбираем закладку Directories и выбираем из списка Show directories for сперва Include files для пути к заголовочным файлам, затем добавляем путь (папка Include в каталоге, куда установлен DirectX SDK) и выставляем его, нажимая на иконку "стрелочка вверх", в первую позицию. Аналогично и для пути к библиотечным файлам, выбираем из списка Show directories for пункт Library files и добавляем путь к библиотечным файлам (директория LIB в каталоге DirectX SDK).

Теперь попробуем написать простейшую программу, инициализирующую DirectX. Для этого познакомимся с некоторыми интерфейсами Direct3D и их методами.

Для создания объекта d3d используется функция Direct3DCreate8():

pD3D = Direct3DCreate8(D3D_SDK_VERSION);

здесь pD3D — указатель на интерфейс IDirect3D8, D3D_SDK_VERSION объявлено в d3d8.h.

Файл d3d8.h содержит объявления функций, работающих с Direct3D. Поэтому его необходимо включить в свой код директивой препроцессора:

#include <d3d8.h>

Функция Direct3DCreate8() возвращает указатель на созданный объект d3d. Если она вернула значение NULL, то это означает, что ваша программа не может инициализировать DirectX8. В этом случае ваша программа должна закончить своё выполнение.

Компонент, который занимается просчётом объектов на экран в Direct3D, называется Direct3D device. Он также включает в себя и сохраняет установки, касающиеся просчёта, занимается операциями трансформации, освещения и растеризацией. Метод CreateDevice() интерфейса объекта d3d создаёт такой device. Одним из параметров этого метода является объект структурного типа D3DPRESENT_PARAMETERS. Для ознакомления с Direct3D, мы не будем углубляться в значения всех полей этой структуры. Скажем только про те, которые нам сейчас понадобятся. Поле Windowed отвечает за то, будет ли графика отображаться на весь экран или в окне; значение может быть соответственно FALSE или TRUE.

Чтобы не было видно, как перерисовывается графика, все отображаемые объекты выводят сперва в невидимой области видеопамяти, так называемой back buffer (задний буфер). После того, как кадр полностью прорисован, его копируют в видимую область памяти — front buffer или render target. Если приложение отображает графику на весь экран, то в копировании нет необходимости, достаточно просто говорить Direct3D какая часть видеопамяти является видимой, то есть просто переключать (flip) видимость с одного буфера на другой. Ясно, что если мы выводим графику в окно, то мы можем пользоваться только копированием back buffer'а в front buffer. Поле SwapEffect мы выставим в значение d3dswapeffect_discard чтобы наиболее эффективно представить back buffer для отображения.

BackBufferFormat — ещё одно поле структуры D3DPRESENT_PARAMETERS, которое нам необходимо задать, чтобы сказать Direct3D, какого формата будет back buffer. Пусть наше приложение, для простоты, будет выводить графику в окно. Формат back buffer'а должен совпадать с форматом front buffer'а, который в свою очередь в нашем случае совпадает с текущим форматом desktop'а. Его же мы можем получить методом интерфейса объекта d3d GetAdapterDisplayMode(), указав в качестве первого параметра D3DADAPTER_DEFAULT.

Итак, мы можем уже написать функцию инициализации Direct3D для последующего просчёта объектов:

// функция Init создаёт объекты d3d и d3d device

bool Init(HWND hWnd) {

if (pD3d = Direct3DCreate8(D3D_SDK_VERSION)) {

D3DDISPLAYMODE d3ddm; // отсюда нам нужно поле Format

if (FAILED(pD3d->GetAdapterDisplayMode(D3DADAPTER_DEFAULT, &d3ddm)))

return false;

D3DPRESENT_PARAMETERS d3dpp;

ZeroMemory(&d3dpp, sizeof(d3dpp)); // выставляем в 0 все поля d3dpp

d3dpp.Windowed = TRUE;

d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;

d3dpp.BackBufferFormat = d3ddm.Format;

if (FAILED(pD3d->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pDevice))) {

return false;

}

return true;

}

returnfalse;

}

Здесь pD3d — объект d3d, объявленный как

IDirect3D8 * pD3d;

а pDevice — указатель на интерфейс device'а

IDirect3DDevice8 * pDevice;

В методе CreateDevice() вторым параметром мы задали D3DDEVTYPE_HAL. Это означает, что мы пытаемся создать устройство просчёта, поддерживаемое hardware.

Таким образом, если наша функция Init() вернула значение true, означает, что инициализация прошла успешно. После этого мы можем выводить графику средствами DirectX. Об этом мы поговорим во второй части урока. Единственное, что осталось добавить к выше сказанному, раз уж мы научились создавать объекты, нужно не забывать их удалять. Объекты DirectX являются обычными COM объектами. После того, как мы закончили ими пользоваться, необходимо вызвать методы Release(), для каждого из этих объектов:

// функция ReleaseAll освобождает объекты d3d device и d3d

void ReleaseAll() {

// Освобождаются в обратном порядке создания

if (pDevice) pDevice->Release();

if (pD3d) pD3d->Release();

}

Поведал: Ваткин.

Первые шаги под DirectX 8. (Часть 2)

Автор: Сергей Ваткин.

Попробуем вывести простейший объект в нашем приложении. Любой трехмерный объект, который может вывести DirectX, является полигональной моделью. То есть любой объект состоит из некоторого количества треугольников. Треугольники задаются своими вершинами. Вершины, в свою очередь, могут иметь какие-то координаты, цвет, текстурные координаты и т.д. Вершины могут быть разных типов, например, если мы не используем текстурирование, зачем нам задавать текстурные координаты. Зададим самый простой формат вершины. У вершины такого формата будут координаты положения в трёхмерном пространстве и цвет:

#define D3DFVF_MYVERT (D3DFVF_XYZ | D3DFVF_DIFFUSE)

Структура данных для такой вершины будет выглядеть следующим образом:

struct MyVert{

float x, y, z; // координаты

DWORD Color; // диффузный цвет

};

Цвет вершины задаётся 32-х битовым целым числом. Для установки нужного цвета можно использовать макроподстановку D3DCOLOR_XRGB(r,g,b), где r,g и b — составляющие компоненты цвета, соответственно красная, зелёная и синяя, могут принимать целые значения от 0 до 255-ти.

При помощи device вы управляете просчётом, то есть выводом графики. Чтобы заполнить каким-либо цветом, например, синим, всю область просчёта, можно воспользоваться методом Clear():

DWORD dwBlue = D3DCOLOR_XRGB(0, 0, 128);

pDevice->Clear(0, NULL, D3DCLEAR_TARGET, dwBlue, 1.0f, 0);

Перед тем, как вывести объекты, нужно предупредить DirectX об этом специальным вызовом:

pDevice->BeginScene();

После того, как вы закончили посылать объекты на просчет, вызывайте ещё один специальный метод:

pDevice->EndScene();

То есть прорисовка всех объектов происходит между вызовами этих методов. Об этом нужно помнить, если вы попытаетесь вывести объект вне этого блока, то DirectX просто проигнорирует вас.

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

pDevice->SetVertexShader(D3DFVF_MYVERT);

Это необходимо для того, чтобы DirectX знал, как расположена информация о вершине в структуре MyVert и каким способом он будет выводить объекты.

Треугольник задаётся последовательностью вершин, как линейный (одномерный) массив. Для одного треугольника нам понадобится три вершины:

MyVert v[3];

//Зададим расположение для вершин:

v[0].x =-0.5f; v[0].y =-0.5f; v[0].z = 0.5f;

v[1].x =-0.5f; v[1].y = 0.5f; v[1].z = 0.5f;

v[2].x = 0.5f; v[2].y = 0.5f; v[2].z = 0.5f;

//и цвет:

v[0].Color = D3DCOLOR_XRGB(255,0,0); // красный

v[1].Color = D3DCOLOR_XRGB(0,255,0); // зеленый

v[2].Color = D3DCOLOR_XRGB(0,0,255); // синий

Выводом объектов занимаются семейство методов DrawPrimitive интрефейса IDirect3DDevice8. Примитивом здесь называется минимальный объект, который может быть выведен таким методом, например, треугольник здесь тоже является примитивом. В нашем случае мы воспользуемся методом DrawPrimitiveUP():

pDevice->DrawPrimitiveUP( D3DPT_TRIANGLELIST, 1, v, sizeof(MyVert));

Первым параметром задаётся тип примитивов, второй отвечает за количество примитивов, третий является указателем на область в памяти, где расположена информация о вершинах, в нашем случае мы указываем наш массив, последний параметр — размер шага в байтах, с которым идут вершины одна за другой, у нас элементы массива лежат "плотно", поэтому шагом является размер, занимаемый данными одной вершины, то есть размер структуры MyVert.

Поскольку всё отображение ведется в невидимую часть экрана, мы должны показать все это на экране. Этим занимается метод Present(). Для нашего примера параметры этой функции нас не интересуют, выставляем их в 0:

pDevice->Present(0, 0, 0, 0);

Этот метод вызывается, когда вы отобразили все объекты, участвующие в текущем кадре, в текущей сцене, то есть после метода EndScene().

В итоге мы построили функцию Render(), которая и будет выводить наш треугольник на экран:

void Render() {

// Инициализацию массива v можно вынести за пределы

// функции Render()

MyVert v[3];

v[0].x =-0.5f;  v[0].y =-0.5f;  v[0].z = 0.5f;

v[1].x =-0.5f;  v[1].y = 0.5f;  v[1].z = 0.5f;

v[2].x = 0.5f;  v[2].y = 0.5f;  v[2].z = 0.5f;

v[0].Color = D3DCOLOR_XRGB(255,0,0); // красный

v[1].Color = D3DCOLOR_XRGB(0,255,0); // зеленый

v[2].Color = D3DCOLOR_XRGB(0,0,255); // синий

// Закрашиваем экран синим цветом

DWORD dwBlue = D3DCOLOR_XRGB(0,0,128);

pDevice->Clear(0, NULL, D3DCLEAR_TARGET, dwBlue, 1.0f, 0);

pDevice->BeginScene();

// Поскольку мы не используем освещение для треугольника,

// отключаем его

pDevice->SetRenderState(D3DRS_LIGHTING, FALSE);

// Просчет объектов всегда между BeginScene и EndScene

pDevice->SetVertexShader(D3DFVF_MYVERT);

pDevice->DrawPrimitiveUP(D3DPT_TRIANGLELIST, 1, v, sizeof(MyVert));

pDevice->EndScene();

pDevice->Present(0, 0, 0, 0);

}

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

Ниже приведён код, который больше относится к windows-программированию. Создаётся главное окно приложения и ведётся обработка сообщений:

// функция обрабатывающая сообщения главного окна приложения

LRESULT WINAPI MsgProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {

switch (msg) {

case WM_DESTROY:

PostQuitMessage(0);

return 0;

}

return DefWindowProc(hWnd, msg, wParam, lParam);

}

INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, INT) {

WNDCLASSEX wc = {

sizeof(WNDCLASSEX), CS_CLASSDC, MsgProc, 0L, 0L,

GetModuleHandle(0), 0, 0, 0, 0, "FirstDX_cl", 0

};

RegisterClassEx(&wc);

// Создание главного окна приложения

HWND hWnd = CreateWindow("FirstDX_cl", "FirstDX",

WS_OVERLAPPEDWINDOW, 100, 100, 160, 160,

GetDesktopWindow(), NULL, wc.hInstance, NULL);

if (Init(hWnd)) {

ShowWindow (hWnd, SW_SHOWDEFAULT);

UpdateWindow(hWnd);

MSG msg;

ZeroMemory(&msg, sizeof(msg));

while (msg.message != WM_QUIT) {

if (PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE)) {

TranslateMessage(&msg);

DispatchMessage(&msg);

} else Render();

}

}

ReleaseAll();

UnregisterClass("FirstDX_cl", wc.hInstance);

return 0;

}

Функция Render() вызывается всегда, когда не приходят какие-либо сообщения, то есть перерисовка кадра происходит практически постоянно. Функции Init() и ReleaseAll() описаны в предыдущей части урока.

Теперь есть всё, чтобы вы смогли скомпилировать и запустить наш пример. Не забудьте добавить библиотеку d3d8.lib в ваш проект, чтобы линковщик смог найти реализации функций Direct3D.

Поведал: Ваткин.

GameDev.net

2D Rendering in DirectX 8

by Kelly Dempski

Background

I have been reading alot of questions lately related to DirectX 8 and the exclusion of DirectDraw from the new API. Many people have fallen back to DX7. I can understand people using DX7 if they have alot of experience with that API, but many of the questions seem to be coming from people who are just learning DX, and they are stuck learning an old API. People have argued that many people don't have 3D hardware, and therefore D3D would be a bad alternative for DirectDraw. I don't believe this is true - 2D rendering in D3D requires very little vertex manipulation, and everything else boils down to fillrate. In short, 2D rendering in D3D on 2D hardware should have pretty much the same performance as DirectDraw, assuming decent fillrate. The advantage is that the programmer can learn the newest API, and performance on newer hardware should be very good. This article will present a framework for 2D rendering in DX8 to ease the transition from DirectDraw to Direct3D. In each section, you may see things that you don't like ("I'm a 2D programmer, I don't care about vertices!"). Rest assured, if you implement this simple framework once, you'll never think about these things again.

Getting Started

Assuming you have the DX8 SDK, there are a couple tutorials that present how to create a D3D device and set up a render loop, so I don't want to spend alot of time on that. For the purposes of this article, I'll talk about the tutorial found in [DX8SDK]\samples\Multimedia\Direct3D\Tutorials\Tut01_CreateDevice, although you can add it to anything. To that sample, I'll add the following functions:

void PostInitialize(float WindowWidth, float WindowHeight) — this function is called by the app after everything else is set up. You've created your device and initialized everything. If you're following along with the Tutorial code, WinMain looks like this:

…

if (SUCCEEDED(InitD3D(hWnd))) {

PostInitialize(200.0f, 200.0f);

// This is my added line. The values of

// 200.0f were chosen based on the sizes

// used in the call to CreateWindow.

ShowWindow(hWnd, SW_SHOWDEFAULT);

…

void Render2D() — This function is called each time you want to render your scene. Again, the Render function of the Tutorial now looks like this:

VOID Render() {

if (NULL == g_pd3dDevice) return;

// Clear the backbuffer to a blue color

g_pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0,0,255), 1.0f, 0);

// Begin the scene

g_pd3dDevice->BeginScene();

Render2D(); //My added line…

// End the scene

g_pd3dDevice->EndScene();

// Present the backbuffer contents to the display

g_pd3dDevice->Present(NULL, NULL, NULL, NULL);

}

OK, that's our shell of an application. Now for the good stuff…

Setting Up for 2D drawing in D3D

NOTE: This is where we start talking about some of the nasty math involved with D3D. Don't be alarmed - if you want to, you can choose to ignore most of the detailsЕ Most Direct3D drawing is controlled by three matrices: the projection matrix, the world matrix, and the view matrix. The first one we'll talk about is the projection matrix. You can think of the projection matrix as defining the properties of the lens of your camera. In 3D applications, it defines things like perspective, etc. But, we don't want perspective - we are talking about 2D!! So, we can talk about orthogonal projections. To make a long story very short, this allows us to draw in 2D without all the added properties of 3D drawing. To create an orthogonal matrix, we need to call D3DXMatrixOrthoLH and this will create a matrix for us. The other matrices (view and world) define the position of the camera and the position of the world (or an object in the world). For our 2D drawing, we don't need to move the camera, and we don't want to move the world for now, so we'll use an identity matrix, which basically sets the camera and world in a default position. We can create identity matrices with D3DXMatrixIdentity. To use the D3DX functions, we need to add:

#include <d3dx8.h>

and add d3dx8dt.lib to the list of linked libraries. Once that was set up, the PostInitialize function now looks like this:

void PostInitialize(float WindowWidth, float WindowHeight) {

D3DXMATRIX Ortho2D;

D3DXMATRIX Identity;

D3DXMatrixOrthoLH(&Ortho2D, WindowWidth, WindowHeight, 0.0f, 1.0f);

D3DXMatrixIdentity(&Identity);

g_pd3dDevice->SetTransform(D3DTS_PROJECTION, &Ortho2D);

g_pd3dDevice->SetTransform(D3DTS_WORLD, &Identity);

g_pd3dDevice->SetTransform(D3DTS_VIEW, &Identity);

}

We are now set up for 2D drawing, now we need something to draw. The way things are set up, our drawing area goes from —WindowWidth/2 to WindowWidth/2 and -WindowHeight/2 to WindowHeight/2. One thing to note, in this code, the width and the height are being specified in pixels. This allows us to think about everything in terms of pixels, but we could have set the width and height to say 1.0 and that would have allowed us to specify sizes, etc. in terms of percentages of the screen space, which would be nice for supporting multiple resolutions easily. Changing the matrix allows for all sorts of neat things, but for simplicity, we'll talk about pixels for nowЕ Setting Up a 2D "Panel"

When I draw in 2D, I have a class called CDX8Panel that encapsulates everything I need to draw a 2D rectangle. For simplicity, and it avoid a C++ explanation, I have pulled out the code here. However, as we build up our code to draw a panel, you'll probably see the value of such a class or higher level API if you don't use C++. Also, we are about to recreate much that goes on in the ID3DXSprite interface. I'm explaining the basics here to show the way things work, but you may want to use the sprite interface if it suits your needs.

My definition of a panel is simply a 2D textured rectangle that we are going to draw on the screen. Drawing a panel will be extremely similar to a 2D blit. Experienced 2D programmers may think that this is a lot of work for a blit, but that work pays off with the amount of special effects that it enables. First, we have to think about the geometry of our rectangle. This involves thinking about vertices. If you have 3D hardware, the hardware will process these vertices extremely quickly. If you have 2D hardware, we are talking about so few vertices that they will be processed very quickly by the CPU. First, let's define our vertex format. Place the following code near the #includes:

struct PANELVERTEX {

FLOAT x, y, z;

DWORD color;

FLOAT u, v;

};

#define D3DFVF_PANELVERTEX (D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1)

This structure and Flexible Vertex Format (FVF) specify that we are talking about a vertex that has a position, a color, and a set of texture coordinates.

Now we need a vertex buffer. Add the following line of code to the list of globals. Again, for simplicity, I'm making it global — this is not a demonstration of good coding practice.

LPDIRECT3DVERTEXBUFFER8 g_pVertices = NULL;

Now, add the following lines of code to the PostInitialize function (explanation to follow):

float PanelWidth = 50.0f;

float PanelHeight = 100.0f;

g_pd3dDevice->CreateVertexBuffer(4 * sizeof(PANELVERTEX), D3DUSAGE_WRITEONLY,

D3DFVF_PANELVERTEX, D3DPOOL_MANAGED, &g_pVertices);

PANELVERTEX* pVertices = NULL;

g_pVertices->Lock(0, 4 * sizeof(PANELVERTEX), (BYTE**)&pVertices, 0);

//Set all the colors to white

pVertices[0].color = pVertices[1].color = pVertices[2].color = pVertices[3].color = 0xffffffff;

//Set positions and texture coordinates

pVertices[0].x = pVertices[3].x = -PanelWidth / 2.0f;

pVertices[1].x = pVertices[2].x = PanelWidth / 2.0f;

pVertices[0].y = pVertices[1].y = PanelHeight / 2.0f;

pVertices[2].y = pVertices[3].y = -PanelHeight / 2.0f;

pVertices[0].z = pVertices[1].z = pVertices[2].z = pVertices[3].z = 1.0f;

pVertices[1].u = pVertices[2].u = 1.0f;

pVertices[0].u = pVertices[3].u = 0.0f;

pVertices[0].v = pVertices[1].v = 0.0f;

pVertices[2].v = pVertices[3].v = 1.0f;

g_pVertices->Unlock();

This is actually much simpler than it may look. First, I made up a size for the panel just so we'd have something to work with. Next, I asked the device to create a vertex buffer that contained enough memory for four vertices of my format. Then I locked the buffer so I could set the values. One thing to note, locking buffers is very expensive, so I'm only going to do it once. We can manipulate the vertices without locking, but we'll discuss that later. For this example I have set the four points centered on the (0, 0). Keep this in the back of your mind; it will have ramifications later. Also, I set the texture coordinates. The SDK explains these pretty well, so I won't get into that. The short story is that we are set up to draw the entire texture. So, now we have a rectangle set up. The next step is to draw it…

Drawing the Panel

Drawing the rectangle is pretty easy. Add the following lines of code to your Render2D function:

g_pd3dDevice->SetVertexShader(D3DFVF_PANELVERTEX);

g_pd3dDevice->SetStreamSource(0, g_pVertices, sizeof(PANELVERTEX));

g_pd3dDevice->DrawPrimitive(D3DPT_TRIANGLEFAN, 0, 2);

These lines tell the device how the vertices are formatted, which vertices to use, and how to use them. I have chosen to draw this as a triangle fan, because it's more compact than drawing two triangles. Note that since we are not dealing with other vertex formats or other vertex buffers, we could have moved the first two lines to our PostInitialize function. I put them here to stress that you have to tell the device what it's dealing with. If you don't, it may assume that the vertices are a different format and cause a crash. At this point, you can compile and run the code. If everything is correct, you should see a black rectangle on a blue background. This isn't quite right because we set the vertex colors to white. The problem is that the device has lighting enabled, which we don't need. Turn lighting off by adding this line to the PostInitialize function:

g_pd3dDevice->SetRenderState(D3DRS_LIGHTING, FALSE);

Now, recompile and the device will use the vertex colors. If you'd like, you can change the vertex colors and see the effect. So far, so good, but a game that features a white rectangle is visually boring, and we haven't gotten to the idea of blitting a bitmap yet. So, we have to add a texture. Texturing the Panel

A texture is basically a bitmap that can be loaded from a file or generated from data. For simplicity, we'll just use files. Add the following to your global variables:

LPDIRECT3DTEXTURE8 g_pTexture = NULL;

This is the texture object we'll be using. To load a texture from a file, add this line to PostInitialize:

D3DXCreateTextureFromFileEx(g_pd3dDevice, [Some Image File], 0, 0, 0, 0,

D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, D3DX_DEFAULT,

D3DX_DEFAULT , 0, NULL, NULL, &g_pTexture);

Replace [Some Image File] with a file of your choice. The D3DX function can load many standard formats. The pixel format we're using has an alpha channel, so we could load a format that has an alpha channel such as .dds. Also, I'm ignoring the ColorKey parameter, but you could specify a color key for transparency. I'll get back to transparency in a little bit. For now, we have a texture and we've loaded an image. Now we have to tell the device to use it. Add the following line to the beginning of Render2D:

g_pd3dDevice->SetTexture(0, g_pTexture);

This tells the device to render the triangles using the texture. One important thing to remember here is that I am not adding error checking for simplicity. You should probably add error checking to make sure the texture is actually loaded before attempting to use it. One possible error is that for a lot of hardware, the textures must have dimensions that are powers of 2 such as 64×64, 128×512, etc. This constraint is no longer true on the latest nVidia hardware, but to be safe, use powers of 2. This limitation bothers a lot of people, so I'll tell you how to work around it in a moment. For now, compile and run and you should see your image mapped onto the rectangle.

Texture Coordinates

Note that it is stretched/squashed to fit the rectangle. You can adjust that by adjusting the texture coordinates. For example, if you change the lines where u = 1.0 to u = 0.5, then only half of the texture is used and the remaining part will not be squashed. So, if you had a 640x480 image that you wanted to place on a 640×480 window, you could place the 640×480 image in a 1024×512 texture and specify 0.625, 0.9375 for the texture coordinates. You could use the remaining parts of the texture to hold other sub images that are mapped to other panels (through the appropriate texture coordinates). In general, you want to optimize the way textures are used because they are eating up graphics memory and/or moving across the bus. This may seem like a lot of work for a blit, but it has a lot to do with the way new cards are optimized for 3D (like it or not). Besides, putting some thought into how you are moving large chunks of memory around the system is never a bad idea. But I'll get off my soapbox.

Let's see where we are so far. At one level, we've written a lot of code to blit a simple bitmap. But, hopefully you can see some of the benefit and the opportunities for tweaking. For instance, the texture coordinates automatically scale the image to the area we've defined by the geometry. There are lots of things this does for us, but consider the following. If we had set up our ortho matrix to use a percentage based mapping, and we specified a panel as occupying the lower quarter of the screen (for a UI, let's say), and we specified a texture with the correct texture coordinates, then our UI would automagically be drawn correctly for any chosen window/screen size. Not exactly cold fusion, but it's one of many examples. Now that we have the texture working well, we have to get back to talking about transparency.

Transparency

As I said before, one easy way of adding transparency is to specify a color key value in the call to D3DXCreateTextureFromFileEx. Another is to use an image that actually has an alpha channel. Either way, specify a texture with some transparency (either with an alpha channel or a color key value) and run the app. You should see no difference. This is because alpha blending is not enabled. To enable alpha blending, add these lines to PostInitialize:

g_pd3dDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE);

g_pd3dDevice->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA);

g_pd3dDevice->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);

g_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_MODULATE);

The first line enables blending. The next two specify how the blending works. There are many possibilities, but this is the most basic type. The last line sets things up so that changing the alpha component of the vertex colors will fade the entire panel by scaling the texture values. For a more in depth discussion of the available settings, see the SDK. Once these lines are in place, you should see the proper transparency. Try changing the colors of the vertices to see how they affect the panel.

Moving the Panel

By now our panel has many of the visual properties we need, but it's still stuck in the center of our viewport. For a game, you probably want things to move. One obvious way is to relock the vertices and change their positions. DO NOT do this!! Locking is very expensive, involves moving data around, and is unnecessary. A better way is to specify a world transformation matrix to move the points. For many people, matrices may seem a bit scary, but there are a host of D3DX functions that make matrices very easy. For example, to move the panel, add the following code to the beginning of Render2D:

D3DXMATRIX Position;

D3DXMatrixTranslation(&Position, 50.0f, 0.0f, 0.0f);

g_pd3dDevice->SetTransform(D3DTS_WORLD, &Position);

This creates a matrix that moves the panel 50 pixels in the X direction and tells the device to apply that transform. This could be wrapped into a function like MoveTo(X, Y), which I won't actually give the code for. Earlier I said to remember the fact that the vertex code specified the vertices around the origin. Because we did that, translating (moving) the position moves the center of the panel. If you are more comfortable with moving the upper left or some other corner, change the way the vertices are specified. You could also create different coordinate systems by correcting the parameters sent to the MoveTo function. For example, our viewport currently goes from —100 to +100. If I wanted to use MoveTo as if it were going from 0 to 200, I could simply correct for it in my call to D3DXMatrixTranslation by subtracting 100 from the X position. There are many ways to quickly change this to meet your specific needs, but this will provide a good basis for experimentation.

Other Matrix Operations

There are many other matrix operations that will affect the panel. Perhaps the most interesting are scaling and rotation. There are D3DX functions for creating these matrices as well. I'll leave the experimenting up to you, but here are a few hints. Rotation about the Z-axis will create rotation on the screen. Rotating about X and Y will look like you are shrinking Y and X. Also, the way you apply multiple operations is through multiplication and then sending the resulting matrix to the device:

D3DXMATRIX M = M1 * M2 * M3 * M4;

g_pd3dDevice->SetTransform(D3DTS_WORLD, &M);

But, remember that the product of matrix multiplication is dependent on the order of the operands. For instance, Rotation * Position will move the panel and then rotate it. Position * Rotation will cause an orbiting effect. If you string together several matrices and get unexpected results, look closely at the order.

As you become more comfortable, you may want to experiment with things like the texture matrix, which will allow you to transform the texture coordinates. You could also move the view matrix to affect your coordinate system. One thing to remember: locks are very costly, always look to things like matrices before locking your vertex buffers.

Wrapping Up

Looking at all the code listed here, this is really a long, drawn out way to do a blit, but the nice thing is that most of this can be wrapped into tidy functions or classes that make all this a one time cost for long term benefit. Please remember that this is presented in a very bare bones, unoptimized way. There are many ways to package this to get maximum benefit. This method should be the optimal way to create 2D applications on current and coming hardware and also will pay off in terms of the effects that you can implement very easily on top of it. This approach will also help you blend 2D with 3D because, aside from some matrices, the two are the same. The code was easily adapted from 2D work that I did in OpenGL, so you could even write abstract wrappers around the approach to support both APIs. My hope is that this will get people started using DX8 for 2D work. Perhaps in future articles I will talk about more tricks and effects.

DirectDraw The Easy Way

by Johnny Watson

This article describes how to setup DirectDraw displays and surfaces with minimal effort using the common libs included in the DirectX SDK. This can be particularly helpful for those who want a quick way of doing things, while still maintining control of their application's basic framework. Please note the fact that these classes abstract quite a few things, and I highly recommend peering into their functions at some point to see how things are done on a lower level.

Setting it Up

For this article, I'm assuming you have Microsoft Visual C++, and the DirectX 8.1 SDK. If not, please adapt to portions of this article accordingly. Anyway, start up Visual C++, and create a new Win32 Application project. Then go into your DirectX SDK's samples\multimedia\common\include directory, and copy dxutil.h and ddutil.h to your project folder. Then go to samples\multimedia\common\src, and do the same with dxutil.cpp, and ddutil.cpp. Add the four files to your project, and link to the following libraries: dxguid.lib, ddraw.lib, winmm.lib. Now, you create a new C++ source file document, and add it to your project as well. This will be the file we'll work with throughout the tutorial.

The Code

Now that we've got that out of the way, we can get down and dirty with some actual code! Let's start off with this:

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

#include "dxutil.h"

#include "ddutil.h"

Standard procedure here. We #define WIN32_LEAN_AND_MEAN, so all that icky MFC stuff doesn't bloat our program (just a good practice if you aren't using MFC). Then we include dxutil.h, and ddutil.h, the two centerpieces of this article. They provide shortcut classes to make programming with DirectX in general less taxing.

//globals

bool g_bActive = false;

CDisplay *g_pDisplay = NULL;

CSurface *g_pText = NULL;

//function prototypes

bool InitDD(HWND);

void CleanUp();

void GameLoop();

Pretty self explanatory. Our first global, g_bActive, is a flag to let our application know whether or not it's okay to run the game. If we didn't have this flag, our application could potentially attempt to draw something onto our DirectDraw surface after it's been destroyed. While this is usually a problem at the end of the program where it isn't that big of a deal, it generates an illegal operation error, and we don't want that, now do we? g_pDisplay is our display object. CDisplay is the main class in ddutil. It holds our front and back buffers, as well as functionality for accessing them, drawing surfaces onto them, creating surfaces, etc. g_pText is our text surface. We will draw text onto this surface (as you've probably figured out), and blit it onto our screen. Note how both objects are pointers, and are initialized to NULL.

Now for the function prototypes. InitDD() simply initializes DirectDraw. Thanks to the DDraw Common Files, this is a fairly simple procedure (but we'll get to that later). CleanUp() calls the destructor to our g_pDisplay object, which essentially shuts down DDraw, and cleans up all of our surfaces. GameLoop() is obviously where you'd put your game.

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {

switch(uMsg) {

case WM_CREATE:

InitDD(hWnd);

g_bActive=true;

break;

case WM_CLOSE:

g_bActive=false;

CleanUp();

DestroyWindow(hWnd);

break;

case WM_DESTROY:

PostQuitMessage(0);

break;

case WM_MOVE:

g_pDisplay->UpdateBounds();

break;

case WM_SIZE:

g_pDisplay->UpdateBounds();

break;

default:

return DefWindowProc(hWnd, uMsg, wParam, lParam);

break;

}

return 0;

}

Standard Windows Procedure function here. On the WM_CREATE event, we initialize DirectDraw, and set our g_bActive flag to true, so our GameLoop() function is executed. When WM_CLOSE is called, we want to set our active flag to false (again, so our app doesn't try to draw to our DDraw screen after its been destroyed), then call our CleanUp() function, and finally destroy our window. It's important that you handle the WM_MOVE and WM_SIZE events, because otherwise DirectDraw will not know the window has been moved or resized and will continue drawing in the same position on your screen, in spite of where on the screen the window has moved.

bool InitDD(HWND hWnd) {

//dd init code

g_pDisplay = new CDisplay();

if (FAILED(g_pDisplay->CreateWindowedDisplay(hWnd, 640, 480))) {

MessageBox(NULL, "Failed to Initialize DirectDraw", "DirectDraw Initialization Failure", MB_OK | MB_ICONERROR);

return false;

}

return true;

}

The infamous InitDD() function… but wait, it's only several lines! This is what the common libs were made for! We now have all the DirectDraw setup garbage out of the way, effortlessly! Again, you'll notice that it's done a lot for you. If you don't really care to know the exact procedure of what has been abstracted from you, at least get the gist of it. It will help out if you have to go back and change the cooperative level or whatnot. Note that this is a boolean function, so if you like, you can do error checking (which I, for some reason or another, decided to omit in this article).

void CleanUp() {

SAFE_DELETE(g_pDisplay);

}

Simple enough. This function calls on the SAFE_DELETE macro defined in dxutil to delete our display object, and call the destructor.

void MainLoop() {

g_pDisplay->CreateSurfaceFromText(&g_pText, NULL, "DDraw using Common Files", RGB(0,0,0), RGB(0,255,0));

g_pDisplay->Clear(0);

g_pDisplay->Blt(0, 0, g_pText, 0);

g_pDisplay->Present();

g_pText->Destroy();

}

This is where you'd want to put your game. In order to give you an example of how surface objects work, we've made a simple text surface and drawn some text onto it. Note that we destroy g_pText at the end, because it is recreated every cycle and not doing so would eventually eat up quite a bit of memory.

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int iShowCmd) {

WNDCLASSEX wc;

HWND hWnd;

MSG lpMsg;

wc.cbClsExtra=0;

wc.cbSize=sizeof(WNDCLASSEX);

wc.cbWndExtra=0;

wc.hbrBackground=(HBRUSH)GetStockObject(BLACK_BRUSH);

wc.hCursor=LoadCursor(NULL, IDC_ARROW);

wc.hIcon=LoadIcon(NULL, IDI_APPLICATION);

wc.hIconSm=LoadIcon(NULL, IDI_APPLICATION);

wc.hInstance=hInstance;

wc.lpfnWndProc=WndProc;

wc.lpszClassName="wc";

wc.lpszMenuName=0;

wc.style=CS_HREDRAW | CS_VREDRAW;

if (!RegisterClassEx(&wc)) {

MessageBox(NULL, "Couldn't Register Window Class", "Window Class Registration Failure", MB_OK | MB_ICONERROR);

return 0;

}

hWnd = CreateWindowEx(NULL, "wc", "DirectDraw Common Files in Action", WS_POPUPWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 640, 480, 0, 0, hInstance, 0);

if (hWnd == NULL) {

MessageBox(NULL, "Failed to Create Window", "Window Creation Failure", MB_OK | MB_ICONERROR);

return 0;

}

ShowWindow(hWnd, SW_SHOW);

UpdateWindow(hWnd);

while (lpMsg.message != WM_QUIT) {

if(PeekMessage(&lpMsg, 0, 0, 0, PM_REMOVE)) {

TranslateMessage(&lpMsg);

DispatchMessage(&lpMsg);

} else if(g_bActive) {

MainLoop();

}

}

return lpMsg.wParam;

}

The longest function in our application, WinMain(). As usual, we setup our window class, create our window, show and update it, and go into the message loop. The loop is different from usual because we dont want the processing of our game to interfere with the processing of messages. We use our g_bActive flag to see if its safe to call our game loop, which involves blitting things onto the screen, and at the end of it all we finally return lpMsg.wParam (I'm honestly not sure why, but thats how it's done in every other Win32 app, so oh well).

Pretty simple, huh? 135 lines of code and we're already blitting stuff to the screen. Feel free to explore these classes further, and experiment with things like color keying, loading surfaces from bitmaps, ect. This is a very cool shortcut to using DDraw. It makes things easy without sacrificing control (you can always go back and edit the classes if you want) or performance. One thing to note is that on my computer if I don't draw anything onto the screen using this framework, the application will lock up (which is why I've included text output here). This shouldn't be much of an issue, seeing as how your game will more than likely be blitting things onto the screen (unless there's some new art style which I'm not aware of).

Have fun!

Разработка графического движка

#1: Введение

Автор: Константин "Dreaddog" Поздняков

Об авторе

Константин Поздняков заканчивает Кемеровский Государственный Университет на кафедре ЮНЕСКО по НИТ. Его диплом достаточно тесно связан с трехмерной графикой и Direct3D в частности. Разрабатывает свой собственный движок. Недавно получил статус MCP (Microsoft Certified Professional) по Visual C++ 6 Desktop. Разработкой игр занимается очень серьезно, планирует связать свою карьеру именно с игровым трехмерным программированием.

Составляющие Игрового Графического Движка

Эта статья ставит своей целью описать (по возможности наиболее полно) возможности игрового движка современного уровня. Я попытался классифицировать потребности в реализации, требуемой от программиста. Здесь не обсуждаются подробно реализации каждого конкретного элемента. Этому будут посвящены следующие статьи, а не этот обзор.

Современный игровой движок должен уметь:

1. Рисовать интерфейс.

2. Рисовать курсор.

3. Рисовать сцену.

Это те пункты, которые касаются графической части, а кроме того:

4. Использовать файл настроек для инициализации.

5. Проводить проверку состояния устройства и выдавать ошибку при их несоблюдении.

6. Современный графический движок не должен в реальном времени изменять параметры устройства или режим работы (оконный/полноэкранный).

7. Уметь загружать файлы из сжатого файла, причем делать это асинхронно.

8. Вести файл протокола.

9. Уметь в реальном времени изменять параметры, не требующие изменения устройства.

10. Контролировать ошибки и правильно их обходить.

11. Корректно чистить после себя при загрузке дополнительной информации.

12. Контролировать состояние сцены.

13. Пройти отладку в VTune.

14. Должен знать свои "тонкие" места.

Технические возможности движка:

15. Экранные меню.

16. Остановка сцены (без остановки рендеринга ).

17. Игровой интерфейс.

18. Ландшафт.

19. Объекты.

20. Модели (со скелетной анимацией).

21. Окружение.

a. Туман

b. Слоеный туман

c. Небо

d. Облака

e. Погодные эффекты

f. Вода

g. Солнце, луна, звезды.

22. Точечные эффекты.

23. Трава.

24. Эффекты отражения.

25. Тени.

Может, что и забыл, но пока на ум ничего не приходит, присылайте свои предложения для реализации и мы это обязательно сделаем. Рассмотрим каждый пункт в развернутом виде.

1. Рисовать интерфейс.

Это одна из самых главных частей игрового проекта, именно она делает из программы демонстрирующей графические возможности игру. Кроме того, единственная возможность движка позволяет отображать Main Menu в проекте, экран сохранения, экран восстановления, экран загрузки карты, игровой интерфейс — т. е. областей применения масса. Обычно для интерфейса используют трансформированные координаты с наложенной текстурой. Эта часть отвечает за презентабельность проекта, ведь именно ее увидит пользователь в первую очередь, за нее в основном отвечает команда художников и дизайнер.

2. Рисовать курсор.

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

3. Рисовать сцену.

Сердце любого графического движка — его сцена, набор объектов, взаимодействующих с пользователем. Обычно, сложнее подобрать реалистичные параметры сцены, а не реализовать требуемые возможности. Движок может быть мощным по скорости прорисовки, с качественным выходным изображением, но плохая команда трехмерных художников, команда сопровождения и недостаточная проработка параметров реалистичности может свести на нет все усилия программистов. При этом рисование сцены должно быть масштабируемым, то есть добавить треугольников в модель персонажа достаточно просто, но переделать модель рисования неба, эффектов и теней может быть затруднительно. Пример — вода в M&M IX, по-моему, если говорить об убогости реализации LithTech + M&M IX это сладкая парочка, там, где движок не глючит — там недоработки художников и дизайнеров, а там где у них это все более-менее прилично, вылезает ущербность реализации LithTech. Я думаю назвать конкретные места нет никакой необходимости, все прекрасно их видели.

4. Использовать файл настроек для инициализации.

Здесь все просто, все изменяемые параметры должны применяться при следующей загрузке, и тогда без применения инициализационного файла не обойтись. Инициализационный файл не погибает при переустановке системы, его можно легко перенести с машины на машину. Сложностей в его реализации нет, там все просто. Либо ждите, когда будет выложена моя статья с реализацией, либо реализуйте сами, либо обращайтесь прямо ко мне, я вышлю.

5. Проводить проверку состояния устройства и выдавать ошибку при их несоблюдении.

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

6. Современный графический движок не должен в реальном времени изменять параметры устройства или режим работы (оконный/полноэкранный).

Нет необходимости в изменении устройства из приложения, мы можем упростить эту часть, и направить усилия на другие более важные части. Пользователи привыкли, и могут безропотно выйти из программы, чтобы сменить режим с оконного на полноэкранный или изменить глубины цвета (все равно почти вся информация загружается заново). Это упрощение и скорее упрощает жизнь программистам. Вообще говоря, команда разработчиков единое целое, но у каждой части свои задачи (все помнят модель разработки Microsoft Solution Framework), поэтому ни одна из частей не должна идти на поводу у другой, но в тоже время должны вырабатываться разумные компромиссы (если дизайнером нужно рисовать по 200 KPolys за фрейм при 60 Hz на GeForce 2, то программисты должны обеспечить такую производительность, но если программистам нужно рисовать по 200+ за раз, то модели должны быть сделаны с этим расчетом).

7. Уметь загружать файлы из сжатого файла, причем делать это асинхронно.

В основном, это культура программирования, нет необходимости пользователям видеть структуру организации приложения (кроме того, при шифровании усложняется жизнь производителей контрафактной продукции и часто это требование издателя). Асинхронность необходима для одновременной работы с несколькими файлами (фоновое проигрывание музыки и загрузка сцены).

8. Вести файл протокола.

Протоколирование сильно упрощает отладку приложения и систематизирует работу программистов. Очень легкая задача. В одной из общих статей обязательно будет реализация, если нет мочи ждать, то пишите мне, ищите в Сети или пишите сами.

9. Уметь в реальном времени изменять параметры, не требующие изменения устройства.

Скорее приведен как пример правильного поведения устройства. Движок должен предоставлять широкий набор параметров для изменения, касающихся как внешнего вида, так и производительности. Игровые проекты двигают рынок аппаратуры, а не наоборот. Мы должны предоставить человеку веский довод для улучшения аппаратуры, и слабая аппаратура это не повод лишать себя и "смежников" дополнительного заработка. Игрок, он как девушка — нет игроков, которые не играют, есть игроки, которые не играют в твою игру (это твоя вина).

10. Контролировать ошибки и правильно их обходить.

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

11. Корректно чистить после себя при загрузке дополнительной информации.

Нельзя допускать забивание памяти видеокарты и системной памяти, для этого можно использовать программы типа NUMEGA Bounds Checker, или встроенные в API средства контроля, они будут рассмотрены отдельно.

12. Контролировать состояние сцены.

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

13. Пройти отладку в VTune.

Отладка в VTune может добавить до 300 % производительности, поэтому не стоит ей пренебрегать.

14. Должен знать свои "тонкие" места.

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

15. Экранные меню.

Необходимо реализовать быстро и точно, для этого достаточно пользоваться рекомендациями, даваемыми, например, Ричардом Хадди (Richard Huddy, NVidia) — как он говорит: "Вам необходимо поверить, во все те плохие вещи, которые я вам говорю". Следующая статья будет полностью посвящена оптимизации Direct3D8 приложений, а после этого будет приведен класс, реализующий эти рекомендации применительно к экранным меню.

16. Остановка сцены (без остановки рендеринга).

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

17. Игровой интерфейс.

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

18. Ландшафт.

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

19. Объекты.

Главное в реализации объектов — это сортировка и обрезка. Мы должны сортировать объекты по дальности, по текстуре и определять видимые и невидимые объекты. Сортировка по дальности позволяет использовать уровни детализации (отключать освещение объекта, тень от объекта и т. д.), правильно рисовать прозрачные объекты, сортировка по текстуре сильно увеличивает производительность, невидимые объекты самые быстрые (потому что мы их не рисуем). Кроме того, необходимо контролировать загрузку объектов и текстур (не допускать излишнего копирования информации). Реализацию такого вида объектов мы тоже подробно рассмотрим.

20. Модели (со скелетной анимацией).

Для них верно все то же, что и для предыдущего пункта, кроме того, при отдалении можно убирать части скелета (bones) и за счет этого увеличивать скорость работы.

21. Окружение.

a. Туман

b. Слоеный туман

c. Небо

d. Облака

e. Погодные эффекты

f. Вода

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

22. Солнце, луна, звезды.

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

23. Точечные эффекты.

Простая с точки зрения реализации возможность, но требует разработки качественных эффектов, разработанных на основе точечных спрайтов. Без художников и дизайнеров эффектов эта возможность не только не добавит очков приложению, но может и отнять их.

24. Трава.

Реализация травы необходима, но она скорее декоративное украшение (хотя, безусловно, эффектное), основная проблема — эффективная реализация (обычно используют нетрансформированные спрайты с изменением альфа-канала по удаленности от камеры. (Обычно не реализуется в движках с плавающей камерой, хотя в них возможно использование пиксельных шейдеров на небольшую часть экрана для реализации изменения высоты и освещенности).

25. Эффекты отражения.

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

26. Тени.

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

Главный вывод, который можно сделать — реализация игрового приложения — это комплексная задача, требующая работы всех подразделений.

Можно сказать о некоторых способах ускорения разработки игрового проекта: например, можно позволить художникам и дизайнерам разрабатывать трехмерные модели в программах для трехмерного моделирования (например, Discreet 3D Studio Max), а когда игровой фрейм с набором редакторов будет реализован, написать конвертор в собственный формат и релиз выпускать с собственным форматом.

Следующая статья будет посвящена особенностям оптимизации Direct3D8 приложений. Жду любых комментариев, пишите — пообщаемся.

Автор: Константин "Dreaddog" Поздняков

#2: Оптимизация Direct3D приложений

Автор: Константин "DreadDog" Поздняков

Начнем, как обычно, издалека. Оптимизация любого приложения, а графического тем более, это процесс не только увлекательный и волнующий, но очень и очень полезный. Затратив немного усилий в момент, когда создается приложение можно избавить себя от кучи проблем в момент, когда приложению понадобится дополнительная производительность. К тому же, обычно, если программист задумывается об оптимизации, то у него есть немного время, и он может написать не только быстро, но и красиво. Большая часть советов, приводимых здесь общедоступна, но, к сожалению, не общеизвестна. А, учитывая, что чем больше хороших игровых проектов (это особенно актуально для России), тем больше платят зарубежные издатели за права на издание, тем больше в конечном итоге объем рынка игровых приложений в России, и тем привлекательнее этот рынок для инвестиций. Замкнутый круг, от расширения (но не разрыва), которого выигрывают все стороны — повышается престиж страны и конечный заработок разработчиков. Итак, немного напыщенных фраз закончены — пора перейти к советам.

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

Оптимизация трехмерного приложения может вестись по нескольким ключевым позициям:

1. Оптимизация рендеринга.

2. Оптимизация процессорной части приложения.

3. Оптимизация алгоритмов.

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

Рассмотрим их по порядку, причем начнем с конца.

3. Оптимизация алгоритмов

Мы интересуемся только графической частью приложения, поэтому здесь главное правило, как и в программировании:

Если можно что-то сделать вне цикла — делай это вне цикла.

Если можешь создать таблицу с параметрами и ее использовать — создай и используй.

Если можешь что-то не считать — не считай это.

А главное, если есть возможность что-то ускорить, то эту возможность нельзя упускать.

Создание таблицы синусов и косинусов для быстрого преобразования Фурье (задачи распознавания образов и шифрования), вместо использования функций позволяет увеличить скорость расчета на порядки.

Если можно обновлять информацию не для каждого фрейма, а хотя бы для каждого второго, то рост производительности в этой части будет на 100%.

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

2. Оптимизация процессорной части приложения

Интересно, что для этой части предлагаются только методы оптимизации выполнения на уровне аппаратуры, но забывать про оптимизацию параллельности выполнения тоже не стоит. Мы имеет не один процессор, а два: CPU и GPU. В GPU работа хорошо распараллеливается, и мы за ней не следим, но есть ряд операций, выполнение которых заставляет процессор простаивать, поэтому ТАКИЕ операции нужно стараться уменьшать в количестве и следовать рекомендациям, приведенным в части статьи, посвященной непосредственно примерам. Кстати в этом процессе может помочь Statistical Driver от NVIDIA, но его нужно получать непосредственно от NVIDIA, а для этого необходимо стать регистрированным разработчиком на developer.nvidia.com.

Итак, самое главное

1 удаляем непосредственное преобразование типа float к типу long или int.

Каждый раз, когда вы пишите

int i = f; // f - float, вы неявно вызываете функцию ftol() или ftoi(), поэтому лучше так:

Вместо:

int i = f; // вызов __ftoi()

Пишем:

__inline void myftol(int *i, float f) {

__asm fld f;

__asm mov edx, I

__asm fistp[edx];

}

//…

MyFtoL(&i, f);

Либо используем недокументированный переключатель оптимизации /QIfist чтобы избежать вызовов __ftol().

2 Не используем fsqrt — 79 циклов это слишком долго.

Достаточно качественная реализация приведена в NVToolkit (MUST HAVE для всех кто программирует графику, но не хочет лезть в математику). Полный архив NVToolkit можно скачать с http://developer.nvidia.com/. Когда я ее выкачивал он лежал по адресу http://developer.nvidia.com/docs/IO/1208/ATT/NVTK_no_libs.zip.

/********************************************************************* ulSqrt.cpp

Copyright (C) 1999, 2000 NVIDIA Corporation

This file is provided without support, instruction, or implied warranty of any kind.

NVIDIA makes no guarantee of its fitness for a particular purpose and is not liable under any circumstances for any damages or loss whatsoever arising from the use or inability to use this file or items derived from it.

Comments:

*********************************************************************/

#include <stdio.h>

#include <math.h>

#include <windows.h>

static float _0_47 = 0.47f;

static float _1_47 = 1.47f;

float__fastcall ulrsqrt(float x) {

DWORD y;

float r;

_asm {

mov eax, 07F000000h+03F800000h // (ONE_AS_INTEGER<<1) + ONE_AS_INTEGER

sub eax, x

sar eax, 1

mov y, eax // y

fld _0_47 // 0.47

fmul DWORD PTR x // x*0.47

fld DWORD PTR y

fld st(0) // y y x*0.47

fmul st(0), st(1) // y*y y x*0.47

fld _1_47 // 1.47 y*y y x*0.47

fxch st(3) // x*0.47 y*y y 1.47

fmulp st(1), st(0) // x*0.47*y*y y 1.47

fsubp st(2), st(0) // y 1.47-x*0.47*y*y

fmulp st(1), st(0) // result

fstp y

and y, 07FFFFFFFh

}

r = *( float *)&y;

// optional

r = (3.0f - x * (r * r)) * r * 0.5f; // remove for low accuracy

return r;

}

/*

sqrt(x) = x / sqrt(x)

*/

float __fastcall ulsqrt(float x) {

return x * ulrsqrt(x);

}

3 Нормализация векторов. Обычно делают неправильно, но сначала код:

//Обычно делают так:

void normaliseNormalise(Vector *v) {

float L, L_squared, one_over_L;

L_squared = (v->x * v->x) + (v->y * v->y) + (v->z * v->z);

L = sqrt(L_squared);

one_over_L = 1.0 / L;

v->x = v->x * one_over_L;

v->y = v->y * one_over_L;

v->z = v->z * one_over_L;

}

// А можно так:

#define ONE_AS_INTEGER ((DWORD)(0x3F800000))

float __fastcall InvSqrt(const float & x) {

DWORD   tmp = ((ONE_AS_INTEGER << 1) + ONE_AS_INTEGER - *(DWORD*)&x) >> 1;

float y = *(float*)&tmp;

return y * (1.47f - 0.47f * x * y * y);

}

void Normalise(Vector *v) {

float L_squared, one_over_L;

L_squared = (v->x * v->x) + (v->y * v->y) + (v->z * v->z);

one_over_L = InvSqrt(L_squared);

v->x = v->x * one_over_L;

v->y = v->y * one_over_L;

v->z = v->z * one_over_L;

}

По-моему комментарии излишни :).

4 Разворачивание циклов

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

Для этого используем макросы, но оставляем возможность переключится на функции и не развернутые циклы для отладки (Отладка развернутых циклов сложна и неинформативна).

Опасайтесь разбухания кода!

Измеряйте производительность кода постоянно, причем желательно вести базу данных, в которой будут указываться не только изменения в коде, но и изменения в производительности. Особенно такие базы полезны при работе с несколькими программистами графического ядра приложения.

1. Оптимизация рендеринга

Благодатная тема для описания, существует огромное количество способов сделать неправильно и один способ сделать правильно (Это заявление не относится к операционной системе Windows, для нее правильнее другое: Существует огромное количество способов сделать правильно, но они устарели и их лучше не использовать, а самый лучший способ — это как раз тот, в который мы недавно добавили большое количество NOP'ов и он работает как раз так, чтобы чуть-чуть тормозить на средней системе :)).

DirectX 8 и, в частности, Direct3D8 - это безусловно самая лучшая разработка Корпорации (ведь мы уже смело можем ТАК ее называть).

Итак, следуйте следующим указаниям:

1. Не используйте "тяжелые" функции в цикле рендеринга. Всегда функции

ValidateDevice(), CreateVB(), CreateIB(), DestroyVB(), Optimize(), Clone(), CreateStateBlock(), AssembleVertexShader()

помещайте в загрузку сцены и НИКОГДА в цикл рендеринга приложения. Создание буфера вершин может занять до 100 ms!

2. Использование DrawPrimitiveUP() является ошибкой, вызывает задержки в работе процессора и всегда вызывает дополнительное копирование вершин.

3. Не позволяйте художникам контролировать ваш код. Если вам необходимо рисовать по 200+ вершин за проход, то геометрия должна удовлетворять этому требованию. Позволите себе рисовать по 2 вершины за вызов — и вы ТРУП :(.

4. Сортируйте по текстурам и по шейдерам. Если сложно сортировать по обоим параметрам, используйте кэширование. Создаем большую текстуру 4K×4K, в нее копируем текстуры, используемые в сцене, подправляем текстурные координаты геометрии и рисуем большой кусок с одной текстурой сортированный по шейдерам. Либо готовим геометрию таким образом, чтобы это кэширование не требовалось.

5. Стараемся использовать как можно меньшее количество буферов вершин. Смена буфера очень "тяжелая" операция и дорого нам стоит. Поэтому

6. Загружаем модели в сцене в минимальное количество буферов.

7. Используем минимальное количество разновидностей FVF, если возможно — то один общий FVF (Максимального размера).

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

9. Всегда считайте данные в видеокарте, как доступные только для записи.

10. Если вам необходимо восстанавливать состояние буфера, храните две копии.

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

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

13. Разделяйте буфер на потоки, если вам необходимо обновлять только часть информации, и.

14. Всегда обновляйте данные подряд. (процессор передает данные по 32 байта, 64 байта — Pentium IV).

15. Старайтесь использовать кэш вершин видеокарты. Если данные в кэше они не пересчитываются (экономится T&L шаг).

16. Всегда старайтесь использовать FVF кратный 32 байтам.

17. Не используйте примитивы высокого уровня — NVIDIA признает, что это рекламный ход и рекомендует подождать карт смещения (Displacement maps в DirectX9).

18. Производите грубое отсечение частей, не попадающих на экран, и не посылайте их в видеокарту (CPU или ProcessVertices).

19. Рисуйте за раз не менее, чем по 200+ вершин. См. иллюстрации в конце статьи.

20. Всегда используйте индексированный рендеринг. Это единственный случай, когда используется кэширование в кэш вершин видеокарты.

21. Отдавайте предпочтение Indexed Strips, после этого Indexed Lists, после этого Indexed Fans. Грамотное использование Indexed Strips может дать большой прирост скорости (кэш + отсутствие копирования лишней информации). Размер кэша — 18 вершин для GeForce 3/4 Ti, 10 — для GeForce 1/2/4 MX.

22. Для многопроходного рендеринга используйте первый Z-only проход — это экономит расчет следующих проходов.

23. Используйте уровни детализации для всего, чего только возможно — для текстур (для удаленных объектов можно не накладывать Detailed Map), для объектов в части геометрии (количество полигонов) и скиннинга (уменьшаем количество костей (bones) при удалении объекта), отключаем дальние источники освещения, отключаем туман для объектов, на которых он не сказывается.

24. Всегда отдавайте предпочтение большему разрешению перед FSAA (Full Scene Antialiasing) — это бесплатный антиалиазинг.

25. Попробуйте уменьшить размер вершины. Например, позволяйте вершинным шейдерам генерировать компоненты вершины. Сжимайте компоненты и используйте вершинные шейдеры для декомпрессии.

26. Перемещайте вершины в буфере, для того чтобы они использовались подряд при обработке треугольников.

27. Не используйте пару функций BeginScene(), EndScene() более одного раза на кадр.

Рис 1. Производительность видеокарты в зависимости от размера передаваемого за раз фрагмента.

Рис 2. Пропускная способность AGP шины в зависимости от размера FVF и фрагмента.

На этом мы закончим общую часть, если вам стало интересно — прекрасно, значит я достиг своей цели. Дополнительная информация может быть найдена на сайте http://developer.nvidia.com/

Следующая статья будет посвящена созданию рабочего каркаса игрового графического движка.

Пишите — мне интересно Ваше мнение, Ваши предложения и Ваши комментарии. В споре рождается истина и разбиваются головы.

Автор: Константин "DreaDdog" Поздняков

#3: Каркас графического приложения

Автор: Константин "DreadDog" Поздняков

Создание каркаса графического приложения — это занятие достаточно простое с технической точки зрения, но очень (ну может не очень, но все равно) сложное с архитектурной точки зрения. Фактически, не было ни одного случая, чтобы первый каркас любого программиста в его жизни не был забракован по той или иной причине. Кроме того, причиной, по которой здесь рассмотрен каркас в числе первых элементов, можно считать, что создание каркаса — это отличный способ узнать тонкости как Direct3D программирования, так и программирования под Win32 API. А посмотреть на хорошо написанный каркас полезно не только для новичков, но и для вполне профессиональных программистов. Хотя бы для того, чтобы смело сказать: "Ха, да у меня лучше". И улыбнуться :). Будем считать, что тот каркас, который приводится здесь, относится как раз к хорошим. Ссылка в конце статьи. И я надеюсь, что мои предыдущие статьи заинтересовали вас в достаточной степени, чтобы вы скачали эти несколько сот килобайт архива.

Основная задача каркаса — предоставить команде программистов поле деятельности, на котором они смогут достаточно быстро описать и построить рабочее приложение. Потом для этого приложения можно будет проводить замену отдельных блоков. Но структура вызовов будет оставаться такой же, а значит, непредвиденных ошибок будет меньше, и они будут более предсказуемыми. Я считаю, что именно эту задачу мне удалось выполнить. Кроме этого, каркас ни в чем не должен ограничивать разработчиков - ему должно быть глубоко параллельно, какой сложности приложения вы разрабатываете, и какому жанру оно относится. Все требования на каркас остаются теми же. Ладно, общие вопросы, которые я посчитал нужными упомянуть, я упомянул, все остальное либо тривиально, либо я этого не знаю :). Итак, следующий абзац.

Общедоступные реализации подобных задач были и от NVIDIA (NVToolkit, доступен на сайте http://developer.nvidia.com) и от Microsoft (CD3DApplication, поставляется в комплекте DirectX SDK). Кроме того, доступны различные игровые движки, в которых это тоже можно посмотреть. Но все эти реализации обладают несколькими минусами, которые сводят на нет их плюсы. Рассмотрим по порядку. NVToolkit рассчитана на разработку программ примеров. Поэтому реализованы только графические функции, а все, что должно быть в каркасе, но к графике не относится, они смело проигнорировали. Кроме того, структура очень запутана и явно не подходит на роль первого каркаса, который программист видит в своей жизни. CD3DApplication — Корпорация как всегда в своем репертуаре. Все написано очень правильно - в этом направлении не придраться. Единственный вопрос, который возникает — зачем так усложнять? Я мне кажется что для многих программистов, для которых класс CD3DApplication (ну или CD3DFramework, так он, по-моему, назывался в DirectX 7) стал первым, он же стал и последним. Но просто так ничего не бывает, поэтому подобной реализации есть оправдание: Класс — для переносимости кода и легкого встраивания в приложения со структурой Document/View. Все остальное — для гарантии того, что приложение запустится на любой машине. Самый спорный момент — енумерация и выбор REF, если функция аппаратно не поддерживается, увидеть все равно ничего нельзя (REF), но Microsoft смогла доказать что ее приложения запускаются на любой машине. (Те, кто видел Heroes 2 от NWC, запущенный на 486 SX-25/4 Mb под Windows 95, тот меня поймет, я видел :( ). Опять таки, все что превосходит графическую сторону приложения не было затронуто. Все коммерческие движки, во-первых — это уже движки, во-вторых. Полностью в них разобраться может только автор (а учитывая то, что написал он это давно, то и это под вопросом) и с десяток особо умных программистов, которые на это даже времени тратить не будут. Поэтому дерзайте в Сети достаточно ссылок - ищите, да найдете :). В любом случае, даже если вы посмотрите на то, что написал я и оно вам понравится, я бы советовал скачать какой-нибудь свободно распространяемый движок и просто посмотреть на него, там могут быть реализации, которые ни вам, ни мне просто не придут в голову (все мы думаем по-разному, даже если говорим одно и то же).

Итак, особенности реализации:

Глобальное описание функций каркаса. Задача встраивания каркаса в приложение не стоит по определению, кроме того, у нас нет необходимости в двух копиях функциональности, заложенной в каркас, поэтому, я считаю, что ничто не мешает нам описать большую часть переменных и функций в глобальном пространстве имен. Кроме, того, это позволяет легко реализовать следующую особенность каркаса. Итак

Направленность на выполнение любой задачи действиями (функции с префиксом ueAction). Это позволяет в экземплярах классов ставить в соответствие действию (например, щелчку мышкой на экземпляре класса Button, здесь он не приводится, можно поставить в соответствие глобальный Action, который осуществляет корректное завершение работы программы) события. Причем событие не фиксируется жестко в классе. Кроме того, если в реализацию добавить компилятор Си (а такие реализации я видел), то можно легко расширять возможности приложения без перекомпиляции.

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

Осуществляется отслеживание ошибок. Причем, сделана не только стандартная проверка возвращаемого значения, но и проверка глобального флага (схожая с GetLastError() из Win32 API). Это позволяет возвращать ошибки из функций, реализующих события. Кроме того, проверяется, выставлен ли флаг (m_dwError) во всех критических местах приложения. То есть любая ошибка ведет к корректному завершению программы с выдающимся после завершения работы приложения сообщением.

А также, я посчитал необходимым добавить в каркас следующие функции:

Рисование Курсора (CCursor). Это позволило сделать каркас законченным приложением. Все равно практически всегда требуется рисовать собственный курсор. Возможно реализация, которая предлагается спорна и требует доработки, но у меня она работает без ошибок как в оконном режиме, так и в полноэкранном режиме, кроме того, особенностью (но не недостатком) этого класса можно считать только то, что инициализация курсора происходит изнутри класса, то есть не определяется необходимая функциональность для смены загруженного курсора на лету. Но это, в общем, не сложная задача, а здесь я ее не реализовал только потому, что не посчитал нужным. Реализована анимация курсора и реализована смена стадий курсора, в заголовочном файле описан пример добавления новых стадий (кстати, как вам мой английский :)), а в функции Create() — создания анимационных цепочек.

Распаковка ресурсов из файла ресурсов (ResourceManager). Я прекрасно понимаю, что реализация, которая есть в этом классе, неидеальна, но это лучше, чем отдельно лежащие ресурсы, пусть даже записанные не в общедоступном формате. А при необходимости реализацию можно дописать или переделать — было бы желание. Используется CFolder класс, основанный на реализации одной из олимпиадных задачек (задача про хакера Билла у которого накрылся жесткий диск). Он создает и удаляет дерево каталогов по названию файла, начиная с определенного пути (названия файлов должны быть относительными). Описание использования класса есть в main.cpp и мне кажется достаточно логичным.

Сохранение и восстановление параметров приложения из файла конфигурации (CConfigFile). Эта возможность была означена как необходимая для качественного графического приложения. Класс простой, использование тоже несложное. Единственное ограничение - нужно переписать функцию класса CConfigFile::restore() - она должна восстанавливать сбойный конфигурационный файл к первоначальному состоянию. Эта специфичная задача требует специфичной реализации для каждого приложения, и поэтому здесь я ее не провел, но при расширении приложения, я обязательно занесу некоторые значения в реализацию этой функции. Кстати, изменение разряда строк не введено, поэтому следите, чтобы параметр, определенный в файле и строка, по которой вы получаете его параметр, не только совпадали, но и были в одном разряде.

Сохранение информации о выполнении приложения в файл протокола. Эта реализация не принадлежит мне, автора я не знаю, но все равно хочется сказать ему спасибо. Стандартная качественная реализация. Исходник поставлялся с одним из примеров NVIDIA, поэтому, я думаю, его использование не является нарушением авторского законодательства.

В каркасе рисуется счетчик FPS, для его реализации были введены классы: ueFontD3D — это CD3DFont из DirectX SDK, переименован он был просто из соглашения об именовании. Под него написан класс Label, который заданным шрифтом выводит информацию на экран. Также строчку можно скрыть или сделать серой (dimmed). Им выводится счетчик FPS и некоторая дополнительная информация.

В каркасе реализовано перемещение по сцене и изменение направления взгляда (от первого лица). Используются следующие клавиши:

LEFT ARROW, A — стрейф влево.

RIGHT ARROW, D — стрейф вправо.

UP ARROW, W — вперед.

DOWN ARROW, S — назад.

C — вверх.

V — вниз.

Для изменения наклонов головы достаточно прижать правую клавишу мыши и передвигать ей — перемещение вдоль оси Y — голову вверх/вниз, перемещение вдоль оси X — голову влево/вправо. Направление вдоль оси Y инвертировано. Если вы хотите ввести возможность инвертировать мышку, то можно ввести в конфигурационный файл переменную inverty, которая будет принимать значение 1 или -1, и читать ее в программе. А в месте изменения параметра m_iFi на нее просто умножать.

Соглашения по использованию каркаса:

Используется MFC, статично подключенная к приложению. Часть определений занесена в файл STDAFX.h, а имплементаций в файл STDAFX.cpp. Они активно используются всеми классами, поэтому определены именно там. Все общие определения типов сделаны в common.h — файле с глобальными определениями, используемыми каркасом и графическими классами. Вспомогательные классы в нем ничего не хранят. Для именования функций используется система, в которой главное слово, по которому подразделяются классы функций, ставится перед остальной частью. Например, если функция относится к движку (каркасу), то она имеет префикс ueEngine*, если к событиям — ueAction* и т. д.

В фоновом режиме инициализируется устройство DInput для получения информации от пользователя. Им мы обрабатываем только клавиатуру. Для мышки используется очередь сообщений — поэтому, обработка ведется в обработчике WM_MOUSEMOVE, кстати, там же мы должны рисовать курсор (вы можете рисование курсора перенести в функцию рендеринга — масса ощущений в оконном режиме.).

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

Следующая статья будет посвящена созданию нескольких стадий рендеринга (в ней мы сделаем главное меню). Поместим насколько экранных кнопок на экран в главном цикле рендеринга. И сделаем ландшафт (self-shadowing height-map based textured landscape with colored light map :) ). Попробуем его оптимизировать.

А сейчас о FeedBack'е: Мне очень интересно, что вы думаете обо мне и о проекте в целом, поэтому мне бы хотелось от всех вас получить письмо следующего содержания (это минимум, можно подробнее): мой литературный талант (категория L, 0-10, 0 — а может тебе чем другим заняться, 10 — неплохо), мое искусство программирования (категория P, 0-10, 0 — за такой кодинг в коляске убивать надо, 10 — неплохо ), заинтересованность проектом (категория I, 0-10, 0 — да я это даже не читал, 10 — обязательно буду следить за развитием, очень интересно). Ваш Возраст, опыт программирования на C/C++, опыт работы с графикой, предпочтительная библиотека (DX/OGL/Другое).

Автор: Константин "DreaDdog" Поздняков

#4: Ландшафт и интерфейс

Автор: Константин "DreadDog" Поздняков

Как обычно немного вступления: (о реакции читателей).

Немного по изменениям в исходниках.

Были исправлены куча ошибок и приложение начало работать устойчивей. Предвидя проблемы с инициализация "правильного" графического приложения, я создал утилиту, которая позволяет выбрать графический режим работы из списка доступных для данной видеокарты и в нем запустить приложения. Там вы можете посмотреть как нужно правильно (ну может и не правильно, но вроде работает), определять доступные режимы на конкретной видеокарте. Не реализованы в утилите, например, ограничения самого приложения, то есть в терминах каркаса "Validate" устройства не происходит, но оба приложения должны разрабатываться параллельно. Были исправлены ошибки, такие как Warning's при компиляции, излишнее использование библиотеки MFC, и подключение лишних Header'ов (в частности, DX) во вспомогательные классы. Был добавлен файл common.cpp, в который перекочевали все графические функции из stdafx.cpp. Благодаря Артему Кирилловскому, я исправил мелкие ошибки, портившие впечатление о программе. Кстати, в этой версии вращающийся кубик был убран, поэтому теперь мы начинаем разрабатывать чисто графическое, но полноценное приложение. На кнопку <H> была повешена справка по кнопкам, правда она доступна только в сцене и в главном меню ее вызвать нельзя. В класс Font были добавлены два массива, содержащие размеры каждого символа шрифта, таким образом, чтобы обеспечить корректную работу класса Edit (о нем чуть позднее). В каркас были добавлены функции для изменения гаммы (gamma), контрастности (contrast) и яркости (brightness), функции для создания обычной текстуры и текстуры как поверхности для рендеринга (Render Target). Перегружена функция для загрузки текстуры (местонахождение текстуры теперь можно передать не только как TCHAR*, но и как CString, исключительно для удобства). Добавлена функция для записи скриншота (пока только в формате Windows Bitmap, но это ведь не проблема, правда?). Она повешена на клавишу Print Screen (через DINPUT). И последнее, добавлены глобальные переменные, отвечающие за состояние клавиш <SHIFT> и <CAPS LOCK> (конечно, можно было использовать следующий способ:

nVirtKey = GetKeyState(VK_SHIFT);

if (nVirtKey & 0x8000) {/*Shifted*/}

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

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

Рассмотрим оптимизацию подробнее. Во-первых, если для каждой кнопочки вы будете использовать отдельный VB, то это будет не только медленно (необходимо менять VB для каждого элемента :( ), но и нерационально (все помнят о том, что буфер вершин - это обычная область в какой-либо памяти (видео, AGP, системная), подобно которой занимает текстура, поэтому получается 2000+ байт лишней используемой памяти для каждого буфера). Поэтому я предлагаю создавать "системный" буфер для интерфейса, в который инициализировать все экранные элементы, кроме него можно использовать буфер индексов (хотя это, наверное, необязательно). Так сделано практически во всех "интерфейсных" классах, которые добавились в этой версии приложения. Кроме того, мне кажутся разумными попытки кэшировать все текстуры интерфейса сцены в одну и рисование из нее (при этом возникают проблемы с изменением текстурных координат при смене состояния, например, кнопки), но этот вариант возможен при относительно компактном и уже определенном интерфейсе.

Мне кажется, проблем с разбором классов возникнуть не должно. Только не нужно забывать про сдвиг положения элемента интерфейса на 0.5 относительно его реального положения (чтобы центры текселей текстуры совпадали с пикселями экрана при текстурировании, подробнее можно посмотреть в DirectX SDK, топик "Directly Mapping Texels to Pixels"). Это устраняет замыливание интерфейсных элементов при фильтрации, и, кроме того, позволяет отображать интерфейс вообще без фильтрации, что сильно улучшает четкость изображения.

Список и краткое назначение классов:

Static — это класс для отображения статичной плоской графической информации. Практически все его предназначение - это рисование плоского экранного спрайта в заданных экранных координатах.

Button — это класс для отображения кнопки. Он перекрывает функциональность Static'а, кроме того он отслеживает положение курсора и состояние левой кнопки мыши, определяет момент щелчка по кнопке и запускает на выполнения функцию, которая поставлена в соответствие этому экземпляру класса. Кроме того отображается в различных состояниях:

- в состоянии NORMAL — это обычно состояние (курсор не находится над кнопкой),

- в состоянии FOCUS — курсор наведен,

- в состоянии PRESSED — курсор наведен и нажата левая кнопка,

- в состоянии DISABLED — кнопка отключена.

Animate — используется для отображения анимированной информации. В примере мы выводим огонь. Но в реальном приложении это может быть анимированная кнопка. Класс потребует некоторого расширения, но останется в принципе тем же.

И последнее,

Edit — это аналог CEdit из библиотеки MFC. Перехватывает "фокус", позволяет вводить информацию, удалять BackSpace'ом и Delete'ом. В общем, это тоже класс, который требует доработки, а также, может быть некоторой специализации. В исходнике на русском языке кратко изложено, что я думаю по этому поводу. Например, можно совместить классы Edit и CConfigFile и сделать, чтобы строчка из Edit могла быть обработана CConfigFile'ом (это очень легкая задача). Тогда можно будет легко написать консоль приложения.

Вообще, все классы, которые приведены — они как бы классы примеров, то есть не введен класс CheckBox, RadioButton, AnimateButton или ProgressBar, но не потому, что их реализация сложна, а как раз потому, что она очень похожа на реализации уже приведенных классов. Какие конкретно классы будут реализованы зависит, в основном, от необходимости и требований конкретного приложения.

Переходим к ландшафту.

В сети очень много информации по рисованию ландшафта, здесь мы отметим только принципиальные моменты, которые следует учитывать при проектировании ландшафта.

Прежде всего, нужно ориентироваться на блочную структуру, организации сцены. То есть нужно стараться, чтобы у вас были готовые небольшие локальные кусочки поверхности, которые вы можете рисовать отдельно. При этом, конечно, не стоит забывать, что по скорости рисовать два фрагмента по 400 треугольников ничуть не медленнее, чем рисовать два фрагмента по 200 треугольников. Поэтому размер фрагмента должен быть достаточно большим. При этом достаточно важно накладываемое требование на локальность кусочков. Наилучший вариант - это квадрат, но, к сожалению, квадратная организация фрагментов неоптимальна. Вы должны решить, что для вас в данный момент важнее, вывод поверхности максимально быстро или у вас есть какие-нибудь другие приоритеты (например, организовать квадратную фрагментацию гораздо проще). Дело в том, что вы будете использовать кэш видеокарты только при короткой длине линии (до восьми вершин). Вы должны захватить как можно больше вершин в кэше при обратном проходе (за счет этого можно практически вдвое увеличить скорость вывода ландшафта). Никакой практической сложности при выводе ландшафта нет. Только нужно не забывать, что линии нужно соединять без лишних треугольников, поэтому между переходами приходится вставлять вырожденные треугольники (этот механизм используется для увеличения длины линии заданной через TriangleStrip). Такие вырожденные треугольники практически бесплатны, ведь трансформированные вершины в момент использования обычно уже находятся в кэше видеокарты, и даже если их там нет, то они будут выбраны из кэша при обратном проходе, а поскольку они вырождены, то рисуются они только одной линией. То есть нам получается значительно выгоднее нарисовать лишние треугольники, но не разрывать цепочку (несколько вызовов DIP c маленьким количеством треугольников обрабатываемом при каждом вызове). Естественно, что каждому фрагменту нужно ставить в соответствие две переменные — расстояние до центра и флаг видимости (которые можно вычислять любым способом, главное — чтобы было правильно :) ). Обычно вычисляют процессором, но, например, можно для этого использовать функцию ProcessVertices (которая для этого и была создана, она, правда тоже считает процессором, но, вроде как, использует SSE или 3DNow!).

Мы реализовали поверхность с некоторыми, иногда очень важными ограничениями. Например, текстурные координаты вершин общие для всех смежных треугольников, что не всегда удобно (можно, конечно, заставить поработать художников и тогда это не проблема :) ). Зато, это позволяет использовать обычные редакторы двумерной графики для редактирования ландшафта (карты высот), что, в общем, не очень важно, но что значительно важнее — это позволяет уменьшить объем файла ресурса (для сети это очень важно).

Обычно задают минимум два набора текстурных координат, один для текстуры, второй — либо для карты освещенности (затененности), либо для Detail Map. Затененность и освещенность поверхности можно задавать в цвете конкретной вершины (в ней же можно задать цветовые пятна, которые могут повысить качество выводимой картинки). Этот способ экономит целый слой текстурирования при смешивании (это либо дополнительный проход, если мы превосходим количество слоев мультитекстрирования, либо нерациональное использование ресурсов видеокарты (введь в этот слой вместо карты освещенности можно было записать Detail Map)). Но этот способ плох в одном случае — если нас не устраивает качество затенения на поверхности (квадраты слишком большие, чтобы создавать плавные тени).

Тени могут быть заранее рассчитанными, либо считаться в реальном времени. Хороший вариант предложил Mircea Marghidanu в своей статье "Fast Computation of Terrain Shadow Maps" доступной по ссылке www.gamedev.net/reference/articles/article1817.asp. В своем классе я использовал именно подобный метод и, как он и просил, помещаю на него ссылку. Метод хорошо описан по-английски и я не вижу смысла повторять, то же что там уже сказано. Конечно, там приведена OGL реализация, но это не очень важно, как можно сделать под D3D вы можете посмотреть в исходниках. Ссылка на них есть в начале статьи. Конечно, для использования в реальном приложении метод нужно разделять (то есть обсчитывать в каждом кадре только небольшое количество точек, таким образом распределяя нагрузку на процессор). Кроме того, в реализации создается текстура для проективного текстурирования на объекты (которые, я надеюсь, появятся в следующей статье). Конечно, класс оставлять в том виде в котором он есть мы не можем. Поэтому к следующей статье нам необходим простенький редактор, позволяющий редактировать ландшафт в трехмерном виде. Он должен позволить задавать текстурные координаты треугольникам (а в случае Height-map, правильнее говорить "вершинам"), а также ставить в соответствие текстуры, которыми мы будем текстурировать конкретные треугольники. Свободное текстурирование ландшафта, так же как отсечение невидимых фрагментов ландшафта и вывод фрагментов в порядке Front-to-Back мы тоже рассмотрим в следующей статье.

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

Следующая статья будет посвящена рисованию окружения сцены, кроме того, мы начнем рисовать в сцене объекты, но пока они у нас будут статичными.

Автор: Константин "DreaDdog" Поздняков

Внимание!

В настоящее время Константин Поздняков, автор цикла статей "Разработка графического движка", выходит на свой послеучебный жизненный путь. Если вам нравится его подготовка, умение писать исходный код, и у вас есть возможность предложить Константину работу, то он с удовольствием рассмотрит любые варианты. Ваши предложения отправляйте по электронной почте Константину: dreaddog@rambler.ru.

Content

Ваткин Сергей и др DirectX 8. Начинаем работу с DirectX Graphics

GameDev.ru

DirectX 8: Начинаем работу с DirectX Graphics

DirectX 8: Создание и текстурирование простого трехмерного объекта

Первые шаги под DirectX 8. (Часть 1)

Первые шаги под DirectX 8. (Часть 2)

GameDev.net

2D Rendering in DirectX 8

DirectDraw The Easy Way

Разработка графического движка

#1: Введение

#2: Оптимизация Direct3D приложений

#3: Каркас графического приложения

#4: Ландшафт и интерфейс