Software Engineer, Bachelor of Computer Science
После статьи о книгах для саморазвития gamedev программиста, меня просили больше написать про аишную часть и том, что стоит почитать по этой теме. Для программиста ИИ в игрострое ситуация с книгами схожа, но с несколькими интересными особенностями. Здесь важна не только глубина знаний, сколько наработанность с инструментами, библиотеками и технологиями в целом, а с учетом что новые подходы развиваются с поразительной скоростью, поразительной для игростроя конечно. Казалось только лет 10 назад стали использоваться BT (behavior tree), но и они уже имеют редакцию 4.x (https://www.behaviortree.dev/). Но важно не зацикливаться на затаскивании в проект модных примочек, базовые знания остаются самым важным что можно получить. Это как в притче о удочке — дай человеку рыбу, и он накормит себя сегодня; дай ему удочку, и он будет кормить себя всю жизнь. Удочкой в этом случае выступает знание, как оно работает, а не как можно его использовать.
ИИ до сих пор стоит в игрострое особняком, потому что до сих пор нет стандартов построения игровой логики, каждая из студий решает свои уникальные технические и инженерные задачи, и вынуждена находить баланс между чем-то новым и общей стабильностью игры. Этот путь усеян пробами и ошибками, даже если вы уже прошли по нему в прошлом, и мало кто поможет вам увидеть ошибки заранее, банально потому, что прошел по другому пути, со своими граблями и костылями. Тем хуже когда, именитый разработчик приходит в команду и начинает продавать свои решения и опыт, которые часто не бьются с разработками команды. Но, статья не об этом, а о полезных книгах.
Игры всегда требовали высокой производительности системы, а игровые движки разрабатывались с учетом надлежащей поддержки многопоточных вычислений, чтобы задействовать все ресурсы компьютера. Но применение хороших абстракций сильно усложняет разработку и хотя многопоточность открывает очень широкие возможности в играх, проблем она также добавляет порядком. Вообще разработка любого софта с поддержкой многопоточности — это отдельный вопрос, и статей на эту тему написано немало. Здесь я решил показать основные шаблоны применения системы задач, которая с большой вероятностью будет реализована в любом игровом движке, ну а также их плюсы и минусы разных подходов.
Большинству игр «хватает» одного потока, это обычно подразумевает наличие главного треда, где выполняются все игровые задачи (обработка ввода, обновление мира, рендеринг и т. п.), для каждого кадра. И такая модель последовательных вычислений сохранялась очень долго, да и сейчас применяется в большом числе игр, особенно мобильных, задействую ресурсы одного ядра. Есть конечно хорошо выделяемые задачи, вроде загрузки текстур, звуков, но это скорее исключение, в силу обособленности данных для таких задач. Чтобы сделать исключение правилом разработчики игровых движков приучают пользователей этих самых движков разделять игровые «циклы» на независимые «задачи», которые могут выполняться отдельно в «менеджере задач», который уже в свою очередь может запускать их на разных ядрах. Профит тут конечно очевидный — параллельное выполнение — это основной фактор повышения производительности игр.
Что еще можно вынести в другой поток без особого ущерба для игры?
Существует класс приложений реального времени, для которых тяжело предсказать потребности в распределении памяти во время выполнения статически. В этот класс входят, например, встраиваемые реализации стеков некоторых коммуникационных протоколов, где поведение и распределение ресурсов определяется отчасти активностью других агентов в сети. Классический подход в таких случаях заключается в использовании блочных менеджеров памяти, выделяющих фрагменты фиксированного размера (как это сделано, например, в LwIP). Этот подход накладывает нежелательные функциональные и качественные ограничения на реализацию. В этой заметке я предлагаю точку зрения, что традиционные (не блочные) аллокаторы незаслуженно обделены вниманием разработчиков систем реального времени, делюсь соображениями по релевантным вопросам, жалуюсь на жизнь, и предлагаю улучшить положение дел.
(КДПВ – см. аннотацию к диаграмме в конце)
Несмотря на то, что материалов на тему move-семантики и идеальной передачи в Интернете предостаточно, вопросов типа «что я должен здесь использовать: move или forward?» не становится меньше или мне просто «везет» на них. Поэтому и решено было написать эту статью. Предполагается, что читатель хотя бы немного знаком с rvalue-ссылками, move-семантикой и идеальной передачей.
В разработке игр динамические и статические массивы являются основным инструментом при работе с набором объектов, буду дальше называть их vector. Вы можете подумать про разные map, set, и другие ускоряющие структуры, но их тоже предпочитают делать поверх векторов. Почему так? Вектора просты для понимания, удобны для большого числа задач, особенно там, где объём данных заранее неизвестен или примерно известен. Но как вы понимаете, за все надо платить, и расплачиваться приходится производительностью, которой, как обычно, всегда не хватает. Так что, использование динамических массивов имеет свои ограничения и особенности.
Oh, and the documentation: It's extensive but never tells me what I need to know.
Эта цитата взята из обсуждения CMake на Reddit, и она очень точно описывает большую часть моих проблем с CMake: когда я хочу что-то сделать, документация не помогает с этим вообще, - приходится искать решения в чужих проектах и статьях.
В этой статье будут разобраны проблемы, с которыми я столкнулся в процессе изучения Vulkan. Однако материал будет полезен и тем, кто настраивает любой другой проект.
Когда мне предстоит начать работу с новым микроконтроллером, я обычно гляжу, а какое у него быстродействие GPIO. Сколько тактов на одну запись уходит по факту. Такая у меня традиция. Было дело, я так выяснил, что китайские клоны STM32 работают с GPIO чуть быстрее, чем оригинал. Для дешёвых контроллеров обычно ничего более интересного такие проверки не выявляют, но традиция есть традиция. Не изменял я ей и при начале освоения CH32x035 на базе RISC-V. И вот для него картинки получились такими интересными, что я решил поделиться ими с общественностью. Не то, чтобы там было что-то революционное, но от привычных мне они точно отличаются.
А ещё я добавлю к ним немного выводов… И нутром чую, что в комментариях мне объяснят, что я понимаю всё неправильно, а на самом деле… Но я буду только рад обоснованным высказываниям. Вместе мы установим истину.
Вы когда-нибудь задумывались о том, что у человеческого мозга есть ограниченная емкость и вы можете выучить этот чертов английский просто потому что в детстве запомнили слишком много покемонов? Или почему обучение с учителем гораздо эффективнее, чем самостоятельное?
Эти вопросы вполне применимы и в области машинного обучения. Для обучения модели диффузии требуется много данных и вычислительной мощности, а затем для создания изображений требуется значительное количество вычислений и серьезное оборудование. Исследователи (у которых обычно нет денег и на доширкак) задали очень хороший вопрос - можно ли достичь тех же результатов с меньшими усилиями?
В своей работе я больше склоняюсь к стилизованной картинке, однако полученный в статье результат можно будет адаптировать и для реалистичного стиля/PBR. В этом посте мы поговорим о шейдере воды, относящемся к береговой линии, не касаясь материала песка и других деталей воды, например, преломления и каустики (о них можно прочитать в Water Shader Breakdown или по другим ссылкам в разделе Water на странице Resources). Впрочем, шейдер выполняет и смешение прозрачности/альфы, чтобы затенить материал под ним для симуляции мокрого песка.
Мы поговорим о двух способах наложения волн в сцене: при помощи текстуры глубин и ручных UV. Ниже я перечислю замечания, плюсы и минусы каждого способа. В последующих разделах мы поработаем над ними по очереди.
«String interning», иногда это называют «пулом строк» — это оптимизация (https://en.wikipedia.org/wiki/String_interning), при которой хранится только одна копия строки, независимо от того, сколько раз программа ссылается на нее. Среди других оптимизаций по работе со строками (SWAR, SIMD-cтроки, immutable strings, StrHash, Rope string, и немного других), часть которых была описана тут, она считается одной из самых полезных оптимизаций в игровых движках, есть правда небольшие недостатки у этого подхода, но экономия памяти и скорость работы при правильной подготовке ресурсов и работе с лихвой их перекрывают.
Вы 100% когда-нибудь писали одну и ту же строку несколько раз в одной программе. Например:pcstr color = "black"; А позже в коде пришлось написать: strcmp(color, "black");Как видите, строковый литерал "black" встречается несколько раз. Означает ли это, что программа содержит две копии строки "black"? Более того, означает ли это, что в оперативную память загружаются две копии этой строки? На оба вопроса ответ — зависит от компилятора и вендора. Благодаря некоторым оптимизациям в сlang (Sony) и GCC, каждая строка-литерал хранится в программе только в одном экземпляре, и, следовательно, только одна копия загружается в оперативную память, поэтому иногда cтановятся возможными разные фокусы.
Пробуем разобраться, как устроен знаменитый AFL++ изнутри. Часть 1.
Написание этой статьи было вызвано отсутствием комплексных материалов о структуре фаззера AFL++ (American Fuzzy Lop plus plus) на русском языке, а также необходимостью устранить собственные пробелы в знаниях.
Многомерная линейная регрессия — один из основополагающих методов машинного обучения. Несмотря на то, что современный мир интеллектуального анализа данных захвачен нейронными сетями и градиентным бустингом, линейные модели до сих пор занимают в нём своё почётное место.
В предыдущих публикациях на эту тему мы познакомились с тем, как получать точные оценки средних и ковариаций методом Уэлфорда, а затем научились применять эти оценки для решения задачи одномерной линейной регрессии. Конечно, эти же методы можно использовать и в задаче многомерной линейной регрессии.
Случайно попалась довольно старая статья 2018 года с простым и понятным описанием категорий значений в C++. До неё всякие glvalues, prvalues, xvalues были малопонятными для меня.
cppreference.com просто перечисляет категории, и это не добавляет понимания, всё кажется чрезмерно излишним.
На stackoverflow.com есть 24 поста разной степени ценности, что только добавляет недоумения от сложности этой темы.
Сегодня я покажу, как модифицировать powershell shellcode runner для загрузки и выполнения нагрузки в обход Windows Defender.
Я буду использовать shellcode runner, который применял ранее.
Для демонстрации я использую виртуальную машину Windows с временно отключённым Defender. Я скопирую код и создам на его основе новый файл, используя PowerShell ISE.
Всем привет! Меня зовут Андрей, я Frontend разработчик. На данный момент работаю на фрилансе. Имею достаточно хороший опыт работы с React.
Хочу рассказать, что такое React Context и как это можно использовать в проектах.
Попробую всё рассказать как можно проще.
Вероятнее всего у вас спрашивали на собесе «как работают корутины под капотом?», вы не долго думая выбрасывали что‑то в стиле «там под капотом стейт‑машина, она определяет какая suspend функция будет выполняться», но понимали ли вы на самом деле о чем говорили? Возможно, но если честно я плохо понимал собственные ответы на такие вопросы и даже после десятка пройденных собесов у меня не было полноценной картины как работает внутрянка этой поистине невероятной библиотеки «сладкой асинхрон
