Пишу фреймворк LDL, аналог SDL но на С++ и с поддержкой старых систем

[JordanCpp]

Тема перекочевала с дружественного сайта old-games.ru

Приветствую!

Пишу фреймоврк для разработки софта или игр. Идею взял из библиотеки SDL, но пишу на С++.
Главная идея это кроссплатформенность, производительность и поддержка старых и новых систем.

На данный момент фреймворк работает начиная с Windows 95 и Debian Linux 3.

Идея зародилась после написания статьи. Если критикуешь, предлагай, а предлагая делай.
В софте все всрато и становится еще всратее

Сатья о фреймворке на хабре. Немного устарела.

Сам проект. Лицензия boost. На гитхабе есть примеры и скриншоты.
GitHub - JordanCpp/Lib-LDL

Особенности проекта.

Поддержка старых систем 25+ лет.
Модульный дизайн.
Динамическая загрузка рендера при запуске приложения.
Весь код написан на С++ 98, для поддержки большего числа компиляторов и систем. Но разработчик, может использоать любой стандарт языка, хоть С++ 23. Ограничение есть лишь у меня как у разработчика фреймворка.
Высокоуровневый ООП API. Есть возможнось заюзать свои кастомные аллокаторы.
Поддержка старого железа 25+ лет.
Производительность.
Минимальная внешняя зависимость.
Проект собирается следующими компиляторами.
Windows: Visual C++ 6.0 и выше вплоть по MSVC 2022 (На нём под Windows и разрабатываю), OpenWatcom v2
Linux: gcc начиная с версии 3 и выше.

В проекте есть тесты, но пока нет документации.

Что сделано:
1. Статическая и динамическая линковка фреймворка.
2. Реазизована поддержка 2D API.
3. Реализована поддержка звука
4. Рендер OpenGL 1.2, OpenGL 3.3, Sowfware рендер.
5. Загрузка графических форматов png,bmp, tga, jpeg и т.д
6. Загрузка звуковых форматов mp3,wav, ogg, и т.д

Мои желания по общей архитектуре:
1. На сколько возможно, делать api и внутренний код простым.
2. Максимальная производительность.
3. Упростить работу с аллокаторами памяти.
4. Создавать библиотеку общего назначения(графичесйи интерфей, звук и т.д)
5. Сделать аналог Qt но на минималках.

На своём фреймворке начал проект по реализации движка игры Arcanum.

[JordanCpp]

Выступил на конференции по С++ 2023 с темой: Вперед в прошлое, или Разрабатываем фреймворк под Windows 95 в 2023 году

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

Мне нравится не только юзать старые железки, но и под них программировать.

Ещё доп информация:

Я как раз этого и добиваюсь. Сейчас движок используя только API фреймворка, собирается и работает идентично на windows и linux. Чем больше я буду обеспечивать поддержку других систем, тем больше проектов на LDL будут на них одинаково работать. Просто нужно будет перекомпилировать под систему, не переписывая код.

Есть проблемы которые невозможно решить.

1. Это поддержка кодировки в системе.
К примеру берем windows 95 она не поддерживает unicode. Есть такой вариант. Windows 95 c поддержкой русской и английской локали будет работать с английским и русским юникодом без специальных знаков если конвертировать данную строку в acsii строки, согласно локали. Но если это будет другая локаль к примеру unicode на греческом языке, данную строку невозможно конвертировать в acsii. В итоге мы можем работать с юикодом в системе, но только если она совпадает с локалью. Это актуально для функционала который получает и отправляет текстовые данные в систему. Удалить файл по имени, переименовать, выбор файла и т.д Если для таких целей использовать только английский, то проблем нет.

Фреймворк поддерживает freetype и может выводить на экран любой юникод, так как текст это просто изображение.

2. Тема многопоточного кода.
Такой код не будет работать на старых операционных системах. Если требуется обеспечить работу начиная с windows 95, только одно ядро.

3. Функционал которого нет в старых ОС, поддержка мультитач, дополнительное управление дисплеем, DPI и т.д Для обеспечения возможности сборки фреймворка для старых систем, будут реализованы заглушки, которые ничего не делают. Пример это поддержка прокрутки колесиком мыши. Его можно задействовать в коде, но на Windows 95 работать не будет.

Если писать под современные операционные системы, ограниений нет.

[ATauenis]

Интересный проект. Хоть, сам я не С++ разработчик, но приветствую развитие таких библиотек. Будет интересно, если под старые платформы появятся новые игры или софт какой-то. Лишь бы по производительности прошло - удел той же Windows 98 это всякие Slot1/A, Socket 370 системы. А 95, так, вообще от топовых 386 и выше. Кстати, как там с поддержкой WinNT 3/4?

2. Тема многопоточного кода.
Такой код не будет работать на старых операционных системах. Если требуется обеспечить работу начиная с windows 95, только одно ядро.

Многопоточность бывает разной. Распараллелить код, чтобы одновременно выполнялось несколько подпрограмм/функций, и ещё оставался отзывчивым интерфейс, можно было на любой ОСи. Даже в Visual Basic был зловещий DoEvents(), позволявший замутить подобие многопоточности (с производительностью, конечно, был полный атас, но оно работало, особенно, после подбора мест, куда этот костыль пхать).

DPI

Те же форточки или OS/2 с незапамятных времён умеют работать при разном разрешении. Только криво.

колесиком мыши. Его можно задействовать в коде, но на Windows 95 работать не будет.

IntelliMouse ж есть.

[JordanCpp]

Кстати, как там с поддержкой WinNT 3/4?

Не проверял, но постараюсь проверить в виртуалке. Никогда эти системы не использовал.

Те же форточки или OS/2 с незапамятных времён умеют работать при разном разрешении. Только криво.

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

IntelliMouse ж есть.

Я читал в какой то книге, не могу вспомнить (Программирование под Windows 3.1), автор описывал какую то библиотеку для поддержки колесика.

Многопоточность бывает разной. Распараллелить код, чтобы одновременно выполнялось несколько подпрограмм/функций, и ещё оставался отзывчивым интерфейс, можно было на любой ОСи. Даже в Visual Basic был зловещий DoEvents(), позволявший замутить подобие многопоточности (с производительностью, конечно, был полный атас, но оно работало, особенно, после подбора мест, куда этот костыль пхать).

Это нужно обдумать, я пока не приступал к поддержке многопоточности именно фреймворка. Использовать примитивы того же С++11 возможно и всё будет работать, но не переносимо на старые операционные системы.

[JordanCpp]

Будет интересно, если под старые платформы появятся новые игры или софт какой-то.

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