C++ *

Event System на C++: реализация без макросов, сложной обвязки и непонятного синтаксиса. Только чёткий и управляемый код.

История начинается в далёком 2019 году, а может, и немного раньше. Уже два года я благополучно перестал работать на дядю, ибо понял, что много денег не заработаю, а здоровье гробится конкретно. А рабство — это не моё. Хотя для страны, откуда я родом, 2500$ в месяц, из которых 500$ уходило на аренду жилья и еду, — это неплохо. Остальное копи, откладывай, трать по желанию. Не бедствовал.

Осень 2017-ого года. Я увольняюсь и лечу смотреть мир, в далекую Индию (тема целой отдельной статьи). Золотое время до макаронобесия. Тогда у меня был слабенький ноутбук 10"(На Unity я буду разрабатывать, используя настольный PC), который я сменил на acer n3700 cpu году так в 2019-ом. И вот мне пришло в голову разработать свой AI, когда ChatGPT ещё даже не маячил на горизонте и не стал мэйнстримом. Шла разработка на java, языке, который я использовал в своей карьере. Но быстро понял, что java не то, что нужно, особенно для UI визуализации графов данных и графа знаний AI.

В Steam завершился «Фестиваль передвижных ящиков», посвященный играм, где разными способами можно передвигать ящики. На английском фестиваль называется «Sokoban Fest» в честь первой игры, где появилась эта механика.

Игра-головоломка «Sokoban» (яп. 倉庫番, рус. кладовщик) вышла в Японии в 1982 году. А разработал ее годом ранее Хироюки Имабаяси. Она имела колоссальный успех. И механика привлекла тогда внимание многих геймдизайнеров, которые стали применять ее в новых играх и продолжают применять в современных играх разных жанров.

В своем проекте X-Drums 2.0 на Unreal Engine 5 мне захотелось добавить эту механику. И в этой статье я расскажу, что из этого получилось и какие еще игры повлияли на финальную реализацию.

В этой статье я поделюсь своей реализацией брелков через CableComponent.

Идея написания данной статьи возникла у меня во время реализации брелков для оружия. Как оказалось, в Unreal Engine на данный момент не существует готовых инструментов для реализации данного аксессуара. Тут можно было подумать, что брелки возможно реализовать через стоковый CableComponent, но как бы не так:

Александр Лонин, руководитель группы полигонального моделирования C3D Labs, к.ф.-м.н, представляет новую разработку компании — полигональное ядро C3D PolyShaper — и рассказывает о новых возможностях инструментов реверс-инжиниринга, алгоритмах модификации при процессинге сеток, диагностике и лечении сеток.

С3D Solver – это инструмент для разработчиков, работающих с 2D и 3D-моделированием. Он позволяет создавать параметрические сборки из твёрдых тел и эскизы, накладывая на них связи (ограничения). Мы остановимся непосредственно на трёхмерном решателе, чтобы на его примере ответить на возникающие у разработчиков приложений вопросы, которые и послужили толчком к написанию данной статьи. Например, расскажем о значении синхронизации представлений геометрических объектов – это наиболее распространенная проблема, возникающая при использовании трёхмерного решателя. А также в рамках статьи погрузимся в основные аспекты работы программиста конечного приложения с С3D Solver, рассмотрим функциональность математической библиотеки и пройдём путь от клика по иконке до сопряжения геометрических объектов на конкретном примере.

Чтобы лучше ориентироваться в предметной области и терминах, которые будут упоминаться, начнём с краткого описания базовых понятий. В статье рассмотрим три представления твёрдых тел. Изображение модели, которую пользователь видит на экране, мы будем называть графическим представлением. Следующее представление – модельное. Оно включает в себя описание топологии моделируемого объекта, связей элементов геометрической модели, историю её построения и атрибуты элементов. За него отвечает геометрическое ядро C3D Modeler. Наконец, есть параметрическое представление, которое обеспечивает взаимосвязь элементов модели, позволяя редактировать её, синхронно изменяя положение тел. Воплощается оно в системе геометрических ограничений GCM_System под управлением C3D Solver, который не имеет прямой связи с твёрдыми телами модельного представления. Отсюда возникает важная особенность – необходимость синхронизации представлений.

Допустим, вы создали свою USTRUCT в C++ и хотите её сериализовать.

Обычно, достаточно просто пометить нужные поля как SaveGame. Но вот проблема, для этого они сами должны поддерживать сериализацию. К сожалению, одна из наших переменных ее не поддерживает. В моем случае, это структура FNonSerializableStruct. Из-за этого сериализуется только вторая структура, хоть мы и пометили SaveGame обе.

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

