Пишем легаси с нуля на С++, не вызывая подозрение у санитаров. 05 — GDI рендер

Приветствую, Хабравчане!

Основная репа RetroFan.

Так как проект пухнет строчками кода. Я встроил поддержку обработки ошибок. Так как я намеренно не использую исключения, то требуется некий альтернативный подход. Мне не очень нравится идеология принятая в Windows, libc или SDL2. При вызове функции, проверяют её возвращаемое значение и если значение соответствует коду ошибки, то для подробной информации об ошибке требуется вызвать функцию GetLastError.

И в принципе такой подход не плох, но меня беспокоит глобальность данной функции. Для упрощения обработки ошибок я создал класс Result.

namespace LDL { class Result { public: Result(); bool Ok(); const std::string& Message(); void Message(const std::string& message); void Message(const std::string& message, const std::string& detail); void Clear(); private: void Assert(const std::string& message); bool        _ok; std::string _message; }; }

И уже его передаю в конструктор тех классов, которые могут генерировать ошибки. К примеру класс окна.

LDL::Result result; LDL::Window window(result, LDL::Vec2i(0, 0), LDL::Vec2i(800, 600));      if (!result.Ok())     {         result.Message(); //Описание ошибки     }

Генерировать ошибки может всё, что угодно. К примеру WinAPI при рисовании линии. Но я понимаю, что никому не интересна обработка ошибок особенно при написании игр, главное при возникновении ошибки проинформировать пользователя, а игру или программу всегда можно перезапустить.

Поэтому я добавил такой вариант.

void Result::Message(const std::string& message) { _ok = false;  _message = message;  Assert(_message); }   void Result::Assert(const std::string& message) { puts(message.c_str()); abort(); }

Если в result была запись об ошибке, то выводим её и прекращаем выполнение программы. Плюсы у такого подходы есть, главный простота. В будущем добавлю такое поведение опциональным, если опция включена все ошибки ассертим, если нет просто возвращаем описание ошибки.

Обернул функцию Windows GetLastError в класс.

const std::string& WindowError::GetErrorMessage() {     DWORD ident = GetLastError();     assert(ident != 0);      LPSTR buffer = NULL;      size_t size = FormatMessageA(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, ident, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPSTR)&buffer, 0, NULL);      _message.append(buffer, size);      LocalFree(buffer);      return _message; }

И обработка ошибки WinApi выглядит так:

_activePalette = CreatePalette(&gdiPalette.logPalette);  if (_activePalette == NULL) { _result.Message(_windowError.GetErrorMessage()); }

_result и _windowError это члены класса.

Теперь двигаемся в сторону рендера. Пришлось немного почитать документацию по WinApi:) И если забежать вперед, задуманное работает. Я создал два рендера для GDI.

1. Рендер умеющий выводить RGB/A и палитровые изображения конвертируя их в RGB.

2. Рендер выводящий и работающий только с палитровыми изображениями.

RGB рендер.

Код лежит в GdiRndr.cpp

namespace LDL { class GdiTexture;  class GdiRender { public: GdiRender(Result& result, MainWindow& window); GdiRender(Result& result, MainWindow& window, const Palette& palette); ~GdiRender(); const Palette& GetPalette(); const Color& GetColor(); void SetColor(const Color& color); void SetColor(uint8_t index); void Begin(); void End(); void Clear(); void Line(const Vec2i& first, const Vec2i& last); void Fill(const Vec2i& pos, const Vec2i& size); void Draw(GdiTexture* texture, const Vec2i& dstPos, const Vec2i& dstSize, const Vec2i& srcPos, const Vec2i& srcSize); void Draw(GdiTexture* texture, const Vec2i& pos); void Draw(GdiTexture* texture, const Vec2i& pos, const Vec2i& size); const HDC Hdc(); private: MainWindow& _window; BaseRender  _baseRender; Result&     _result; WindowError _windowError; Palette     _palette; }; }

Нам интересна функция Draw. Для вывода изображений используется именно она, остальные функции вызывают ёе с разными аргументами.

