Стэн Трухильо - Графика для Windows средствами DirectDraw

Каждый элемент буфера представлен структурой DIDEVICEOBJECTDATA. Эта структура используется независимо от типа устройства, поэтому ее поля были сделаны универсальными. DirectInput определяет структуру DIDEVICEOBJECTDATAследующим образом:

typedef struct {

DWORD dwOfs;

DWORD dwData;

DWORD dwTimeStamp;

DWORD dwSequence;

} DIDEVICEOBJECTDATA, *LPDIDEVICEOBJECTDATA;

Для мыши поле dwOfsопределяет тип события. В DirectInput определены следующие константы, описывающие ввод от мыши:

• DIMOFS_X

• DIMOFS_Y

• DIMOFS_Z

• DIMOFS_BUTTON0

• DIMOFS_BUTTON1

• DIMOFS_BUTTON2

• DIMOFS_BUTTON3

Программа Smear реагирует только на перемещение мыши по осям xи y, поэтому после вызова функции GetDeviceData()поле dwOfsсравнивается с константами DIMOFS_Xи DIMOFS_Y.

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

Поля dwTimeStampи dwSequenceсодержат информацию о том, когда произошло данное событие. Поле dwTimeStampопределяет время в миллисекундах (о том, как интерпретируется эта величина, можно подробно узнать в описании функции Win32 GetTickCount()). Поле dwSequenceопределяет порядок наступления событий. События с меньшими номерами наступили раньше, однако несколько событий могут иметь одинаковые порядковые номера. Например, если мышь или рукоять джойстика смещается по диагонали, события для координат x и y будут иметь одинаковые номера.

Вернемся к функции DrawScene(). Цикл ввода извлекает элементы буфера до тех пор, пока буфер не опустеет. Этот цикл выглядит так:

while (!done) {

DIDEVICEOBJECTDATA data;

DWORD elements=1;

HRESULT r=mouse->GetDeviceData(sizeof(data), &data, &elements, 0);

if (r==DI_OK && elements==1) {

switch (data.dwOfs) {

case DIMOFS_X:

x+=data.dwData;

break;

case DIMOFS_Y:

y+=data.dwData;

break;

}

} else if (elements==0) done=TRUE;

}

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

Если вызов функции прошел успешно и значение elementsосталось равным 1, значит, элемент буфера был прочитан, а поля dwOfsи dwDataопределяют тип события. Нулевое значение elementsговорит о том, что буфер пуст и цикл завершается.

После извлечения всех элементов буфера остается лишь вывести поверхность в позиции, определяемой переменными xи y. Для этого используется функция BltSurface():

BltSurface(primsurf, sphere, x, y, TRUE);

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

Перед завершением приложения MFC вызывает функцию OnDestroy(); мы воспользуемся ею для освобождения объектов DirectInput. Функция OnDestroy()выглядит так:

void SmearWin::OnDestroy() {

DirectDrawWin::OnDestroy();

if (dinput) dinput->Release(), dinput=0;

if (keyboard) {

keyboard->Unacquire();

keyboard->Release(), keyboard=0;

}

if (mouse) {

mouse->Unacquire();

mouse->Release(), mouse=0;

}

}

Функция OnDestroy()просто освобождает каждый объект DirectInput (и вызывает одноименную функцию базового класса).

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

В следующей главе мы займемся одной неприятной проблемой, связанной с курсором мыши. Как вы вскоре убедитесь, DirectInput станет неотъемлемой частью ее решения.

Если вы пытались работать с мышью в полноэкранном приложении DirectDraw, скорее всего, проблема с курсором вам уже знакома. Ввод от мыши нетрудно получить и использовать в программе, пока не приходится отображать курсор на экране. Но попробуйте-ка вывести стандартный курсор Windows — и проблема заявит о себе.

Первая трудность связана с переключением страниц. Если курсор мыши не был отключен, Windows не подозревает о том, что видеоустройства находятся под управлением DirectDraw, и выводит курсор мыши на поверхности GDI. Если поверхность GDI скрыта, а вместо нее на экране отображается другая поверхность, курсор исчезает. Эта переменчивость приводит к тому, что курсор мыши мерцает и выглядит полупрозрачным.

Более того, курсор может оказаться искаженным или вообще отсутствовать. Например, в видеорежимах Mode X используется нелинейная организация пикселей. Windows пытается вывести курсор мыши, но поскольку режимы Mode X не поддерживаются Windows GDI, изображение курсора портится. Кроме того, Windows не умеет выводить курсор мыши на вторичных видеоустройствах (например, на видеокартах с чипами 3Dfx). Вывод продолжает поступать на первичное видеоустройство независимо от того, какое устройство активно в данный момент, поэтому курсор мыши пропадает.

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

Раз курсор мыши отображается самим приложением, а не Windows, частота его прорисовки зависит от быстродействия приложения. Если приложение постоянно работает на 75 FPS, это будет приемлемо, но что если частота вывода кадров упадет до 30 FPS и ниже? С падением частоты курсор будет все медленнее реагировать на действия пользователя.

Существует множество причин, по которым приложение может иметь низкую частоту вывода кадров. Трехмерные приложения предъявляют особенно жесткие требования к системе и часто работают с частотой 30 FPS и менее. Но «тормозить» могут и обычные, не трехмерные приложения. Сложное приложение, выводящее сотни объектов, будет иметь низкий FPS (конечно, все зависит от компьютера и видеокарты). Кроме того, режимы High и True Color часто оказываются намного медленнее 8-битных режимов.