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

то он будет летать на новом.

в корне не согласен — в части того, что сейчас можно сделать куда более высокопроизводительный код современными средствами.

Когда ПО поставляется одним куском, в виде прошивки например, а для старых систем это может быть актуально, то и к LGPL могут возникнуть вопросы.

Насколько я понимаю, это решается предоставлением законному получателю ПО объектных модулей проприетарной части.

Смотрел код этого проекта год назад и ныне.
Слабенько всё.
До того, чтобы этот API использовать его ёщё пилить и пилить.
Пока это лишь fun для понимания того, как работать с мультимедия.
ИМХО толку не будет пока у ТС не появится реальная мотивация к тому, чтобы разработать API, который будет полезен для других.

ещё и обман других. Тут нет никакого здравого смысла

Я бы не был столь категоричен. Поддержка старого железа, это всего лишь фича, фреймворка.

Это не всегда так. Например, ты можешь написать вылизанный код для старого одноядерного процессора, выжимающий максимум из его производительности. Но на современном процессоре он может оказаться тормозом из-за того, что не сможет распараллелить вычислительную задачку на несколько ядер.

Поддержка фич конктретной платформы, скрыта за API. Мне понравилась цитата Таненбауме. Пишу по памяти. Если фича есть в железе и она ускоряет код, то нужно её протащить в API и абстрагировать. Если фичи нет, будет выполняться скушный код, но таким образом две системы будут поддерживаться.

Есть же LGPL, которая позволяет использовать твоё детище в проприетарных разработках и при этом гарантирует, что саму библиотеку не зажмут. Золотая середина для библиотек, имхо.

Я читал много о лицензиях и склонялся к LGPL, но поразмыслив решил выбрать более BSD like лицензию, в основном для того, что бы разработчики имели возможность встраивать фреймворк в свой проект статически. Пользуясь своими флагами компилятора, собрать фреймворк.

А как проверить, что указатель ссылается на валидную память? сам то указатель валидный — не nullptr.

Как вариант завести менеджер, и проверять им указатель на валидность, со всеми проверками и т.д Но думаю, что это излишне. SDL1 и 2 вообще на си и не проверяют, SFML так же это не делает.

в корне не согласен — в части того, что сейчас можно сделать куда более высокопроизводительный код современными средствами.

Но его не делают:)

ИМХО толку не будет пока у ТС не появится реальная мотивация к тому, чтобы разработать API, который будет полезен для других.

Поделитесь мыслями, что улучшить, на что обратить внимание и т.д Мне важен фидбек по проекту. Если ткнете в код, буду благодарен. Реальная мотивация, это вы о чём?

Уважуха, конечно, но зря.

Конечно, трезво глядя на цели, заявляемые автором, вряд ли бизнес может иметь какой-то интерес в этом фреймворке. Поэтому использование лицензии «Васянам от Васи» имеет смысл (без намёка как-то задеть автора — на самом деле, я думаю, что это один из немногих, если не единственный, интересных опенсорс проектов, выставляемых на ЛОРе за последнее время).

Но пожалуйста хватит врать о «золотой середине». Люди и особенно компании избегают LGPL, потому что это рак, пусть и в меньших масштабах чем GPL, но в масштабах бизнеса головная боль та же. Если ты хочешь популяризовать свою библиотеку, она не должна быть под раковой лицензией. Точка.

Реальная мотивация, это вы о чём?

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

Поделитесь мыслями, что улучшить, на что обратить внимание и т.д

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

Вообщем всё можно реализовать, но это колоссальный труд.

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

Для этого специально начал проект по реализации движка игры Arcanum. Проверка идеи, API. Графически слаб, но вообщем проект довольно сложный. Сейчас обдумываю концепию автоматического батчинга текстур.

Хочу добавить следующую возможность. Разработчик рисует 2D API, в нутри все данные попадают в очередь, после чего алгоритм делит на батчи и рисует. И ещё дополнительный момент, с текстурами. Создаем текстуры, пользователь их видит как разные указатели на классы, но внутри, выделяется одна большая текстура и в нее копируются изображения, если текстура заполнена создается следующая. При рисовании, в очередь отрисовки попадают размер изображения, координаты изображения в текстуре. Так же алгоритм проходит, делит на батчи и т.д

