Девлог LOLEngine 0
Привет, игроделы!
Денёк выдался тяжелый и кодить получилось мало, но, учитывая успешный успех предыдущего поста, пора браться за работу.
На сегодня успелось только собрать базу на гит и вызывать окошко. Обо всем по порядку:
Завел проект на гите и стянул его на машину. Далее создал вот такую структуру папок:
Код движка расположился в папке 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! Сделай форматирование кода в тексте! задолбался все картинками ставить!
Все внешние функции и методы я сложу в файле LOLEngine/Include/Engine/ExternalSettings.hpp где пока будет объявлена одна extern функция GetApplicationSettings()
В папке Game/Sources/ создаю файл GameSettings.cpp и пишу реализацию функции GetApplicationSettings();
Возвращаюсь в движок - в main.cpp и получаю первые настройки из исполняемого модуля Game.
Запускаю и радуюсь окошку.
На сегодня это все. Успел мало, но надеюсь разогнаться на днях. Спасибо тем, кто подписался и @AABVGD, за идею написать под веб-сборку. В следующем посте постараюсь подключить OpenGL, glad и emscripten для сборки цветного окошка под desktop и web. Ссылка на репо
Ставьте плюсы/минусы, пишите в комментах что я сделал так, а что не так.
PS: Если кто знает как вставлять код с форматированием на Pikabu, расскажите
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 посвятить обзору планируемой архитектуры (с диаграммами и картинками), желаемых возможностей движка, построения первичной дорожной карты. Тогда было бы понятно, куда идёт проект. Работа в формате "программирую пока программируется" будет протекать тяжело, а читателям может быть не совсем понятно, где сейчас находится проект и чего ждать.