7

Девлог LOLEngine 0

Серия LOL Engine

Привет, игроделы!

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

На сегодня успелось только собрать базу на гит и вызывать окошко. Обо всем по порядку:

Завел проект на гите и стянул его на машину. Далее создал вот такую структуру папок:

Код движка расположился в папке LOLEngine, и собираться он будет в виде статической библиотеки. Точка входа int main() тоже будет расположена здесь.

Код проекта будет в папке Game, сборка - в исполняемый файл.

Ну и все сторонние библиотеки будут складываться в папку ThirdParty.

Начну с подключения сабмодулей к своему репозиторию. Мне понадобятся: сейчас - glfw, потом - glm (сильно потом сюда будут спиханы все json, imgui и прочее)

Сабмодули подключил, обновил, проверил наличие в папке ThirdParty. Далее - прежде чем открывать папку репозитория в VS Code, следует сразу создать файл .gitignore (чтобы в комит не шло то, что не должно туда идти) и файл CMakeLists.txt в корне репозитория, и по одному CMakeLists.txt в папках LOLEngine и Game

Открываю папку в VS Code и создаю файл main.cpp в LOLEngine/Internal и пустой GameSettings.cpp в Game/Sources (в каждый проект надо добавить как минимум один файл исходного кода, чтобы CMake не ругался)

Далее перехожу в корневой CMakeLists и пишу следующее:

CMAKE_SUPPRESS_REGENERATION добавил, чтобы при сборке в IDE не создавался таргет для теста сборки

Движок и исполняемый проект подключаю через add_subdirectory. CMake найдет файлы CMakeLists в соответствующих папках.

CMakeLists.txt проекта Game выглядит так:

В туториалах часто видел, как все добавляемые файлы прописывают вручную в add_executable или add_library.

Здесь я использую file(GLOB_RECURSE) чтобы рекурсивно пройти по папкам и найти все файлы, сохранить их в переменную GAME_SOURCES и GAME_HEADERS и дальше добавить в проект. Для сборки достаточно добавить только cpp и c файлы, но чтобы hpp, h были видны в IDE если кто-то соберет под Visual Studio или XCode, добавляю и их.

source_group(TREE) сохранит структуру каталогов при сборке под IDE

Далее на очереди CMakeLists движка:

Нахожу OpenGL, аналогично Game, прохожусь рекурсивно по папкам в поисках исходников, подключаю в статическую библиотеку.

Далее папку с внутренними заголовками подключаю как PRIVATE, а папку Include и загаловки glm, glfw - как PUBLIC, чтобы они были видны в Game

Ну и заканчиваю подключением библиотек. Если в папке сабмодуля есть CMakeLists.txt высокая вероятность, что ее можно подключить через add_subdirectory и не париться вообще (Imgui потом придется собирать самим)

С этим закончили. Теперь если в main.cpp написать простой int main(), то все запустится.

Заработало

Заработало

Теперь проекту нужно передать размер и название окна в движок (позднее и некоторые другие данные). Для этого в LOLEngine/Include/Engine/Core создаю файл AppSettings.hpp и объявляю простую структурку.

Pikabu! Сделай форматирование кода в тексте! задолбался все картинками ставить!

Pikabu! Сделай форматирование кода в тексте! задолбался все картинками ставить!

Все внешние функции и методы я сложу в файле LOLEngine/Include/Engine/ExternalSettings.hpp где пока будет объявлена одна extern функция GetApplicationSettings()

В папке Game/Sources/ создаю файл GameSettings.cpp и пишу реализацию функции GetApplicationSettings();

Возвращаюсь в движок - в main.cpp и получаю первые настройки из исполняемого модуля Game.

Запускаю и радуюсь окошку.

На сегодня это все. Успел мало, но надеюсь разогнаться на днях. Спасибо тем, кто подписался и @AABVGD, за идею написать под веб-сборку. В следующем посте постараюсь подключить OpenGL, glad и emscripten для сборки цветного окошка под desktop и web. Ссылка на репо

Ставьте плюсы/минусы, пишите в комментах что я сделал так, а что не так.

PS: Если кто знает как вставлять код с форматированием на Pikabu, расскажите

Лига программистов

2.3K постов12K подписчиков

Правила сообщества

- Будьте взаимовежливы, аргументируйте критику

- Приветствуются любые посты по тематике программирования

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

1
Автор поста оценил этот комментарий

Люблю, когда движок сам определяет main() и решает, какие системы должны запуститься и взаимодействовать для работы класса приложения, определённого пользователем. Это очень удобно для разработки с опорой на один только код: можно включить заголовок движка и забыть о нём, сосредоточившись на программировании логики для своих задач.


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


Альтернатива: скинуть заботу об определении main() на плечи приложения-пользователя движка и, по возможности, автоматизировать написание соответствующего .cpp-файла с мейном с помощью редактора. Тогда размер дистрибутива будет определяться главным образом только теми системами движка, которые на самом деле востребованы приложением.


