vka123
> Это просто обёртка для std::queue<LDL::Events::Event>
Дело в том, что я скорее всего заменю очередь на кольцевой буфер. И лучше что бы напрямую в API, STL не торчал.
vka123
> Обычную очередь событий раздули на 7 файлов.
> Зачем столько пустых классов, геттеров и сеттеров? и каждый чих в новом файле.
> Это неудобно.
Я долгое время писал на С#, больше привычка каждую сущность рассовывать по файлам.
Лучше мелкие классы держать в одном файле Events. hpp?
vka123
> Попробуйте написать ТЗ на вашу библиотеку.
Думаю хорошая идея. И в документацию библиотеки войдёт.
vka123
Ещё и тестировать удобно. Я подключаю только 1 header с конкретной сущностью.
Ещё вопрос.
Имеет ли смысл дробить классы? Пример.
Ограничитель фпс и счётчик фпс. В принципе их можно добавить в класс окна или рендера. Но я их сделал как отдельные сущности. Удобно тестировать. Но и нужен дополнительный код, что бы инициализировать и т. д
Если я добавлю два метода к классу окна, limitFps и GetFps, избегаем доп кода.
Я в вопросе кода довольно прагматичен.
Если я не использую в программе или в какой-то её части принципы ООП, то там я не использую ни классы ни ООП, а просто пишу на С. При таком подходе 80% вашего кода бесполезно - ибо это обёртки.
Второй важный момент - ваша библиотека это основа программы или вспомогательные модули. Вам это надо выбрать, от этого зависит как её будут использовать: можно ли её прикомпоновать к готовому проекту и использовать полезный функционал или по частям вашу библиотеку использовать нельзя.
Для библиотек основной показатель - это повторное использование кода в других проектах.
Вы сами используете куски от STB - просто подключил заголовочный файл и пользуешься и никаких лишних требований. С вашей так можно? или надо всё подключать ?
помимо STB вот ещё пример хороших библиотек - подключил нужный модуль и просто используешь.
https://github.com/mattiasgustavsson/libs
А фреймворк в отличие от библиотек должен содержать какую-то идеёную часть - как писать приложение основываясь на этом фреймворке.
JordanCpp
> Лучше мелкие классы держать в одном файле Events. hpp?
не hpp, а cpp
void LDL::Events::Eventer::Push(LDL::Events::Event& event)
вот самому не лень писать все эти неймспейсы?
vka123
> Я в вопросе кода довольно прагматичен.
> Если я не использую в программе или в какой-то её части принципы ООП, то там я
> не использую ни классы ни ООП, а просто пишу на С. При таком подходе 80% вашего
> кода бесполезно - ибо это обёртки.
Так и есть это обёртка над осью, окном, таймером, циклом событий, над OpenGL и DirectX. Из моего кода там только ЦПУ рендер. Но зато это обёртка стандартная для всех операционных систем, как реализованных, так и будущих.
vka123
> Второй важный момент - ваша библиотека это основа программы или вспомогательные
> модули. Вам это надо выбрать, от этого зависит как её будут использовать: можно
> ли её прикомпоновать к готовому проекту и использовать полезный функционал или
> по частям вашу библиотеку использовать нельзя.
Это фреймворк, так как имеет свой цикл событий. Не библиотека.
vka123
> Вы сами используете куски от STB - просто подключил заголовочный файл и
> пользуешься и никаких лишних требований. С вашей так можно? или надо всё
> подключать ?
Подключать. Будет версия для динамического и статического связывания.
vka123
> помимо STB вот ещё пример хороших библиотек - подключил нужный модуль и просто
> используешь.
> https://github.com/m… stavsson/libs
Огонь. Посмотрю как, что реализовано.
vka123
> А фреймворк в отличие от библиотек должен содержать какую-то идеёную часть -
> как писать приложение основываясь на этом фреймворке.
Идейная часть как у SDL и SFML. Только в более компактном ввиде. Но по мере развития проекта, конечно я буду добавлять новый функционал.
u960
> вот самому не лень писать все эти неймспейсы?
За меня их студия пишет. Но вы правы в заголовочных файлах нет смысла писать namespace'ы в определении методов. Так они уже находятся в намеспайсе. Обязательно проведу рефакторинг и лишнее уберу.
Идейная часть сделать заменитель SDL2 но с ООП и поддержкой всевозможных систем и устройств.
Я понимаю, что сейчас проект это поделка на коленке, но у меня есть желание его улучшить и начать с малого и постепенно добавлять функционал.
Именно для этого, для помощи и дельного совета. Зарегистрировался на этом сайте, не что бы гнуть свою точку зрения и показывать какой я тут важный пряник, а спросить совета у разработчиков. Как лучше сделать, что поменять, на что обратить внимание и т. д
Благодарен всем, кто решил проявить свой интерес и помочь советом в реализации.
У меня была идея переписать фреймворк на си. Для биндинга к любым языкам. И для С++ навернуть над библиотекой ООП обвяз. Но хочется программировать на С++, а не просто делать обвязку на С. Хотя опять же, ещё размышляю над этим вариантом.
И ещё плюс фреймворка, что я не ограничиваю в версии стандарта С++. Я как разработчик, ограничил себя стандартом С++98. Но пользователь фреймворка, может использовать любой современный стандарт.
Я ближе к релизу, напишу техническую статью, где все распишу. Уже без лишних мемасов и шуток:) Но ведь мемы смешные же? :)
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 ты в глаза не видел, и не разу не пользовался
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 какой-нибудь взял.
JordanCpp
> Это сделано для оптимизации. Зачем тратить ресурсы на заливку экрана цветом,
> если в следующем кадре, экран будет перерисован новой графикой. Я исходил из
> таких соображений.
я про два флага (D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER), ты каждый кадр и заливаешь цветом и чистишь буфер.
я и просил, а вдруг я не хочу чистить буфер, что мне делать тогда.
JordanCpp
> Создаём аллокатор с 4 мб под данные, передаем его в загрузчик изображений.
почему нельзя было передать один общий аллокатор?
бывают случаи, когда выделяются определенный кусок памяти,и он дополнительно помечается,
как видео память, или только как аудио память. И тогда на этот кусок памяти "натравливается" свой аллокатор, чтобы он эту память менеджерил. Но у тебя явно не этот случай.