Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

После статьи о книгах для саморазвития gamedev программиста, меня просили больше написать про аишную часть и том, что стоит почитать по этой теме. Для программиста ИИ в игрострое ситуация с книгами схожа, но с несколькими интересными особенностями. Здесь важна не только глубина знаний, сколько наработанность с инструментами, библиотеками и технологиями в целом, а с учетом что новые подходы развиваются с поразительной скоростью, поразительной для игростроя конечно. Казалось только лет 10 назад стали использоваться BT (behavior tree), но и они уже имеют редакцию 4.x (https://www.behaviortree.dev/). Но важно не зацикливаться на затаскивании в проект модных примочек, базовые знания остаются самым важным что можно получить. Это как в притче о удочке — дай человеку рыбу, и он накормит себя сегодня; дай ему удочку, и он будет кормить себя всю жизнь. Удочкой в этом случае выступает знание, как оно работает, а не как можно его использовать.

ИИ до сих пор стоит в игрострое особняком, потому что до сих пор нет стандартов построения игровой логики, каждая из студий решает свои уникальные технические и инженерные задачи, и вынуждена находить баланс между чем-то новым и общей стабильностью игры. Этот путь усеян пробами и ошибками, даже если вы уже прошли по нему в прошлом, и мало кто поможет вам увидеть ошибки заранее, банально потому, что прошел по другому пути, со своими граблями и костылями. Тем хуже когда, именитый разработчик приходит в команду и начинает продавать свои решения и опыт, которые часто не бьются с разработками команды. Но, статья не об этом, а о полезных книгах.

В разработке игр динамические и статические массивы являются основным инструментом при работе с набором объектов, буду дальше называть их vector. Вы можете подумать про разные map, set, и другие ускоряющие структуры, но их тоже предпочитают делать поверх векторов. Почему так? Вектора просты для понимания, удобны для большого числа задач, особенно там, где объём данных заранее неизвестен или примерно известен. Но как вы понимаете, за все надо платить, и расплачиваться приходится производительностью, которой, как обычно, всегда не хватает. Так что, использование динамических массивов имеет свои ограничения и особенности.

C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?

Кроме того, такая практика приводит к ожидаемым проблемам с производительностью даже в обычных приложениях, чего уж говорить про высоконагруженные системы или игры, которые претендуют на что-то быстрее 20 фреймов в секунду.

Пытаться оптимизировать код, который использует системные аллокаторы, — всё равно что сгребать листья в кучу ветреным днём: куча, конечно, сгребается, но постоянно приходится махать грабельками, чтобы она оставалась на одном месте. Даже если выделения памяти происходят последовательно, друг за другом, вот прям без всяких перерывов, нет гарантии, что эти участки будут расположены хотя бы близко друг к другу. В результате при обработке таких данных процессору приходится прыгать по разным участкам памяти, теряя такты просто на поиск данных вместо того, чтобы работать с ними.

Я отнюдь не призываю вас встать на путь ручного управления памятью, ибо он будет усеян ловушками, граблями и чреват утечками. Но разработчик в итоге оказывается перед выбором: либо довериться системному аллокатору и столкнуться с проблемами вроде размазанного перфа, когда вроде и код написан правильно, модно и молодежно, но отчего-то работает небыстро, либо взять всё в свои руки, создавая собственные механизмы выделения и освобождения ресурсов.

Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?

Здравствуйте, на связи nikhotmsk с очередным потоком сугубо-технических мыслей. В своей прошлой статье я обещал не использовать жаргонный язык и улучшить читаемость статей. Так вот, сообщаю, что из этого ничего не получилось. Поэтому если вы ничего не поймете, то это значит, что у вас не хватило знаний, как говорил персонаж из книги - "Чтобы что-то узнать, надо уже что-то знать". Но расстраиваться не нужно.

Глядя на главную картинку вы уже почувствовали неладное. Да, я программирую для старинного компьютера ZX Spectrum. Того самого, который построен на чипе Zilog Z80, и у которого графическая память, пожалуй, самая запутанная среди всех ретро-машин. Но наша статья не об этом, а о том, как всё же совместить Ассемблер и Си. Методы, описанные здесь, скорее всего подойдут и к вашему проекту. Ведь теория остается неизменной.

Как создать быстрый код на C++? Мы будем разбираться в современных техниках оптимизации: кэш-локальности, кастомных аллокаторах и многопоточности. Практические примеры и результаты тестов.

▍ Навигация по вышедшим частям

• Часть 1
• Часть 2
• Часть 3 < — вы здесь
• Часть 4
• Часть 5

▍ Навигация по вышедшим частям

• Часть 1
• Часть 2 < — вы здесь.
• Часть 3
• Часть 4
• Часть 5

1. Модули и краткая история C++.
2. Операция «космический корабль».
3. Концепты.
4. Ranges.
5. Корутины.
6. Другие фичи ядра и стандартной библиотеки. Заключение.

В этой статье мы подробно разберем понятие сопрограмм (coroutines), их классификацию, детально рассмотрим реализацию, допущения и компромиссы, предлагаемые новым стандартом C++20.

Когда вы стоите на поверхности Земли, вы испытываете столкновения окружающих атомов и молекул атмосферы с вашим телом. То же делают и фотоны, частицы света. Некоторые из этих частиц особенно энергичны и могут отбрасывать электроны от атомов и молекул, с которыми они обычно связаны, создавая свободные электроны и ионы, которые тоже могут столкнуться с вами. Через ваше тело проходят призрачные нейтрино и антинейтрино, хотя они редко взаимодействуют с вами. Но с вашим телом происходит гораздо больше, чем думаете.

По всей Вселенной, от звёзд, чёрных дыр, галактик и т. д. испускаются космические лучи — частицы, несущиеся через Вселенную с высокими энергиями. Они попадают в атмосферу Земли и вызывают ливни как стабильных, так и нестабильных частиц. Те из них, которые живут достаточно долго, прежде чем распасться, в конечном итоге попадают на поверхность Земли. Каждую секунду через ваше тело проходит от 10 до 100 мюонов — нестабильных, тяжёлых кузенов электрона. При среднем времени жизни в 2,2 микросекунды можно подумать, что они не могли бы пройти всю толщину атмосферы, ~100 с лишним километров, от космоса до вашей руки. Тем не менее, теория относительности утверждает, что это происходит, и тот факт, что эти мюоны проходят через ваше тело, более чем достаточен для доказательства её правоты.

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

Своим постом автор Jenny Jam* пытается заполнить этот пробел. Он рассуждает, когда C — идеальный выбор, а когда лучше обратиться к другим языкам. Описывает, как настроить среду разработки и выбрать инструменты, разобраться в версиях, особенностях сборки и тонкостях работы с библиотеками.

Цель статьи — упорядочить представление о языке C и его экосистеме, и, конечно, дать практические советы, которые пригодятся в реальных проектах.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

В этой статье описано создание эмулятора 16-битной приставки Sega Mega Drive на C++.

Будет много интересного: эмуляция процессора Motorola 68000, реверсинг игр, графика на OpenGL, шейдеры, и многое другое. И все это на современном C++. В статье много картинок, можно хоть на них посмотреть.

Оптимизация SQL-запросов является одной из ключевых задач при работе с реляционными базами данных. Эффективные SQL-запросы позволяют значительно улучшить производительность приложений и обеспечить более быстрый доступ к данным. В данной статье мы рассмотрим как переписать запрос, чтобы выполнялся быстрее. В статье пойдет речь о PostgreSQL, хотя применять данные советы к любой базе данных SQL Ниже будут представлены термины и операторы, о которых пойдет в данной статье.

Асинхронный код часто становится камнем преткновения для начинающих разработчиков. Почему функции выполняются не в том порядке, зачем нужны промисы, и что делает async/await? В статье я простыми словами объясняю:

• Как работает Event Loop и почему это важно.
• Какие ошибки чаще всего допускают джуны при работе с асинхронностью.
• Как научиться писать понятный и предсказуемый асинхронный код.

Если асинхронность вызывает больше вопросов, чем ответов, загляните в статью - там всё по шагам. 🙂