- IPcorp
- Постоялец
саблезубый творожок
> надёжность и удобство, всё лежит в одном месте и ты это контролируешь,
Вот это я и понял прям буквально. Но сча прочитал продолжение диалога, тс все норм вроде делает, так что сорян, накосячил я со своим утверждение. Ввели в заблуждение два момента:
1. Monika
> Это делается для того, чтобы любой человек пытающийся собрать движок, не искал эти зависимости бог знает где. Еще и версии ведь нужные подбирать придется
> А так, сразу склонировал и собрал)
и
2. Nikitron
> Зачем коммитить 3rdparty в репозитой и при этом использовать cmake
которые тоже понял буквально, особенно второе вводит в заблуждение, так как никакого "коммитить 3rdparty в репозитой" в свой (я так понял) у тс вроде нет 😏 Сторонние модули в своей репе как гит субмодули. По сути это же просто ссылки на сторонние модули, и вроде как при простом клонировании репы игры они даже и не тянутся. Чистота репозитория сохраняется, чужого там при таком подходе нет. Просто тс, дабы не потерять доступ к сторонним либам, сделала их форки, и субмодули указывают не на оригинальные репы, а на эти самые форки.
Далее тс так и уточнила, что:
Monika
> Все библиотеки как раз форки, так как уже было такое, что репозиторий удалили, и движок ссылался на битый сабмодуль.
Плюс лишней работы, конечно, но зато недежней. Вообще все это "с как уже писали выше - внешний репозиторий могут удалить" как-то диковато звучит. Хотя я с плюсами редко работаю, может потому и не сталкивался с таким. В мире js, видно, все более цивилизовано, и vsc юзается именно так, как и должен юзаться, и для чего его, собсно, и слепили.
Nikitron
> для разработчиков же может быть просто bootstrap.sh который запустив один раз, скачает и скомпилирует всё что нужно для разработки и запуска движка
Вот это уже явно лишнее, как по мне. Клонируешь репу игры с подтягиваением субмодулей, и дальше просто компилишь движок, зачем что-то еще запускать, а автору движка еще и настраивать. Хотя тут у каждого свой подход, лишь бы не захламлялся свой репозиторий чужим кодом.
ЗЫ. У мну сча вот проект на js. Есть там, правда, и самописные модули на плюсах, но в плане плюсов те пару нужных библиотек я вот тупо рядом в своей репе и положил. Как-раз таки не красиво, но в моем случае их обновлять и не планирую, да и это просто момент в разработке, остальное все на js/ts, так что плюс пару килобайт не особо важно. В остальном проект из трех частей, клиент UI, само приложение, и сервак. На данный момент, глянул, 17 основных зависимостей, и 23 devDependencies. А если зайти и глянуть их внутренние зависимости, их там в сумме где-то 300+. Естественно, ни о каком ручном обновлении и речи нет. Собсно vsc тут и должен все разруливать и следить за обновлениями. Но я вот, что бы тоже перестраховаться, просто зафиксировал версии сторонних модулей, хотя обычно так не делают. В пределах миноров ничего не должно ломаться, при этом пользователи всегда имеют самые последние версии нужных модулей.
Как итог. Если нужно просто кому-то скачать репу что бы в коде покопаться, это менее 1 Мб. Если кто хочет просто собрать что бы юзать, тут уже менеджер пакетов будет тянуть нужные зависмости. Если же нужно проект кастомизировать, чего-нить править, тут еще нужно поднятнуть и devDependencies. Последних два момента, глянул, это уже скачать еще до 300 Мб, которых в моем репозитории из 1 Мб просто нет. За все время ни разу не было (стучу по дереву), что бы где-то что-то из зависимостей удалили, хотя, кажется, из подобных проектов с сотнями сторонних пакетов это должно быть очень вероятно.
IPcorp
> вводит в заблуждение, так как никакого "коммитить 3rdparty в репозитой" в свой (я так понял) у тс вроде нет
это зависимости сабмодулей Engine, которые закоммичены:
https://github.com/SpaRcle-Studio/SRRender/tree/dev/libs/inc - glad, json, stbi
https://github.com/SpaRcle-Studio/SRRender/tree/dev/libs - glew
https://github.com/SpaRcle-Studio/EvoVulkan/tree/dev/Depends - glfw, stbi
https://github.com/SpaRcle-Studio/EvoVulkan/tree/dev/Depends/inc - glm
сори что вводу в заблуждение
IPcorp
> Вот это уже явно лишнее, как по мне. Клонируешь репу игры с подтягиваением субмодулей, и дальше просто компилишь движок, зачем что-то еще запускать, а автору движка еще и настраивать. Хотя тут у каждого свой подход, лишь бы не захламлялся свой репозиторий чужим кодом.
ну и мы спорим об одном и том же, ты любишь делать х команд, я люблю делать 2 команды чтобы собрать проект, разница не большая
IPcorp
> Вот это уже явно лишнее, как по мне.
Сори но всё же напишу
https://github.com/SpaRcle-Studio/SRCommon/tree/dev/libs - 6 либ закомичено но интереснее всего glm которая в разных сабмодулях повторно закоммичена
самое интересно это как раз история коммитов:
https://github.com/SpaRcle-Studio/SRCommon/commits/dev/libs/glm
где прекрасные патчи и улучшение сторонней библиотеки - https://github.com/SpaRcle-Studio/SRCommon/commit/7321134cb305418… 4d0dd8b13R175
которые в SRCommon есть, а в EvoVulkan нет:
https://github.com/SpaRcle-Studio/EvoVulkan/commits/dev/Depends/inc/glm
вот и поддерживайте потом 2 разные версии одной версии библиотеки.
Nikitron
Ты пойми что профессиональным галерщикам удобно когда их старая репа пропадает, у них это называется "к сожалению исходники потеряли".
Добавили автоматическую публикацию дев релизов, в случае, если все сборки и тесты после коммита успешно прошли
https://github.com/SpaRcle-Studio/SREngine/releases
Nikitron
> которые в SRCommon есть, а в EvoVulkan нет:
> https://github.com/SpaRcle-Studio/EvoVulkan/commits/dev/Depends/inc/glm
> вот и поддерживайте потом 2 разные версии одной версии библиотеки.
Этот код планируется оттуда вообще вычистить. Изначально когда делалась поддержка вулкана для движка, то надо было тестовое приложение сделать, которое могло бы самостоятельно запускаться и показывать что все работает. Сейчас это не нужно, и будет в будущем вычищено
up
Три года разработки, а результатов нету.
gamedevfor
> Три года разработки, а результатов нету.
Ну здесь как результат сам процесс, а он в сравнении обычно слабо заметен. Я так понимаю, и суть то здесь в самом процессе, а не в результате, потому как странно писать двигло, начиная с зада. Обычно тру путь, это сначала слепить игру, и если в процессе были найдены интересные подходы в плане реализации того-другого, тогда можно это все вынести отдельным слоем в свой движок для дальнейшего переюзанья. А вот прям так с ходу лепить двигло обосновано лишь в том случае, если уже существующие решения чем-то не устраивают, кроме как "это не моё". Я вот чет в нем не вижу ничего такого прям революционного, что не покрывают ни юнька, ни анриал, ни прочие из зоопарка. И это не говоря о том, что прям в разы проще и экономнее по времени взять и допилить хотелки в уже существующем решении, а не городить с нуля нечто в вакууме, что чревато крайностями типа здесь чего-то не хватает, здесь чего-то лишнее приплели, и тому подбное. Так что, как понимаю, это проект для души и получения удовольствия от самого процесса его создания. Даже не удивлюсь, если он еще лет 10+ в разработке будет.
IPcorp
Нет у движка своей философии, поэтому будет и дальше барахтаться как ...
gamedevfor
> Три года разработки, а результатов нету
А что для вас результат?
За три года в движке было реализовано множество фичей, значительно улучшена и переработана кодовая база, графика стала на порядок лучше, разные дев демки есть с примерами использования фичей.
Monika
Надо скриншоты выкладывать.
Эх! Написали бы движок для ртс. Щас кроме Springs и его Форка Recoil. Ничего и нет! И там все на уровне 90-х застряло. Конечно, работает, но без пузыря не разберешься.
Monika
Я тоже думал сделать свой движок на все 3 платформы это windows, android и linux.
OnzaRain
> Эх! Написали бы движок для ртс. Щас кроме Springs и его Форка Recoil. Ничего и нет! И там все на уровне 90-х застряло. Конечно, работает, но без пузыря не разберешься.
Бесполезно надеяться, все всегда делают универсальный движок... Ну, или делай сам ;)