void GdiRender::Draw(GdiTexture* texture, const Vec2i& dstPos, const Vec2i& dstSize, const Vec2i& srcPos, const Vec2i& srcSize) { assert(texture != NULL);  HDC hdcm = CreateCompatibleDC(_window.Hdc());  if (hdcm == NULL) { _result.Message(_windowError.GetErrorMessage()); } else { HGDIOBJ object = SelectObject(hdcm, texture->Bitmap());  if (object == NULL) { _result.Message(_windowError.GetErrorMessage()); } else { if (texture->GetColorKey().Used()) { Color color = texture->GetColorKey().GetColor();  if (TransparentBlt(_window.Hdc(), dstPos.x, dstPos.y, dstSize.x, dstSize.y, hdcm, srcPos.x, srcPos.y, srcSize.x, srcSize.y, RGB(color.r, color.g, color.b)) == FALSE) { _result.Message(_windowError.GetErrorMessage()); } } else { if (StretchBlt(_window.Hdc(), dstPos.x, dstPos.y, dstSize.x, dstSize.y, hdcm, srcPos.x, srcPos.y, srcSize.x, srcSize.y, SRCCOPY) == FALSE) { _result.Message(_windowError.GetErrorMessage()); } }  DeleteDC(hdcm); } } }

Всего 40 строк кода для вывода, всех типов изображений, в том числе с прозрачностью. Главные функции отвечающие за рисование это:

TransparentBlt — копирует загруженные пиксели из озу с учетом цвета альфы.

StretchBlt — копирует загруженные пиксели из озу без учета альфы.

Данные функции поддерживаются в Windows 95, 98. Для Windows 3.1 нужно будет найти альтернативу. Ну и ещё данные методы могут иметь аппаратное ускорение. В зависимости от драйвера и видеокарты.

Обернул API GDI текстур в свои абстрактные текстуры. Класс получился небольшим.

namespace LDL { class GdiRender;  class GdiTexture { public: GdiTexture(Result& result, GdiRender* render, const Vec2i& size, uint8_t bpp, uint8_t* pixels); GdiTexture(Result& result, GdiRender* render, const Vec2i& size, uint8_t bpp, uint8_t* pixels, const Color& color); GdiTexture(Result& result, GdiRender* render, const Vec2i& size, uint8_t* pixels); ~GdiTexture(); const ColorKey& GetColorKey() const; const Vec2i& Size(); const HBITMAP Bitmap(); private: Vec2i       _size; GdiRender*  _render; HBITMAP     _bitmap; ColorKey    _colorKey; Result&     _result; WindowError _windowError; }; }

Реализация:

GdiTexture::GdiTexture(Result& result, GdiRender* render, const Vec2i& size, uint8_t bpp, uint8_t* pixels) :     _size(size),     _render(render),     _bitmap(NULL),     _result(result) {     assert(render != NULL);     assert(size.x > 0);     assert(size.y > 0);     assert(bpp == 3 || bpp == 4);     assert(pixels != NULL);      uint8_t* dstPixels = NULL;      _bitmap = CreateDib(_render->Hdc(), _size, bpp, (void**)&dstPixels);      if (_bitmap == NULL)     {         _result.Message(_windowError.GetErrorMessage());     }     else     {         PixelConverter conv;         conv.RgbToBgr(_size, bpp, pixels);          size_t bytes = _size.x * _size.y * bpp;         memcpy(dstPixels, pixels, bytes);          conv.BgrToRgb(_size, bpp, pixels);     } }

Текстура создается из массива RGB пикселей. Такой универсальный интерфейс позволяет пользоваться любыми библиотеками для загрузки изображений. Есть один момент который мне не очень нравится, но в реалиях единого API для всех систем, по другому сделать невозможно. При копировании пикселей в созданную текстуру, для Windows приходится преобразовывать RGB последовательность в BGR и после провести обратную процедуру. И в зависимости от размера изображения, скорость будет падать. Это сделано потому, что внутренняя реализация изображений в Windows хранится в BGR.

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

GdiTexture::GdiTexture(Result& result, GdiRender* render, const Vec2i& size, uint8_t* pixels) :     _size(size),     _render(render),     _bitmap(NULL),     _result(result) {     assert(render != NULL);     assert(size.x > 0);     assert(size.y > 0);     assert(pixels != NULL);      uint8_t* dstPixels = NULL;      _bitmap = CreateDib(_render->Hdc(), _size, _render->GetPalette(), (void**)&dstPixels);       if (_bitmap == NULL)     {         _result.Message(_windowError.GetErrorMessage());     }     else     {         size_t bytes = _size.x * _size.y;         memcpy(dstPixels, pixels, bytes);     } }