И все это происходит под капотом. Разработчки пишет, стандартный код вывода тайлов, смещаясь по x и y.

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

Я читал о SDL 3.0. Нужно будет ещё раз ковырнуть данный проект. В свое время я его уже смотрел, для понимания общих концепций.

Вообщем всё можно реализовать, но это колоссальный труд.

Поэтому хочу запилить именно фреймворк LDL. Little DirectMedia Layer. Маленький, но который содержит базовые вещи.

Рад за вас!

Ещё есть мысли после готовности фреймворка. Переносить игры с SDL1 и 2 на LDL. Что бы показать готовность и зрелось проекта.

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

Это игра Cube и OpenGL tetris. На данный момент для тестирования переносил Cube 2: Sauerbraten (исходники от 2013 года, так как болеt свежие, слишком сильно завязан на SDL2).

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

ЛОР вас не «отверг», так что ждём новых тредов.

Только если интересно ознакомиться, есть ещё вот такой фреймворк от автора GEGL-а. Тоже довольно шустрый, но мелкий (влазит на контроллеры), на Си и с поддержкой цветовых моделей.

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

Так LGPL это и не запрещает. Объектные модули только надо предоставлять.

это рак

раковой лицензией

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

Объектные модули только надо предоставлять.

Что на практике чревато большим гемором. К тому же, объектники в разы легче реверсить, если кому-то захочется.

Так LGPL это и не запрещает. Объектные модули только надо предоставлять.

Не искушен в лицензиях. Если проект собирается под несколько платформ, нужно предоставить к каждой платформе под каждую битность объектные файлы?

По логике похоже, что да.

Я исходил из простоты. Каждый разработчик, может вкомпилить фреймворк в свой проект, не делится объектниками. Просто берет и юзает на свое усмотрение.

Если проект собирается под несколько платформ, нужно предоставить к каждой платформе под каждую битность объектные файлы?

Да. Можно предоставлять по требованию пользователей, но пользователь, естественно, может потребовать что угодно.

Только если интересно ознакомиться, есть ещё вот такой фреймворк от автора GEGL-а. Тоже довольно шустрый, но мелкий (влазит на контроллеры), на Си и с поддержкой цветовых моделей.

Спасибо, обязательно посмотрю. Наработки пойдут в soft рендер.

Беги аргументируй «золотую середину», содержательный мой.

Сбросьте пожалуйста мой небольшой скор на -15.

Зачем?

Шутка

Чтобы на погонах звёзд не было.

Ну если шутка, то ладно…

Только сбрасывать на произвольную величину модераторы не могут, могут только принудительно выставить в 50. И это мера поощрения новичков с МЕНЬШИМ скором, использовать это в обратную сторону попахивает читерством и вандализмом…

Шутка

Пожадничали нищему дать пятнадцать копеечек.

Можно сделать такой слой совместимости с SDL1 / SDL2, не простая работа, но достаточно сделать один раз и можно собирать с ним все игры.

https://github.com/libsdl-org/sdl12-compat

• Какая цель проекта?
• Какая аудитория проекта?
• Чем это лучше SDL + C++ (при том нормальный C++, а не 98) wrapper над ним или SFML?

Какая цель проекта?

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

Какая аудитория проекта?

Фреймворк я делаю доступным для всех. Сделал С API, для лёгкого создания биндингов к другим языкам. У меня предубеждений нет:)

Чем это лучше SDL + C++ (при том нормальный C++, а не 98) wrapper над ним или SFML?

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

Можно сделать такой слой совместимости с SDL1 / SDL2, не простая работа, но достаточно сделать один раз и можно собирать с ним все игры.

Угу, смотрел этот вариант. Портирование на LDL нужно именно для тестирования фреймворка и понимания какой функционал ещё нужно реализовать. По мере портирования, знакомишься с кодом, изучаешь архитектуру игры.

Из SDL можете взять готовый код для конфигурирования.

