Comments 7
Интересная статья. Моё внимание привлекли библиотеки пулов потоков. Я сам пользуюсь легковесной библиотекой: https://github.com/inkooboo/thread-pool-cpp.
Я решил взять бенчмарк и сравнить скорость выполнения предложенных трёх и той, что у меня. Предложенные 3 уступили с большим отрывом, но надо сделать оговорку, пул от inkooboo имеет заранее установленный размер очереди 128 задач, если превысить его программа упадёт. Если увеличить размер до 10'000 тогда этот пул будет быстрым только в тесте на 10к задач, а в остальных уступит. В моих проектах обычно количество одновременных задач бывает не более двух десятков, поэтому реализация от inkooboo для меня вне конкуренции.
Читаю с удовольствием, спасибо!
Учитывая достаточно объёмный материал в вашем цикле статей, хотелось бы перед "Game++. Game Over" прочитать о вашем видении архитектуры игры в целом и в частностях и не только:
Экосистема вокруг движка (базовый код и инструментарий). Своё и интегрировать или через бубен внедрять сторонние решения.
Как видете например систему плагинов (Да я читал статьи "dll as plugin"), но может есть альтернативы?
Какой масштаб (Не длиннее жизни :) ) реален для команды из 2-х человек. Примеры.
Куда всё катится (Через призму кода, времени, оптимизаций)?
Да, понимаю, что уже опубликовано отнимает ваше время и силы, но вас читают! Всё это не бесследно.
Спасибо, приятно слышать, что не в стол. Как раз последняя часть будет про экосистему движка, уже написана, но в виде черновиках только.
Про плагины - из того, что я вижу - уходят в сторону транспилируемых языков нокод систем, старички еще держатся за дллки, но это дорого в поддержке, непортируемо и занимает время на пересборку.
Для двух человек за месяц-другой реально написать скелет, не фултайм - вечерами. Правда придётся подзабить на семью ;)
Движется все в сторону "печек", т.е. систем, конструкторов которые из частей собирает то что нужно. Сначала к печкам пришли ОС, сейчас по этому пути же идут компиляторы, когда компиляторы компиляторов станут более массовым решением, появится компилятор приложений, ну или как подвиж конструктор игровых движков.
Это не моё видение - Суини и мастер Габен уже лет пять вещают, что мы видим закат движков в их нынешнем виде, когда их пишут люди, потому что большая часть всего нужного для разработки уже написана
Обычно в конце фрейма, перед тем как данные уходят в видео карту у нас остаются свободные потоки, которые можно временно сделать такими «цепочками» и грузить ресурсы когда точно знаем, что не мешаем игре.
А как же поддержка 360Гц мониторов? Там нет времени в конце кадра)
Пика использования такой подход достиг в движках и играх Naughty Dog, которые упоролись и сделали воркеры аж на fibers
Сейчас уже корутины в С++ завезли, больше никакого callback hell.
Я когда-то впечатлился idTech и тоже сделал себе движок на тасках. Пока нет ошибок все хорошо работает, а как только одно из звеньев цепочки тасков ломается, то система приходит в неопределенное состояние и начинаются дедлоки тасков - когда таск ждет успешного завершения другого, который уже завершился с ошибкой. Нужно не забывать обрабатывать все варианты, а компилятор в этом не помошник, в отличие от кодов ошибок с nodiscard например.
Game++. Work hard