Палитра одна на рендер и задается в конструкторе Render. Это позволяет реализовать единый API для всех типов изображений.

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

Рендер на основе палитры.

Код находится в классе GdiPRndr.cpp

Данный рендер внутри себя используя примитивы Windows, реально создает палитру для окна

GdiPaletteRender::GdiPaletteRender(Result& result, MainWindow& window, const Palette& palette) : _window(window), _palette(palette), _hdcm(NULL), _result(result) { GdiPalette gdiPalette; GdiFill(gdiPalette, _palette);  _activePalette = CreatePalette(&gdiPalette.logPalette);  if (_activePalette == NULL) { _result.Message(_windowError.GetErrorMessage()); } }

Палитровое изображение создается так.

GdiPaletteTexture::GdiPaletteTexture(Result& result, GdiPaletteRender* render, const Vec2i& size, uint8_t* pixels) :     _size(size),     _render(render),     _bitmap(NULL),     _result(result) {     assert(render != NULL);     assert(size.x > 0);     assert(size.y > 0);     assert(pixels != NULL);      uint8_t* dstPixels = NULL;      _bitmap = CreateDib(_render->Hdc(), _size, _render->GetPalette(), (void**)&dstPixels);      if (_bitmap == NULL)     {         _result.Message(_windowError.GetErrorMessage());     }     else     {         size_t bytes = _size.x * _size.y;         memcpy(dstPixels, pixels, bytes);     } }

Текстура хранит индексы на палитру RGB. И при вывода на экран индексы преобразовываются в нормальный rgb цвет.

Главное ограничение в моей реализации, это поддержка одной глобальной палитры для рендера. Это сделано намеренно, что бы единый API мог работать на любых реализация, OpenGL, DirectX, Vulkan. В новых графических API просто отсутствует поддержка палитры.

К примеру в DOS’е палитра может быть изменена динамически, чем достигаются разные эффекты. На OpenGL, это не возможно. Поэтому, что обеспечить работу на старых и новых ПК, единая палитра может быть эмулирована на новых графических API, а на старых будет работать нативно.

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

Пример LDL_Pal.cpp

#define LDL_RENDER_NATIVE_PALETTE #include <LDL/LDL.hpp> #include <vector>  int main() { LDL::Palette palette;  palette.Set(0, LDL::Color(0, 0, 0)); palette.Set(1, LDL::Color(255, 255, 255)); palette.Set(2, LDL::Color(255, 0, 0)); palette.Set(3, LDL::Color(0, 255, 0)); palette.Set(4, LDL::Color(0, 0, 255)); palette.Set(5, LDL::Color(255, 255, 0)); palette.Set(6, LDL::Color(0, 255, 255));  LDL::Result result; LDL::Window window(result, LDL::Vec2i(0, 0), LDL::Vec2i(800, 600)); LDL::Render render(result, window, palette);  LDL::Event report;  const size_t imgSize = 100 * 100;  std::vector<uint8_t> buffer1(imgSize, 5); std::vector<uint8_t> buffer2(imgSize, 3);  LDL::Texture img1(result, &render, LDL::Vec2i(100, 100), &buffer1[0]); LDL::Texture img2(result, &render, LDL::Vec2i(100, 100), &buffer2[0]);  while (window.Running()) { while (window.GetEvent(report)) { if (report.Type == LDL::Event::IsQuit) { window.StopEvent(); } }  render.Begin();  render.SetColor(4); render.Fill(LDL::Vec2i(25, 25), LDL::Vec2i(100, 100));  render.Draw(&img1, LDL::Vec2i(0, 0)); render.Draw(&img2, LDL::Vec2i(150, 150));  render.End();  window.Update(); window.PollEvents(); }  return 0; }

Создаем палитру и инициализируем рендер.

LDL::Palette palette;  palette.Set(0, LDL::Color(0, 0, 0)); palette.Set(1, LDL::Color(255, 255, 255)); palette.Set(2, LDL::Color(255, 0, 0)); palette.Set(3, LDL::Color(0, 255, 0)); palette.Set(4, LDL::Color(0, 0, 255)); palette.Set(5, LDL::Color(255, 255, 0)); palette.Set(6, LDL::Color(0, 255, 255));  LDL::Result result; LDL::Window window(result, LDL::Vec2i(0, 0), LDL::Vec2i(800, 600)); LDL::Render render(result, window, palette);

