Разработка игры. Бродилка. [Лог#7]

Темой этого лога станет рендер. Расскажу немного о том как я себе представляю виртуального художника и почему лучше реализовать интерфейс IRender и класс-реализацию CRenderOGL, например.

Хочется провести некоторые аналогии, которые по моему очень чётко вписываются.
Класс «рисовальщик» именовал я раньше как RenderDevice, но что это такое вообще? Зачем какие-то классы городить, когда есть, например, OpenGL? Конечно для удобства использования.
Класс IRenderDevice можно назвать художником, причём очень хорошо ему это имя подходит.
Можно сказать художнику «нарисуй мне вот тут квадрат», собственно это было бы эквивалентно такому вот вызову в коде «pRenderDevice->DrawQuad(… )».
Художник не может нарисовать ничего, если у него нет холста, красок и кистей, и тут вновь можно провести аналогию.
Роль холста будет играть «контекст устройства»( как я понимаю это просто особая видеопамять, вернее её часть) — имеется у всех окон. Тут всё ясно холст — окно.
Кисти или их эквивалент — модели и геометрия, даже не имеет значения 2Д или 3Д. Возможно, кто-то знает, что геометрия(статичная?) в играх на движке Source, idTech и UnrealEngine называется Brush ( кисть ) — наверно просто совпадение, не думаю.
Кисть по холсту художник проведёт, но ничего не нарисует, поэтому нужны краски — текстуры, материалы, шейдеры (shaders). Думаю многие знают что из себя представляет шейдер — это подпрограмма для видеокарты, которая говорит как будет рисоваться 3Д модель. Экранный пост-процессы \ пост-эффекты — это тоже шейдер, например, свечение (glow, bloom), переход картинки в серость\цвет ( такой эффект был в игре Saboteur ).

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

Примерно вот так может выглядеть класс, вернее интерфейс для «художника»:

У методов этого класса нет реализации (конкретного кода) и они все виртуальные. Видно, что несколько первых методов — это инициализация, обновление кадра и освобождение ресурсов ( Init, SwapBuffer и Cleanup соответственно) — эти функции платформозависимые, что не есть хорошо вообще то. Но можно чуть-чуть избавится от зависимости «спрятав» зависимые от платформы типы и функции, например, тип переменной WindowT — произвольный (определённый мной, а не платформой), внутри которого есть платформозависимые переменные. Это сделано для того, чтобы не менять вызов функции, например:
// Этот код не нужно будет менять для каждой платформы
pRenderDevice->Init( pMainWindow, 0 );

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

Последние три функции интерфейса IRenderDevice — «применить вид», «установить материал» и «нарисовать модель». Конечно это не полный список функций, который пригодится, но для очень простых игр думаю даже такого хватит.
Функция ApplyView, которая принимает указатель на некий объект класса GView — особая штука, которой я можно сказать горжусь (хотя на самом деле нечем). GView — это что-то вроде виртуальной камеры, границ вида (вьюпорт \ viewport ) и матрицы проекции. Хранит в себе две матрицы — проекции (перспективная\ортогональная) и вида (положение и направление камеры).

Классы материала и сетки(mesh) вообще могут быть какими угодно, вернее информация которая в них хранится может быть различной и зависеть от «старшей» графической библиотеки (OpenGL \ DirectX).

Но не только материал и 3Д модель зависит от выбора библиотеки, собственно вся реализация интерфейса зависит от неё. Вот например если взять OpenGL, то может быть что-то вроде этого:

Видно, что функций больше, да и переменные появились. (не забывайте, что это примеры, а в реальном проекте будет иначе). Можно создавать экземпляр этого класса и пользоваться всеми этими функциями, однако, если нужна независимость от OpenGL\DirectX, то нужно использовать IRenderDevice у которого функций меньше. Зачем тогда использовать этот урезанный класс? Дело в том, что реализацию художника можно загружать из DLL (если это реализовано, конечно), например, так сделано в Quake2 — рендер и механика игры загружаются из DLL.

Ну вот скажем та же функция ApplyView для OpenGL реализации будет выглядеть примерно так:

Для DirectX реализации были бы совсем другие функции, но смыл бы не изменился.
Поэтому вызывая pRenderDevice->ApplyView( pView ) будет срабатывать специфичный код.

Честно говоря не очень хорошо получается у меня объяснить весь смысл, да что там — вообще не понятно что я тут написал :D

Конечно хотелось бы больше конкретного кода, но не учитель я :(
Да ещё и версия OpenGL, которую я ранее и использовал устарела, теперь придётся чуть обновить свои знания и подтянуть версию хотя бы OpenGL 3.3.

Что дальше ?
Думаю либо чуть увеличить разрыв между логами, либо небольшую паузу взять. Думаю начать уже конкретно проектировать само приложение (не писать код) и сделать небольшой альфа-прототип на каком-нибудь Unity (хотел вообще на GameMaker, но похоже с новым обновлением они отказались от WinXP — Steam отказывается запускать GM).

Заметьте ни одной картинки D:!