Трудно предоставить разумный пример иллюстрирующий этот принцип, так как соблюдение элементарной логики и правил чистого кода по именованию методов и переменных, не позволяет его нарушить. Если в базовом классе есть метод save(), отвечающий за сохранение информации, а вы не пытаетесь его переделать для загрузки данных, у вас все в порядке.

Рассмотрим тонкости соблюдения этого принципа, на довольно сложном примере. Начнем с класса хранения данных.

Приветствую всех мододелов и интересующихся!

Сегодня я хочу обсудить внутреннее устройство системы чит-кодов в The Simpsons: Hit & Run 2003.

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

Привет, я Майк.

Недавно я начал работать в компании Manticore на должности Developer Advocate. Я не совсем далёк от ИТ, но сейчас активно осваиваю современные технологии. В этом блоге я буду делиться своим опытом и тем, что узнаю о Manticore. Я планирую вести дневник, где буду рассказывать, что такое Manticore и как с ним работать. Давайте вместе разбираться, как все устроено, выявлять проблемы и взаимодействовать с разработчиками.

Если вам интересно изучать Manticore вместе со мной, я буду держать вас в курсе в:

Всем привет. На Хабре есть довольно большое количество примеров реализации gRPC‑серверов на GO, чуть в меньшей степени на python, еще меньше — на других языках. Поиск примеров данного проекта для C++ дал мне не так много информации, как хотелось бы. К счастью, очень крутое решение-экземпляр есть на официальном сайте (ссылка). Если вам не хочется читать код и комментарии на английском языке, добро пожаловать под кат.

Приветствую всех обитателей Хабра и случайных гостей!
Этой статьёй я хотел бы начать цикл заметок, посвящённых моей научной работе в вузе, связанной с фаззинг-тестированием. Всего на данный момент я работаю над темой 2 семестра.

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

Надеюсь, кому-нибудь это да пригодится ;-)

В цикле статей под общим названием «Связь решения СЛАУ и минимума квадратичного функционала» постараюсь осветить различные методы решения СЛАУ, которые редко можно встретить в учебниках по линейной алгебре. Основная цель – написать понятный, но в то же время наполненный полезной информацией материал. К каждой последующей статье будет прилагаться соответствующая реализация на языке программирования C++.

В этой статье поговорим о том, как можно ускорить свой код, написанный на Python с помощью модулей, скомпилированных через Nim.

Узнаем о том, какие библиотеки в Python написаны на Nim и даже напишем свой небольшой модуль для Python!

Как я и говорил в прошлой части, тут мы попробуем сделать самый простой обмен при помощи MQTT.

Что же из себя представляет MQTT? В первую очередь - это протокол обмена сообщениями. Данные сообщения могут группироваться по древовидной структуре. Мы можем как отправлять их, так и получать, подписываясь на определенные группы в дереве или отдельные сообщения.

Как улучшить качество и надёжность кодовой базы? Один из ответов на этот вопрос — использование статического анализа. В данной статье мы исследуем, как эта методология может улучшить качество кодовой базы на примере проекта CodeLite.

Привет, Хабр!

В данной статье сделан обзор на фреймворк планирования движения BMPF.

На данный момент подавляющее большинство средств планирования движения работает по одному и тому же принципу: вся сцена описывается как один робот, после чего выполняется планирование на сетке (чаще всего A*, подробнее можно прочитать здесь).

У такого подхода есть две основных проблемы:

1) планирование на сетке гарантирует допустимость только состояний в её узлах, промежуточные никак не оцениваются и не проверяются.

2) для сцены из нескольких роботов размерность пространства планирования получается слишком большой (алгоритмическая сложность планирования растёт как показательная функция).

Данный фреймворк решает обе озвученные проблемы. С документацией фреймворка можно ознакомиться здесь.

Пожалуй, любой С++ разработчик на Unreal Engine имел дело с созданием Default Subobject в конструкторе. Через этот механизм, в частности, создаются компоненты по-умолчанию для акторов. Казалось бы, какие нюансы могут быть связаны с использованием такого стандартного функционала?

Между тем, они есть. И если их не учитывать - можно получить весьма странные проблемы.

Время сборки проекта имеет немалое значение в процессе разработки. Начиная с "комфорта" разработчика, при внесении изменений, заканчивая стоимостью оборудования, необходимого для организации CI.

Ваш код принимает данные извне? Поздравляем, вы вступили на минное поле! Любой непроверенный ввод от пользователя может привести к уязвимости, и найти все "растяжки" вручную в большом проекте почти невозможно. Но есть "сапёр" — статический анализатор. Инструмент нашего "сапёра" — taint-анализ (aka анализ помеченных данных). Он позволяет обнаружить "грязные" данные, дошедшие до опасных мест без проверки. Сегодня мы расскажем о том, как он работает.