ПроектыФорумОцените

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

Страницы: 1 2 3 4 527 Следующая »
#30
(Правка: 22:40) 22:32, 14 дек 2022

vka123
> Это просто обёртка для std::queue<LDL::Events::Event>
Дело в том, что я скорее всего заменю очередь на кольцевой буфер. И лучше что бы напрямую в  API, STL не торчал.

vka123
> Обычную очередь событий раздули на 7 файлов.
> Зачем столько пустых классов, геттеров и сеттеров? и каждый чих в новом файле.
> Это неудобно.

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

Лучше мелкие классы держать в одном файле  Events. hpp?

vka123
> Попробуйте написать ТЗ на вашу библиотеку.
Думаю хорошая идея. И в документацию библиотеки войдёт.

#31
22:41, 14 дек 2022

vka123
Ещё и тестировать удобно. Я подключаю только 1  header с конкретной сущностью.

#32
23:25, 14 дек 2022

Ещё вопрос.

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

#33
0:14, 15 дек 2022

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

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

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

#34
(Правка: 0:24) 0:19, 15 дек 2022

JordanCpp
> Лучше мелкие классы держать в одном файле  Events. hpp?
не hpp, а cpp

void LDL::Events::Eventer::Push(LDL::Events::Event& event)
вот самому не лень писать все эти неймспейсы?

#35
0:36, 15 дек 2022

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

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

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

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

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

#36
0:39, 15 дек 2022

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

#37
0:50, 15 дек 2022

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

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

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

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

#38
(Правка: 1:06) 1:03, 15 дек 2022

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

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

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

#39
(Правка: 1:38) 1:18, 15 дек 2022

JordanCpp
посмотрел примеры в Examples
как то все уныло, что даже комментировать не хочется.
начиная от глобального try на всю программу и заканчивая двумя аллокаторами зачем то

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

докапываться можно абсолютно до любой строчки, к примеру
render.Draw(&image, LDL::Graphics::Point2u(x, y), LDL::Graphics::Point2u(150, 150));

чем хуже вариант?
render.Draw(&image, int x, int y, int width, int height);

void LDL::Graphics::GpuRender::Draw(LDL::Graphics::CpuImage* image, const LDL::Graphics::Point2u& pos, const LDL::Graphics::Point2u& size)
{
  _GpuRenderImpl->Draw(image, pos, size);
}

каеф, короче чисто плюсовый бойлерный код от которого тошнит

точно уверен что после отрисовки сцены следует Present? а если несколько сцен?

void LDL::Graphics::DX9Render::End()
{
    _Direct3DDevice->EndScene();
    _Direct3DDevice->Present(NULL, NULL, NULL, NULL);
}

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

все плохо, а если я не захочу чистить з-буффер? ок цвет я еще как то наверное пропихну

void LDL::Graphics::DX9Render::Clear()
{
    _Direct3DDevice->Clear(0L, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(_BaseRender.Color().Red(), _BaseRender.Color().Green(), _BaseRender.Color().Blue()), 1.0f, 0L);
}

вообщем GAPI ты в глаза не видел, и не разу не пользовался

#40
1:39, 15 дек 2022

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?

#41
1:42, 15 дек 2022

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

#42
1:44, 15 дек 2022

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

#43
1:46, 15 дек 2022

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

#44
(Правка: 2:03) 1:50, 15 дек 2022

JordanCpp
> Это сделано для оптимизации. Зачем тратить ресурсы на заливку экрана цветом,
> если в следующем кадре, экран будет перерисован новой графикой. Я исходил из
> таких соображений.
я про два флага (D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER), ты каждый кадр и заливаешь цветом и чистишь буфер.
я и просил, а вдруг я не хочу чистить буфер, что мне делать тогда.

JordanCpp
> Создаём аллокатор с 4 мб под данные, передаем его в загрузчик изображений.
почему нельзя было передать один общий аллокатор?

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

Страницы: 1 2 3 4 527 Следующая »
ПроектыФорумОцените