Портировал SDL в C++ и сделал в нём много рефакторинга.
Например подсистему использования типов для разных систем заменил на свою и конечно во всех исходниках поменял на свои.
В API SDL многие из функций заменил на свои, ..., ..., ...
Много макросов убрал, ... (много чего).
Пока всё ok!

Использую SDL для разработки GUI (для унификации).

дак в том то и дело — как проверить указатель на валидность?

а в sdl поскольку это си — сделано конвенционально — просто указано, что что-то должно переживать другое. Но это такая себе гарантия, из-за чего происходит множество багов и дыр в безопасности ПО.

Создать мультимедийный фреймворк.

Эта цель уже достигнута упомянутыми SDL и SFML и более легковесными glfw/glut.

С поддержкой в том числе и старого железа и операционных систем.

Это единственное значимое отличие?

Фреймворк я делаю доступным для всех. Сделал С API, для лёгкого создания биндингов к другим языкам. У меня предубеждений нет:)

Я не про то кто может этим пользоваться, я про то кто, по вашему мнению, захочет этим пользоваться.

Пока ни чем. Проект ещё и не до конца портирован на Linux. Ни все базовые фичи запилены

Тогда какого фидбека вы ждёте?

Иметь дополнительную головную боль со сбором объектников, их хранением на каждую версию и предоставлением пользователям (распространением) там, где её можно не иметь - содержательный аргумент.

Эта цель уже достигнута упомянутыми SDL и SFML и более легковесными glfw/glut.

Что теперь аналоги не писать?:) Думаю каждый автор фреймворка реализовал своё видение.

Это единственное значимое отличие?

Пока да.

Тогда какого фидбека вы ждёте?

Фидбек по коду, совет, предложение, критика.

дак в том то и дело — как проверить указатель на валидность? а в sdl поскольку это си — сделано конвенционально — просто указано, что что-то должно переживать другое. Но это такая себе гарантия, из-за чего происходит множество багов и дыр в безопасности ПО.

Спасибо за поднятый вопрос, я об этом не думал. Я думаю встроить shared и unique ptr в проект, можно обмазать ifdef’ами. Тогда будет поддержка новых фич и совместимость со старыми компиляторами.

Реальная мотивация, это вы о чём?

Веду разработку не для фана (технологию разработки программ).
Поэтому форк SDL для меня не фан, а API, которое используется для унификации графического API.
Разница большая между «fun» и «нужно».

Веду разработку не для фана (технологию разработки программ). Поэтому форк SDL для меня не фан, а API, которое используется для унификации графического API. Разница большая между «fun» и «нужно».

Я тоже не в стол делаю. Хочу создать фрейморк, простой, удобный + поддержка старинных систем. Возможно кому то пригодится. Облегченный SDL c ООП из коробки.

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

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

У меня такого рода API находится в разрабатываемом GUI (OpenGL + метаданные).
В нём будет много вкусных (и новых) фич.
Основная фича - удобство.
GUI можно будет использовать в любом ЯП (в run-time).
В частности разработаю много разного типа рендеров.
Для многих controls будет поддержан 3D режим.

Как всё реализовать, понятно.
Проблема одна - в сутках всего 24 часа.

Конечно GUI кроссплатформенно (да и всё иное разрабатываемое API).

Продолжаю портирование под Linux. На данный момент все примеры (15 шт) корректно запускаются и работают.

Протестируйте пожалуйста, у всех ли все собирается и работает.

Сборка стандартная. git clone https://github.com/JordanCpp/Lib-LDL.git cmake .. make

Подскажите плиз.

Из внешнихних зависимостей фреймворк юзает xlib и GLX.

Вопрос, GLX есть в каждом дистрибьютиве? Возникли проблемы на некоторых системах, ругается на отсутствие GLX. Есть ли какой то универсальный способиз коробки подружить xlib и OpenGL? Или все равно нужно будет до устанавливать библиотеки?

Основная фича - удобство. GUI можно будет использовать в любом ЯП (в run-time).

Амбиции – это прекрасно. Но может быть начать с чего-нибудь попроще? Ну там мир во всем мире…