Сохранение информации о выполнении приложения в файл протокола. Эта реализация не принадлежит мне, автора я не знаю, но все равно хочется сказать ему спасибо. Стандартная качественная реализация. Исходник поставлялся с одним из примеров 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/Другое).

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

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

Были исправлены куча ошибок и приложение начало работать устойчивей. Предвидя проблемы с инициализация "правильного" графического приложения, я создал утилиту, которая позволяет выбрать графический режим работы из списка доступных для данной видеокарты и в нем запустить приложения. Там вы можете посмотреть как нужно правильно (ну может и не правильно, но вроде работает), определять доступные режимы на конкретной видеокарте. Не реализованы в утилите, например, ограничения самого приложения, то есть в терминах каркаса "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> (конечно, можно было использовать следующий способ:

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

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

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