Фреймворк LDL (3 стр)

Ещё вопрос.

Имеет ли смысл дробить классы? Пример.
Ограничитель фпс и счётчик фпс. В принципе их можно добавить в класс окна или рендера. Но я их сделал как отдельные сущности. Удобно тестировать. Но и нужен дополнительный код, что бы инициализировать и т. д
Если я добавлю два метода к классу окна, limitFps и GetFps, избегаем доп кода.

Я в вопросе кода довольно прагматичен.
Если я не использую в программе или в какой-то её части принципы ООП, то там я не использую ни классы ни ООП, а просто пишу на С. При таком подходе 80% вашего кода бесполезно - ибо это обёртки.

Второй важный момент - ваша библиотека это основа программы или вспомогательные модули. Вам это надо выбрать, от этого зависит как её будут использовать: можно ли её прикомпоновать к готовому проекту и использовать полезный функционал или по частям вашу библиотеку использовать нельзя.
Для библиотек основной показатель - это повторное использование кода в других проектах.
Вы сами используете куски от STB - просто подключил заголовочный файл и пользуешься и никаких лишних требований. С вашей так можно? или надо всё подключать ?
помимо STB вот ещё пример хороших библиотек - подключил нужный модуль и просто используешь.
https://github.com/mattiasgustavsson/libs

А фреймворк в отличие от библиотек должен содержать какую-то идеёную часть - как писать приложение основываясь на этом фреймворке.

vka123
> Я в вопросе кода довольно прагматичен.
> Если я не использую в программе или в какой-то её части принципы ООП, то там я
> не использую ни классы ни ООП, а просто пишу на С. При таком подходе 80% вашего
> кода бесполезно - ибо это обёртки.
Так и есть это обёртка над осью, окном, таймером, циклом событий, над  OpenGL и DirectX. Из моего кода там только ЦПУ рендер. Но зато это обёртка стандартная для всех операционных систем, как реализованных, так и будущих.

vka123
> Второй важный момент - ваша библиотека это основа программы или вспомогательные
> модули. Вам это надо выбрать, от этого зависит как её будут использовать: можно
> ли её прикомпоновать к готовому проекту и использовать полезный функционал или
> по частям вашу библиотеку использовать нельзя.

Это фреймворк, так как имеет свой цикл событий. Не библиотека.
vka123
> Вы сами используете куски от STB - просто подключил заголовочный файл и
> пользуешься и никаких лишних требований. С вашей так можно? или надо всё
> подключать ?
Подключать. Будет версия для динамического и статического связывания.

vka123
> помимо STB вот ещё пример хороших библиотек - подключил нужный модуль и просто
> используешь.
> https://github.com/m… stavsson/libs
Огонь. Посмотрю как, что реализовано.

vka123
> А фреймворк в отличие от библиотек должен содержать какую-то идеёную часть -
> как писать приложение основываясь на этом фреймворке.
Идейная часть как у SDL и SFML. Только в более компактном ввиде. Но по мере развития проекта, конечно я буду добавлять новый функционал.

u960
> вот самому не лень писать все эти неймспейсы?
За меня их студия пишет. Но вы правы в заголовочных файлах нет смысла писать namespace'ы в определении методов. Так они уже находятся в намеспайсе. Обязательно проведу рефакторинг и лишнее уберу.

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

Я понимаю, что сейчас проект это поделка на коленке, но у меня есть желание его улучшить и начать с малого и постепенно добавлять функционал.

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

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

У меня была идея переписать фреймворк на си. Для биндинга к любым языкам. И для С++ навернуть над библиотекой ООП обвяз. Но хочется программировать на С++, а не просто делать обвязку на С. Хотя опять же, ещё размышляю над этим вариантом.

И ещё плюс фреймворка, что я не ограничиваю в версии стандарта С++. Я как разработчик, ограничил себя стандартом С++98. Но пользователь фреймворка, может использовать любой современный стандарт.

Я ближе к релизу, напишу техническую статью, где все распишу. Уже без лишних мемасов и шуток:) Но ведь мемы смешные же? :)

u960
> посмотрел примеры в Examples
> как то все уныло, что даже комментировать не хочется.
> начиная от глобального try на всю программу
Для примеров я использую один try. Потому, что если что то сломалось то это фатально. Как минимум в примерах.
u960
> заканчивая двумя аллокаторами зачем то
Это фича;)  Идея в том, что бы не дёргать лишний  раз new при загрузке изображения в ОЗУ. Создаём аллокатор с 4 мб под данные, передаем его в загрузчик изображений. Теперь при загрузке изображений память аллокатоа будет сбрасываться и в неё поступать пиксели изображения. Так же аллокатор юзает  stb_image. Можно грузить бесконечное число изображений, главное выделить правильный размер аллокатора.
u960
> я просто вижу что автор любит-хочет много много бойлерплейта
> автору нравится везде подчеркивать что это LDL а не хухры мухры
Ок. В примерах буду юзать using LDL. Галочку для рефакторинга поставил.
u960
> чем хуже вариант?
> render.Draw(&image, int x, int y, int width, int height);
Он не хуже. Просто инкапсулировал точку в класс. Думаете имеет смысл убрать и переделать на int' ы?
u960
> каеф, короче чисто плюсовый бойлерный код от которого тошнит
Имеется ввиду длинная сигнатура метода? Или вы о идиоме pimple? Или о лишних  namespace?

u960
> точно уверен что после отрисовки сцены следует Present? а если несколько сцен?
Насчёт нескольких сцен я не думал.
u960
> вообщем GAPI ты в глаза не видел, и не разу не пользовался
Этот код из туториалов:)

u960
> все плохо, а если я не захочу чистить з-буффер? ок цвет я еще как то наверное
> пропихну
Это сделано для оптимизации. Зачем тратить ресурсы на заливку экрана цветом, если в следующем кадре, экран будет перерисован новой графикой. Я исходил из таких соображений.

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

Der FlugSimulator
> Ну не знаю, зачем этот двиг нужен.
> Даже если бы мне захотелось хардкора, я бы скорее raylib какой-нибудь взял.
Это не двиг, а фреймворк. Прекрасно вас понимаю. Проект ещё в альфе, юзать его нельзя.
Замечу, что когда то и raylib начинали и он был в альфе. И про него говорили, кода кусок:)

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

u960
> бывают случаи, когда выделяются определенный кусок памяти,и он дополнительно
> помечается,
> как видео память, или только как аудио память. И тогда на этот кусок память
> "натравливается" свой аллокатор, чтобы он эту память менеджерил. Но у тебя явно
> не этот случай
Аллокатор может юзать память другого аллокатора. В примерах такой вариант отсутсвует. Добавлю.

FixedLinear(size_t bytes, LDL::Allocators::Allocator* allocator = NULL);

По умолчанию NULL, юзается  new, иначе дергаем аллокатор.

u960
Спасибо за советы и справедливую критику.

Чуть подрефакторил код и добавил ники пользователей которые помогли советом или тестированием фреймворка в readme.

Начинаю готовить документацию на английском с помощью doxygen.