Двойная буферизация

В настоящий момент перерисовка изображения во время манипуляций мышью очень плохая, так как мы работаем с одним (front) буфером. Пора подключать второй. Вместо вызова glFlush; вставьте вызов функции glutSwapBuffers из другой библиотеки, которая, как вы помните, не документирована. Но этого мало — надо заменить волшебное слово SINGLE на не менее волшебное слово — DOUBLE. Местоположение вычислите самостоятельно.

Поиск места вынуждает прокручивать в голове последовательность вызовов функций, что является полезным, а для многих и необходимым упражнением. После этого запустите приложение и отметьте, что управляемость кубика улучшилась, но при достаточно большом его повороте вокруг оси Y, поворот вокруг оси X ведет себя так, как будто сама ось «повернута». Если вы поменяете порядок вызова двух функций вращения glRotated, то эффект останется, но проявит себя в симметричном варианте. Подправьте это, если хотите. Хорошая задача на сообразительность, так как не требует специфических знаний языка программирования, а только общих представлений о сути преобразований и возможностях библиотек OpenGL.

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

Покажем, как добавить реакции на нажатия клавиш клавиатуры. Задействуйте клавиши стрелок для смещения объекта в плоскости Z = const. Введите в main декларацию обработчиков:

glutSpecialFunc (OnSpecialKey);

glutKeyboardFunc(OnKey);

Первая функция привязывает событие нажатия специальных клавиш с функцией OnSpecialKey, а вторая ­­— событие нажатия обычных клавиш с функцией OnKey. Сигнатура обработчика OnKey такова.

void OnKey (unsigned char ch, int x, int y)

{

switch (ch)

{

case 27: exit(0); break;

}

glutPostRedisplay();

}

Сигнатура обработчика OnSpecialKey такова

void OnSpecialKey (int key, int x, int y)

{

switch (key)

{

case GLUT_KEY_LEFT: /* Ваш код */ break;

case GLUT_KEY_RIGHT: /* Ваш код */ break;

case GLUT_KEY_DOWN: /* Ваш код */ break;

case GLUT_KEY_UP: /* Ваш код */ break;

}

glutPostRedisplay();

}

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

Вы, конечно, заметили, что при изменении размеров окна, несмотря на включенный режим двойной буферизации, изображение моргает (flickers). Это происходит потому, что после обработки WM_SIZE система автоматически посылает сообщение WM_PAINT, а перед каждой перерисовкой наш каркас автоматически посылает сообщение WM_ERASEBKGND, обработка которого происходит в недрах каркаса (мы не управляем этим процессом). В обработчике WM_ERASEBKGND происходит стирание всего содержимого окна. Именно это и приводит к морганию. Во всех технологиях flicker-free drawing, а их несколько, либо отказываются от обработки WM_ERASEBKGND, либо берут его в свои руки. Используемый нами каркас не дает нам возможности ввести обработку указанного сообщения и исправить ситуацию, на этом я и успокоился.

Но на этом не успокоился наш студент Денис Сорока, он вспомнил, что в этом каркасе нам доступны все функции API, в том числе и SetWindowLong, которая позволяет заменить оконную процедуру, зарегистрированную системой для нашего приложения. В новой версии оконной процедуры он вводит ветвь обработки нужного нам сообщения (WM_ERASEBKGND), в которой отказывается от стирания фона (return TRUE;). При этом важно то, что все остальные сообщения должны быть обработаны так же, как и ранее, то есть старой оконной функцией. Оказывается, она не потерялась — функция SetWindowLong возвращает адрес текущей оконной процедуры в момент обращения. Если вы поняли алгоритм, попробуйте повторить тот путь, который прошел Денис Сорока.