Почему в LOLEngine отдано предпочтение именно первому варианту? 🤔

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

Тут можно сделать как сделано в SDL - крупные модули писать с максимально низкой связностью и собирать в отдельные библиотеки (Как SDL, SDL_ttf, SDL_mix и т.д.) Далее на этапе компиляции executable проекта подключать только то, что нужно.

Мне кажется, что к точке входа это отношение будет иметь слабо.

В этом проекте я хотел максимально отвязать игровую логику отдельного проекта от всего системного и внутридвижкового. К примеру, в том-же Unity - пользователь по сути (могу и ошибаться) пишет логику для отдельных нодов сцены, саму структуру сцены и заполняет ассеты. В базовом случае ему не надо самому писать InitWindow() InitAssetManager() Application app; app.Loop() и прочее, что часто встречается в int main() и мало отличается между проектами. Я планирую прийти к чему-то такому - писать код для сцен и нодов этой сцены, оставив все остальное движку.

ЗЫ: Спасибо за коммент

2
Автор поста оценил этот комментарий

1. Зачем нумерация с нуля? Програмисткость подчеркнуть?

2. Вроде руководство CMake до сих пор не рекомендует собирать файлы через `GLOB`? Вручную их перечислять, конечно, умеренно утомительно, но автоматически исключаются случаи случайной компиляции ненужных файлов. Помимо этого, иногда может возникать потребность в условной компиляции, например, в зависимости от целевой платформы. В этом случае как минимум придётся собирать отдельные списки файлов через тот же `GLOB`.

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

4. При подключении библиотек лучше указывать имена импортируемых целей сборки, например, `glm::glm`, которые в собираемом проекте как правило прописываются в виде псевдонима для цели сборки (по идее, glm должен иметь уже данный псевдоним).

5. Указание glm и glfw в качестве публичных зависимостей превращает их в зависимости всего, что использует движок. На текущем этапе это, наверное, нормально, т.к. проект только зарождается. В дальнейшем, если планируется превращение его в настоящий движок, проблему как-то надо решать. Разумеется, если предполагается, что движок подтягивается исключительно как субмодуль или через `FetchContent` и добавляется через `add_subdirectory`, то и так сойдёт. А вот если всё-таки планируется превращение в полноценную библиотеку, которую можно отдельно собрать и подключить, необходимо решить вопрос формирования установочного пакета. При решении этой задачи средствами CMake (а как ещё?) потребуется, чтобы все не импортируемые цели, от которых зависит проект, также экспортировались. Иначе CMake будет ругаться.

5. Если цель - подолбиться в низкоуровневый OpenGL с ручным управлением ресурсами и построением обёрток для цивилизованной работы, то оставьте, как есть. Хотя это уже делали и много раз. Если есть цель сделать движок, то просто возьмите Magnum - движок 3D-рендеринга, оборачивающий OpenGL во что-то человекоориентированное, где уже реализованы решения как минимум ряда особенностей реализации OpenGL от разных вендоров.

6. Лучше бы было главу с номером 0 посвятить обзору планируемой архитектуры (с диаграммами и картинками), желаемых возможностей движка, построения первичной дорожной карты. Тогда было бы понятно, куда идёт проект. Работа в формате "программирую пока программируется" будет протекать тяжело, а читателям может быть не совсем понятно, где сейчас находится проект и чего ждать.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Спасибо за советы. Особенно на тему подключения библиотек. Девлог назвал 0 потому что посчитал, что написал слишком мало для первого. Хотя, да, получилось как во всех "я программист - считаю с 0" видео. На тему 5 пункта - движок планирую именно подтягивать как сабмодуль. Но вот думаю, все что в ThirdParty - оформить в отдельный модуль и подключать и к движку и к проекту. Хотя, может и плохая идея

2
Автор поста оценил этот комментарий
@CodePanda, предлагаю сразу в Readme прописать подробнее: что это, как развернуть, писать ли про траблы в issue, или лучше на почту.
И вопросы по проекту.
Почему Game то назван подпроект?
В разработке библиотек есть устоявшиеся правила: include/{proj name}/*, src/*.
Инклюдить публично все папки? Может, наружу BUILD_INTERFACE/include только прокинуть? Зачем юзеру остальное?
То же про линк либ, публичный.
Так же стоит добавить по Readme в каждый подпроект.
Подписался, теперь слежу за Вами.
раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Вот за это замечание спасибо. Как раз пытался нарыть инфу про то что считается стандартом подобной разработки, но, видимо, криво искал. Пока что убрал OpenGL из публичных инклудов, оставил только Include движка и ThirdParty. По советам из комментов, скорее всего выделю ThirdParty в отдельный модуль. До ReadMe дойду, честное слово.

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества