Приветствую, Хабравчане!
Основная репа 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.
Рендер умеющий выводить RGB/A и палитровые изображения конвертируя их в RGB.
Рендер выводящий и работающий только с палитровыми изображениями.
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, но пока без поддержки изображений, только вывод примитивов.


