Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/ Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Вы не правы в том, что производительность не ассоциирована с ECS
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Практически все ее упоминания или реализации на этом сосредоточены и так было с момента ее создания.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Безусловно важным фактором является и разделение логики и данных - и, на самом деле, я критикую это не в последнюю очередь как способ создать реально сложные и плохо обслуживаемые решения
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
ООП буквально придуман для того, чтобы собрать это вместе по хорошей причине - локальность данных и кода
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Я бы не сказал, что сложные задачи, где нужны гибкие отношения многих ко многим сильно упрощаются в ecs
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня. Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов. Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места. Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
Пул не подразумевает выделение памяти при создании новых экземпляров (не его задача), он подразумевает выделение памяти под хранение ссылок на отработанные экземпляры для дальнейшего их переиспользования, что слегка отличается от арены как аллокатора памяти.
Это про пул экземпляров одного типа, не более того. Арена подразумевает выделение большого непрерывного блока памяти, внутри которого уже самостоятельно выделять память под экземпляры разных типов, а освобождать не по одному экземпляру, а память арены целиком.
Перечень вредных советов какой-то. Горотины не бесплатны сами по себе + синхронизация может съесть все выигранное время и даже больше + нужна блокировка множественного доступа к ресурсам. Применять их стоит только осознанно и только в подготовленном окружении.
При возвращении указателя, объявлять его при создании переменной
Субъективщина же, скорость может поменяться в худшую сторону внутри метода, если анализатор увидит, что указатель может стать nil.
Используйте for-loop
Тут вообще хрень написана - тесты надо проводить на реальных примерах, а не на пустых циклах. Самый простой случай: обращение по индексу в слайс - for-loop будет медленнее из-за постоянного bounds-check если не сделать дополнительные проверки внутри тела цикла, что приведет к замедлению по отношению к range-loop. В случае range-loop компилятор понимает, что нарушения границ быть не может и не вставляет эти проверки. Сравнять скорость можно только используя флаг компиляции -gcflags=all="-B", отключающий все проверки на границы.
Есть только 3 рациональных варианта использования for-loop:
нужно идти с шагом, отличным от 1.
реверсивный цикл, это можно будет обойти через range-over-func в 1.23.
если коллекция состоит из жирных объектов, которые range-loop будет принудительно копировать, то for-loop становится выгоднее, если ползать в слайс через указатели.
Он не спал, он активно хайпожорил, что это все говно и никому не нужно, покупайте мои ооп-курсы. Всех, кто приходил к нему в тележковый чатик и случайно упоминал запретное слово "ECS" - сначала обсирал, а потом просто банил. Почему мне в принципе смешно от ситуации - я автор этого фрейма, который он 4 года назад назвал поделием школьника, а теперь продает на нем курсы, хотя он уже устарел и не поддерживается. :)
Какой "чистый код", он анонсировал курс по ECS, который 4 года назад яростно хейтил, причем на том же фреймворке, который и поливал тогда говном. Конъюктурщик чистой воды. Для любителей "чистого кода" в геймдеве (а не в разработке бизнес-приложений), где важна производительность, а не максимальное распиливание на абстракции - есть вот такое занимательное видео: https://www.youtube.com/watch?v=oFiY7EEtAW4
Нет, имелось ввиду, что после настройки пары циферок и нажатия на апаратную кнопку отладчика происходил множественный переход с конечным адресом в 0. Это не мешало обычной работе и срабатывало только при попытке входа в сервис-монитор.
Да, но там много делать не нужно было, достаточно было поправить адрес в блоке памяти, куда писались настройки принтера и прочий мусор, а в скорпионе было модифицированное местами пзу - переход в итоге делался по новому адресу в пзу, который в итоге приводил к переходу в 0 (reset). Точнее сказать уже не смогу, последний раз эту железку видел более 25 лет назад.
Еще как писали. У меня как раз был такой - ZS Scorpion 256 с аппаратным отладчиком. Там так же происходила запись в определенные регистры и вызов прерываний для переключения страниц. Вот этим и пользовались, записывая мусор, что приводило либо к подвисанию, либо к рестарту.
Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
В LeoECS нет кодогенерации, ответственно заявляю как автор.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/
Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня.
Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов.
Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места.
Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
Почему не krita - и для работы с референсами с обводкой и для пиксельарта?
Пул не подразумевает выделение памяти при создании новых экземпляров (не его задача), он подразумевает выделение памяти под хранение ссылок на отработанные экземпляры для дальнейшего их переиспользования, что слегка отличается от арены как аллокатора памяти.
Это про пул экземпляров одного типа, не более того. Арена подразумевает выделение большого непрерывного блока памяти, внутри которого уже самостоятельно выделять память под экземпляры разных типов, а освобождать не по одному экземпляру, а память арены целиком.
Перечень вредных советов какой-то. Горотины не бесплатны сами по себе + синхронизация может съесть все выигранное время и даже больше + нужна блокировка множественного доступа к ресурсам. Применять их стоит только осознанно и только в подготовленном окружении.
Субъективщина же, скорость может поменяться в худшую сторону внутри метода, если анализатор увидит, что указатель может стать nil.
Тут вообще хрень написана - тесты надо проводить на реальных примерах, а не на пустых циклах. Самый простой случай: обращение по индексу в слайс - for-loop будет медленнее из-за постоянного bounds-check если не сделать дополнительные проверки внутри тела цикла, что приведет к замедлению по отношению к range-loop. В случае range-loop компилятор понимает, что нарушения границ быть не может и не вставляет эти проверки. Сравнять скорость можно только используя флаг компиляции
-gcflags=all="-B", отключающий все проверки на границы.Есть только 3 рациональных варианта использования for-loop:
нужно идти с шагом, отличным от 1.
реверсивный цикл, это можно будет обойти через range-over-func в 1.23.
если коллекция состоит из жирных объектов, которые range-loop будет принудительно копировать, то for-loop становится выгоднее, если ползать в слайс через указатели.
Он не спал, он активно хайпожорил, что это все говно и никому не нужно, покупайте мои ооп-курсы. Всех, кто приходил к нему в тележковый чатик и случайно упоминал запретное слово "ECS" - сначала обсирал, а потом просто банил. Почему мне в принципе смешно от ситуации - я автор этого фрейма, который он 4 года назад назвал поделием школьника, а теперь продает на нем курсы, хотя он уже устарел и не поддерживается. :)
Какой "чистый код", он анонсировал курс по ECS, который 4 года назад яростно хейтил, причем на том же фреймворке, который и поливал тогда говном. Конъюктурщик чистой воды.
Для любителей "чистого кода" в геймдеве (а не в разработке бизнес-приложений), где важна производительность, а не максимальное распиливание на абстракции - есть вот такое занимательное видео: https://www.youtube.com/watch?v=oFiY7EEtAW4
Это в коде еще lifetime-ов не было, количество знаков пунктуации удвоилось бы.
Нет, имелось ввиду, что после настройки пары циферок и нажатия на апаратную кнопку отладчика происходил множественный переход с конечным адресом в 0. Это не мешало обычной работе и срабатывало только при попытке входа в сервис-монитор.
Да, но там много делать не нужно было, достаточно было поправить адрес в блоке памяти, куда писались настройки принтера и прочий мусор, а в скорпионе было модифицированное местами пзу - переход в итоге делался по новому адресу в пзу, который в итоге приводил к переходу в 0 (reset). Точнее сказать уже не смогу, последний раз эту железку видел более 25 лет назад.
Еще как писали. У меня как раз был такой - ZS Scorpion 256 с аппаратным отладчиком. Там так же происходила запись в определенные регистры и вызов прерываний для переключения страниц. Вот этим и пользовались, записывая мусор, что приводило либо к подвисанию, либо к рестарту.
Аналогично, только поднял в докере https://github.com/usememos/memos без доступа извне - вполне удобно и без тегов, ищет по словам в заметках.
PowerBlade, SpinTales, NinjaGaiden, BattleToads&DoubleDragons, Jackal, SnakeRattle&Roll