Game++. Patching patterns

Книга Design Patterns: Elements of Reusable Object-Oriented Software («Приёмы объектно-ориентированного проектирования. Паттерны проектирования»), также известная под названием "синей книги", по цвету обложки первого издания, или книги "банды четырех/GoF" издана почти тридцать лет назад. Для такой отрасли, как разработка игр, если смотреть на игры, как на программное обеспечение, это средние века. О правильности сформулированных в этой книге решений говорит хотя бы то, что её рекомендуют к прочтению до сих пор, и на основе этих рекомендаций строят новые системы и фреймворки, хотя вот сами фреймворки особым долголетием не отличаются. Я всё еще считаю, что книга актуальна - как базовые знания вроде математики, алгоритмов и примитивов синхронизации, но за прошедшие годы люди создали и обнаружили множество новых, хоть и не таких известных. А некоторые паттерны, настолько стали, затаскаными что ли, что превратились скорее в антипаттерны, как например, Singleton и совсем потерялся смысл его использования. И там где разумное применение не приносит больше вреда, но позволяет развязать зависимости, создание архитектуры на таких принципах - ведет только к разбуханию кода, и коду ради кода. Другие шаблоны, например Command/Flyweight были забыты и мало применяются в общем софтостроении, но прочно обосновались в разработке игр и интерактивных системах. Собственно о таких вещах и хотел рассказать в этой статье, и показать несколько специфичных шаблонов, применяемых в игрострое, о которых вы врядли услышите за его пределами, или будете порицаемы за их использование. Заходите, великов и граблей хватит на всех.

https://habr.com/ru/articles/903744/

#с++ #game++ #разработка_игр #управление_проектами

RAII 2.0: RAII как архитектурный инструмент в C++

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

https://habr.com/ru/articles/901092/

#С++ #RAII #Жизненный_цикл #Подписки #Транзакции #Безопасность_кода #управление_ресурсами #паттерны #Логический_контракт

Game++. Work hard

Разнесение выполнения (concurrent) систем играют ключевую роль в играх — от обновления поведения ИИ и физики до рендеринга и загрузки ресурсов. Разные модели параллелизма позволяют по-разному организовать работу потоков, распределяя задачи и определяя, как потоки взаимодействуют между собой для достижения общей цели. Правильно выбранная модель влияет не только на производительность, но и зачастую на стабильность игры. Модели выполнения используются разные — от простой многопоточности с ручной синхронизацией до более продвинутых систем акторов, job-based подходов или task graph. Например, системы поведения ИИ могут обновляться параллельно с физикой, пока основной поток отвечает за рендеринг. Некоторые движки, такие как Unreal Engine, используют task graph (граф задач), где зависимости между задачами выражаются явно, и задачи автоматически распределяются по доступным ядрам. Другие подходы, как в CryEngine Perth (аналог ECS, матрица задач), позволяют организовать данные так, чтобы минимизировать ложные зависимости и повысить кэш-эффективность. Конечный выбор всегда зависит от архитектуры движка, платформы и требований конкретной задачи или группы задач.

https://habr.com/ru/articles/898930/

#с++ #разработка_игр #игры_и_игровые_консоли #game++

Как управлять памятью в C#: StructLayout

Привет, Хабр! Сегодня рассмотрим тему, которая обычно ассоциируется с C или Rust, но никак не с C#. А именно — ручное управление памятью , байтовые смещения , бинарная сериализация и прочая низкоуровневые вещи. Зачем? Допустим, в одном из проектов потребовалось прочитать старый бинарный лог от С-подобной прошивки. Формат документации был: offset 0 — 1 byte: Type; offset 1 — 2 bytes: ID; offset 3 — 4 bytes: Timestamp; и т.д. Разбирать всё это вручную с BinaryReader? Нет, спасибо. Можно воспользоваться StructLayout, FieldOffset, MemoryMappedFile, Unsafe.As<T>() и Span<byte>.

https://habr.com/ru/companies/otus/articles/897264/

#С# #управление_памятью #ручное_управление_памятью #байтовые_смещения #бинарная_сериализация

Хеш-таблица и C++20

Рассматриваем различные «приколюхи» из C++20 на примере хеш‑мапы! В статье я разобрал разные способы реализации тех или иных методов в хеш-мапе, так же провел небольшой анализ над ними. Статья является научно-просветительской и немного исследовательской. Читать далее статьи от @SEIka69

https://habr.com/ru/articles/897924/

#с++20 #hashmap #хештаблица #оптимизация_кода #фичи #stl #stl_containers #задачи_для_программистов #производительность

Game++. Heap? Less

Один из частых вопросов, которые я получаю от студентов или на наших внутренних студийных лекциях, — это какую стратегию выделения памяти лучше применять при разработке? Ответ: хотелось бы никакую, т.е. не использовать аллокации рантайм, но жизнь вносит свои коррективы. Мы все знаем, что нельзя просто выделять память, когда вздумается, но откладываем решение этой проблемы до конца проекта. К тому времени дедлайны начинают давить, майлстоуны и некоторые части тела подгорать, и обычно уже слишком поздно, чтобы вносить серьезные изменения. Ну хотябы есть пара недель перед релизом, чтобы поправить основные проблемы. Динамическое выделение памяти — это как раз то, что относится к той категории вещей для большинства программистов, о которой все знают, но забивают пока не приходит OOM. Хотя немного продуманности и предварительного планирования могут помочь избежать большинства этих проблем, и даст небольшую надежду, что игра не вылит по памяти в самый неподходящий момент. Попробую убедить вас не использовать std::string/vector в функциях. При написании кода для пк, неважно - игры это или что-то другое, программа обычно разделяется на условно пять областей памяти. Burn them all