Создаём текстуры с палитрой

const size_t imgSize = 100 * 100;  std::vector<uint8_t> buffer1(imgSize, 5); std::vector<uint8_t> buffer2(imgSize, 3);  LDL::Texture img1(result, &render, LDL::Vec2i(100, 100), &buffer1[0]); LDL::Texture img2(result, &render, LDL::Vec2i(100, 100), &buffer2[0]);

Выводим эту текстуру на экран.

render.Draw(&img1, LDL::Vec2i(0, 0)); render.Draw(&img2, LDL::Vec2i(150, 150));

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

Квадратики это конечно хорошо, но хотелось бы видеть всё же осмысленную графику. Вы хочете графику, она есть у меня 🙂

Пример вывода тайловой карты.

#include <LDL/LDL.hpp> #include <vector> #include <time.h> #include "Isometrc.hpp"  #if (_MSC_VER <= 1200)     #define STBI_NO_THREAD_LOCALS     #define STBI_NO_SIMD #endif  #define STB_IMAGE_IMPLEMENTATION #include "stb_image.h"  const LDL::Vec2i tileSize = LDL::Vec2i(128, 64); const LDL::Vec2i mapSize  = LDL::Vec2i(7, 7); const LDL::Vec2i startPos = LDL::Vec2i(300, 50);  int Random(int min, int max) { return min + (rand() % (max - min + 1)); }  int main() { srand((uint32_t)time(NULL));  LDL::Result result; LDL::Window window(result, LDL::Vec2i(0, 0), LDL::Vec2i(800, 600)); LDL::Render render(result, window);     LDL::Event  report;  stbi_set_flip_vertically_on_load(true);  int width, height, channels; unsigned char* pixels = stbi_load("SeasonsTiles.png", &width, &height, &channels, STBI_default); LDL::Texture tiles(result, &render, LDL::Vec2i(width, height), channels, pixels, LDL::Color(0, 0, 0)); stbi_image_free(pixels);  Isometric isometric;  std::vector<int> tilesX; std::vector<int> tilesY;  tilesX.resize(mapSize.x * mapSize.y); tilesY.resize(mapSize.x * mapSize.y);  for (size_t i = 0; i < mapSize.x * mapSize.y; i++) { tilesX[i] = Random(0, 7); tilesY[i] = Random(0, 5); }  while (window.Running()) { while (window.GetEvent(report)) { if (report.Type == LDL::Event::IsQuit) { window.StopEvent(); } }  render.Begin();  size_t j = 0;  for (size_t rows = 0; rows < mapSize.x; rows++) { for (size_t cols = 0; cols < mapSize.y; cols++) { int x = (int)cols * tileSize.x / 2; int y = (int)rows * tileSize.y;  LDL::Vec2i pt = isometric.CartesianToIsometric(LDL::Vec2i(x, y));  int tx = tileSize.x * tilesX[j]; int ty = tileSize.y * tilesY[j]; j++;  render.Draw(&tiles, LDL::Vec2i(startPos.x + pt.x, startPos.y + pt.y), tileSize, LDL::Vec2i(tx, ty), tileSize); } }  render.End();  window.Update(); window.PollEvents(); }      return 0; } 

Надеюсь, что статья вам была интересна. Я понимаю, что рассказ о старых технологиях это не всегда увлекательно. Но знаете, в этом есть некое очарование. Ведь эти API и подходы, зарождались в то время когда ПК обладали смешными характеристиками по текущим меркам.

Оцените масштаб трагедии, какая производительность сейчас и тогда.

А пользователи требовали, игр, софта, да графику понажористее -:)

На данный момент, рендер стал довольно функционален. В следующей статье опишу реализацию рендера на основе библиотеки XLib. Физически не успеваю реализовать две версии и всё описать в одной статье.

И уже после, двинемся покорять рендеры на основе буфера памяти в ОЗУ с рисованием силами ЦП, OpenGL и т. д.

За кулисами, пока портирую LDL на Windows 3.1. Для этого все исходные файлы именуются максимум в 8 символов. Хочется собрать нативно.

Буду рад предложениям, советам, критике и пообщаться в комментариях.

Обновление:

Удалось портировать под Windows 3.1, но пока без поддержки изображений, только вывод примитивов.