Это не эквивалентная замена.
Во-первых, исключения могут быть отключены.
Во-вторых, abort_programm может нести дополнительную нагрузку и выполнять полезную работу до завершения выполнения.
В-третьих, я могу объявить функции с noexpect, например

Речь о том, что возможность компиляции функций без return это явный баг в стандарте языка.

Вот пример валидной программы на C++:

/*[[noreturn]]*/ void abort_programm();

struct A
{
    static A make();

private:

    A() = default;
};

 template<typename T>
 T create_object(std::function<T()> maker)
 {
    if (maker)
        return maker();
    abort_programm();                            
}

int test()
{
    A a = create_object<A>(&A::make);
}

Компилятор не видит что делает функция abort_programm, она может вызвать exit, abort, кинуть исключение или еще что-то т.е. прервать поток выполнения и не возвратить управление вызывающей стороне и в этом случае программа валидная. А может и возвратить, тогда это UB. Мы не можем здесь написать ни какой return, потому что не знаем как создать объект. Максимум что может сделать компилятор — это предупредить и обратить внимание на потенциальную проблему, сгенерировав предупреждение.

control reaches end of non-void function [-Wreturn-type]

Если мы правильно реализовали функцию abort_programm, то это предупреждение будет ложным. Эта причина существования [[noreturn]]. Если функция будет помечена таким атрибутом, то даже без знания определения, компилятор может сделать вывод о том что все в порядке и подавить генерацию ложного предупреждение.

Помечать валидную программу ошибкой по умолчанию — не правильно.

Можно попробовать с такими сочетаниями собрать: -fforce-emit-vtable -fstrict-vtable-pointers или -fvisibility=hidden -fwhole-program-vtables.

Программирование – это не магия, это набор действий, которые делают с определенной логикой в определенных инструментах. И когда вы увидите, как это делает другой программист, многое станет ясным и понятным.

ECS, это прежде всего дата-ориентированный дизайн. Системы в ECS обрабатывают данные т.е. компоненты, а не сущности (Control). Ни каких переборов сущностей и запросов GetComponent там быть не должно, тем более проверок в цикле наличия компонент. Другая идеология. Собственно вопрос локальности обрабатываемых данных здесь принципиален и именно эту задачу, должна решать ECS. Процессинг, который вы привели в листинге, имеет объектно-ориентированный дизайн. Без какого-либо контекста, ровно такой же метод будет в случае со сцен-графом или другой подобной структурой с навешанными на узлы компонентами (компонентной моделью) и мы также будем итерироваться по этим узлам (Control'ам), запрашивать у узла нужны компонент и выполнять какие-то действия.

Поддерживаю, как это устроено? Видеть в рантайм коде перебор Conlrol'ов и запросы GetComponent на каждой итерации в контексте ECS выглядит очень странно по мне. Чем тогда это отличается от какого-нибудь сцен-графа с компонентой моделью, например?

Спасибо за замечание, исправил.
Это не перевод. Ссылки на использованный материал (его большая часть) находятся в конце статьи.
И отдельная благодарность за найденные ошибки: oficsu, novoselov, HepoH, HungryD, TAPro, ximen, Mingun. Спасибо!

Если интересна тема, можно посмотреть как пример
https://github.com/thebracket/rltk

Agile-пространство, где разрабатываются IT-продукты

Дожили!

Консультант по эффективности и Developer Advocate это одно и тоже?

Если убрать круг в центре то получится

вот так

Метро маленькое, информации, который несет в себе круг, гораздо больше чем вся схема метро. Просто добавили карту города, при этом сам дизайн метро остался такой же как под спойлером. Т.е. весь дизайн — это дизайн карты, центра города, а не метро

Ну т.е. по сути
Не кроссплатформенный (это важно, потому что если мы говорим о небольшой двумерной игрушке, то со временем она захочет перекочевать и на мобильные платформы), нет сети, нет UI, нет скриптов, нет профайлеров, нет spine-анимаций, с многопоточностью тоже скорее всего плохо.
Ну и на рендер нужно посмотреть внимательно еще, является ли он многопроходным, как это конфигурируется, есть ли постобработка, поддерживается ли сжатие, есть ли система частиц и т.д.?

Не знаю как вы, а я приятно удивлен простотой этого фреймворка

Простой потому что там ничего нет

В итоге
Компонентная модель + "напиши все что тебе нужно сам" != игровой движок

Добавлю

• Как дела с сетью?
• Есть ли какая-нибудь поддержка видео, открытых кодеков, например, theora?
• Что с анимациями, поддерживается ли spine?

Для CMake-based проектов https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools

С ходу напрашивается

1. Сделать один нормальный, грейскейленый атлас со всеми группами мышц (не нужно ни каких основ)
2. Один раз построить карту с положением группы на теле человека (x, y)
3. Чтобы отобразить нужное изображение (тело человека спереди или сзади) просто последовательно отрисовываем нужные элементы из атласа в позиции соответствующей карте из пункта 2. Для интенсивности вешаем на отрисовку нужного элемента простой шейдер, который раскрасит его в заданный цвет.
4. Это смело можно делать в рантайме, нужно загрузить только один (или два в зависимости от ограничений на текстуры) атлас. Таким образом отображаем любую картинку, которая будет соответствовать данным — карта с название группы мышц и степенью нагрузки. А хранить исключительно данные тренировки

Может уже писали в комментариях, но… блин…

Еще очень хорошая статья про линейную алгебру для игр, безотносительно движка

И вместо того, чтобы координировать между собой менеджеров и одновременно релизить фичи, был придуман весь этот ад с разделением людей

Тогда бы не о чем было рассказывать на конференции, а так есть гильдии. У меня складывается впечатление, что есть какой-то глобальный челендж