https://habr.com/ru/articles/896958/

#с++ #высокая_производительность #игры_и_игровые_приставки #разработка_игр

Как правильно готовить std::span

Сегодня мы поговорим про std::span и как не порезаться на острых углах C++. Согласно определению на cppreference, шаблон класса span описывает объект, который может ссылаться на непрерывную последовательность объектов, где первый элемент последовательности находится на позиции ноль. Вообще, с учётом того, что, начиная с С++17 мы уже знакомы с понятием string_view, можно представить, что std::span — это нечто подобное, только действующее для непрерывных участков памяти, которые ещё можно и модифицировать. Но не будем забегать вперед, обо всех свойствах по-порядку.

https://habr.com/ru/companies/slurm/articles/896896/

#с++20 #span #c++26 #с++

Кроссплатформенный терминал Modbus TCP / RTU / ASCII с открытым исходным кодом: Часть 4

Терминальная программа – это многофункциональный кроссплатформенный инструмент инженера, который позволяет взаимодействовать с внешним устройством или сервером. Приложение поддерживает различные вариации протокола Modbus, а также дает возможность работы с данными в строковом или байтовом формате. В этом обновлении я расширил работу с макросами. Теперь макросы поддерживают отправку нескольких сообщений за раз. А еще появился конструктор макроса, в котором можно отправлять как отдельные сообщения, так и весь макрос целиком. Подробнее читайте в этой статье!

https://habr.com/ru/articles/895692/

#modbus_rtu #modbus_tcp #ascii #avalonia_ui #terminal #терминал #com #кроссплатформенность #с# #макросы

Почему игродев остается на С++17

Последние пару-тройку лет на конференциях все чаще я слышу жалобы знакомых в игрострое о том, что текущий вектор развития "современного C++" не соответствует потребностям игровой разработки. Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке. Пошатавшись по разным игровым студиям, блин, скоро будет 15 лет как я тут, у меня таки немножечко есть, что вам рассказать. Все современные студии, что крупнее двух с половиной землекопов, пишущие игры на плюсах, шарпе или чем-то близком - используют Visual Studio или переходят со своих поделок на Unreal/Unity, который так-то тоже плюсы, хоть и со странностями. Так исторически сложилось, что винда и майки были, есть и в ближайшем будущем горизонта лет десяти останутся самым крупным рынком ПК-консольных игр, а сами консоли давно стали "ну совсем ПК", но чтобы не терять эксклюзивы (и шекели) вендоры в этом не признаются никогда. Мобилки, как-бы отдельно, и там свои свои покемоны Mac с Android, но в Visual Studio в том или ином виде создаются, дебажатся и оптимайзятся 95% игр, остальное - погрешность. С момента начала золотой эры игростроя (где-то в конце 90-х), большинство игр писались с учетом того, что они будут выпущены на ПК, под ПК понимается - под винду. И наследие многих A+-студий так или иначе связано с Microsoft, даже для не-Microsoft консолей и мобилок.

https://habr.com/ru/articles/894736/

#с++ #с++17 #игры #игры_и_игровые_приставки #ненормальное_программирование

Game++. Unpacking containers

Независимо от того, начинаете ли вы разрабатывать свою игру или присоединяетесь к уже существующему проекту, когда приходит время оптимизировать память и заниматься разным улучшайзингом, то всегда встают одни и те же вопросы. Стоит ли использовать собственные контейнеры? Если использовать свои, то какой лучше выбрать - похожий на vector, или больше подойдет map? Является ли связный список наилучшим выбором при частых вставках и удалениях элементов? А откуда эти вставки вообще взялись, но это конечно другой вопрос. В большинстве случаев студии начинают реализовывать свои решения, заточенные под игру, это со временем приводит к появлению библиотеки решений, а частенько и полной замене всего STL стека. Основная причина - это добиться непрерывного размещения элементов в памяти, чтобы максимизировать локальность кэша при их обходе. Надеюсь, понятно для чего это делают: часто быстрее обойти 1000 элементов, которые лежат друг за другом, чем дюжину, которая раскидана по разным частям оперативки. Если вы не готовы писать и поддерживать свою STL, старайтесь, использовать vector, он хотя бы предсказуем по времени на всех платформах. Так вам скажет большинство разработчиков игр на C++, но проблема в том, что vector перераспределяет хранимые объекты в памяти при вставке новых элементов, а также при удалении любого элемента, кроме последнего. Это означает, что указатели на элементы вектора становятся недействительными, и тогда все зависимости и взаимодействия между элементами перестают работать. Конечно, можно обращаться к элементам через индексы вместо указателей, но индексы тоже теряют актуальность при вставке или удалении элементов не с конца контейнера. К тому же, аллокация памяти тоже небесплатная и может сильно подкосить перф при неправильном использовании. Да, вектора много где выигрывают у других контейнеров, но не одним только вектором жив игрострой, у нас есть кое-что и побыстрее и постабильнее.

https://habr.com/ru/articles/891700/

#с++ #игры_и_игровые_приставки #разработка_игр #программирование #ненормальное_программирование