Новый игровой движок

Сделал форк движка с поддержкой Windows 9x(95,98,ME).
Ссылка на форк - GitHub - PopovEvgeniy/neongdk: Neon game development kit is an ultra-fast 2D game engine for Windows 95 or higher. It uses OPENGL for render

 

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

Если найдете время поделитесь мыслями насчет проекта. Буду рад конструктивной критики.

 

Выпущено обновление движков с исправлением багов и небольшими улучшениями в API.

 

API движков стабилизирован и не будет сильно изменяться в дальнейшем.

 

Выпущено обновление движка с добавлением возможности зеркального отображения видимых объектов.

 

Движок был протестирован в Linux и стабильно работает под Wine 6.0.3.

 

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

 

Сделал ответвление движка под Linux. Ссылка на репозиторий: GitHub - PopovEvgeniy/bird2d: Bird 2d is an ultra-fast 2D game engine for Linux. It uses OPENGL for render

 

Может лучше обмазать версионирование #ifdef'ами? Одна кодовая база, с возможностью собрать под разные ос.

 

@Jordan 63, вы конечно правы. Но есть мелкие детали которые делают мой подход удобным. Код можно разделить на кросс-платформенный слой и модули зависимые от конкретной операционной системы. При вашем подходе код таких модулей получается более трудным для сопровождения.

 

Поделитесь в чём сложность сопровождения зависимых модулей.

Единственное различие с вашим кодом, что у меня в каталоге platforms несколько файлов по конкретному функционалу, окно, событие, время и т.д У вас всё в одном файле, но суть не меняется.

К примеру с чем я сталкивался когда я организовал несколько рендеров через ifdef, я забывал реализовать новый метод в других рендерах и при переключении через #define код не собирался и писал что метод отсутствует.

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

Я не упорствую, как вам комфортно, так и разрабатывайте. У меня после программирования на С#, есть привычка каждый класс выделять в отдельный файл. Проф деформация

 

@Jordan 63, когнитивная сложность при поддержке нескольких платформ в зависимых модулях через блоки #ifdef резко возрастает.

 

Выпущено обновление варианта движка под Linux с добавлением возможности проигрывания аудио-файлов.

 

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

 

Посмотрел, здорово. Мне нравится ваш движок. Но, что не могу принять всё в одном файле. Классы движка так и напрашиваются, что бы быть в своих файлах и namespace' ах.

Обязательно продолжайте.

 

@Jordan 63, спасибо. В двух файлах, но не суть. Ничего идеального нет. Такой подход хоть и имеет недостатки, но тем не менее имеет право на существование. В качестве примера его применения можно назвать stb_image, который вы используйте в качестве зависимости.

 

@Bobbie у меня С# синдром, каждый класс в своём файле и namespace

stb_image клёвый, но всё навалено в кучу.

 

Выпущено обновление движков с добавлением поддержки изометрии.

 

В движках доработан и улучшен API.

 

Оптимизировал загрузчик текстур.