Игровой движок

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

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

Для перехвата окна чужого приложения использовались так называемые «ловушки»(Window Hooking).

Разработка отладочной консоли

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

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

Консоль должна была релизовывать достаточно простой но необходимый функционал:

· Отображение отладочной информации в окне в реальном времени

· Выполнять команды

· Быть просто и удобной в эксплуатации

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

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

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

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

Команды в консоле может регистрировать любая подсистема движка. По этому было важно избежать путаницы среди команд и сделать так что бы и другие разработчики могли понимать назначения и использовать команды реализованные их коллегами. Для этого в принудительном порядке при регистрации любой новой команды обязательным условием было описание ее функционала по определенному шаблону. Которое можно было посмотреть в консоли выполнив командe «help» передав ей в качестве параметра имя другой команды. Ниже я приведу приме регистрации процедуры в консоли и переменной:

Console::RegComProc("quit","Quits engine and releases all resources.",&conquit);

Console::RegComValue("fps_in_caption","Displays current fps value in window caption.",&fps_to_caption,0,1);

Конечно, функционал консоли не ограничивается этими возможностями, но они являются основными.

На рисунке 6 я привожу скриншот консоли в процессе выполнения отладки.

Рис. 6 Консоль в процессе отладки

Таким образом был разработан достаточно удобный инструмент отладки системы в реальном времени.

Разработка системы сообщений

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

Требуемая для движка система событий должна обладать следующими основными свойствами:

· ООП архитектуру

· Возможность передавать любое количество параметров любого типа

· Совместимость с другими языками, а именно Delphi и C#

· Для получения и обработки сообщений подсистемы ничего не должны знать друг о друге

· Высокое быстродействие т.к. поток сообщений может быть очень большим

Для удовлетворения всех описанных выше требовании было принято решения о реализации системы сообщений на основе интерфейсов.

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

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

Ниже я привожу пример генерации ядром некого события:

IWinEvent *wEvent = new WinEvent(EV_WIN_MESSAGE, message, wParam, lParam);

wEvent->Send();

wEvent->Release();

Это событие создается когда окно движка получает какую либо Win32 сообщение операционной системы. Интерфейс IWinEvent понаследован от стандартного интерфейса IEvent. Далее любая подсистема подписавшаяся на сообщение EV_WIN_MESSAGE получит его и сможет обработать в своем обработчике, выглядеть это будет примерно так:

void CWinAPI_Input::MessageProc( IEvent* Event )

{

UINT message = NULL;

WPARAM wParam = 0;

LPARAM lParam = 0;

IWinEvent *wEvent = dynamic_cast<IWinEvent *>(Event);

wEvent->GetParam(&message, &wParam, &lParam);

}

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

Реализация основной файловой системы

Основная файловая система должна обеспечивать предоставление другим подсистемам файлы в универсальном формате, для этого были определены специальные интерфейсы. IFTexture, например, содержит в себе универсальный формат в который можно записать практически любой тип текстуры. Для других подсистем были реализованы схожие интерфейсы. К основной файловой системы подключаются плагины реализующие загрузку файлов различного формата и осуществляющих работу с паками и физически с фалами на диске. По этому вся задача основной файловой системы сводится к тому что бы передавать соответствующие интерфейсы между плагинами самой файловой системы и подсистемами движка. К примеру, что бы загрузить текстуру из пака сначала будет определен плагин, который работает с этим типом файлов, если он найден, то запрос будет переадресован ему. Этот плагин обработав запрос возвращает универсальный интерфейс IFile в основную файловую систему, далее файловая система ищет другой плагин который реализует загрузку такого рода текстур и если он найден, то передает этот интерфейс ему. Теперь уже этот плагин выполняет обработку файла и формирует универсальный интерфейс текстуры IFTexture, который он возвращает основной файловой системе. Основная файловая система уже перенаправляет его подсистеме рендеринга, которая осуществляет загрузку, после чего интерфейс IFTexture освобождается из памяти.

На рисунке 7 приведена схема файловой системы DPE.

Рис. 7 Схема файловой системы DPE

Реализация системы перехвата не обрабатываемых исключений

Библиографический список