При разработке аппаратных решений на базе микроконтроллеров производители хотят защитить свою прошивку от попадания в руки злоумышленников, так как в ней могут содержаться чувствительная информация, ключи шифрования, уникальные алгоритмы, представляющие ценность, и др. Для этого в большинстве микроконтроллеров реализованы технологии защиты от считывания (readout protection) встроенной флеш-памяти. Но так ли хорошо они защищают?

К сожалению, не все технологии Readout Protection работают так, как задумывалось. Для обхода защиты могут быть использованы уязвимости отладочных интерфейсов, нетривиальные атаки типа fault-injection и даже инвазивное вмешательство.

Мы в Positive Labs занимаемся исследованиями безопасности различного «железа». Поэтому, когда в наши руки попало устройство на базе микроконтроллера семейства GD32 компании GigaDevice, мы сами не заметили, как начали исследовать применяющиеся в этих микроконтроллерах технологии защиты. Данные микроконтроллеры довольно популярны и используются повсеместно, в том числе в качестве замены микроконтроллеров STM32, т.к. зачастую совместимы с ними по выводам и даже по карте адресного пространства. Исследование оказалось довольно увлекательным, а результаты — впечатляющими!

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

Но когда вы пишете игровой код на Unreal Engine, вы не имеете дело с игровым циклом напрямую. Вы не начинаете работать сразу с основной функцией — сначала вы определяете подкласс GameMode и переопределяете функцию под названием InitGame. Или пишете одноразовые классы Actor и Component и переопределяете их функции BeginPlay или Tick для добавления собственной логики. Это самый минимум того, что вам нужно сделать: обо всем остальном движок позаботится за вас.

Unreal Engine также предлагает вам как программисту мощный и гибкий инструментарий: конечно, он имеет открытый исходный код, но также возможно и расширение несколькими другими способами. Даже если вы только начинаете работать с этим движком, было бы не лишним получить представление о его GameFramework: о таких классах, как GameMode, GameState, PlayerController, Pawn и PlayerState.

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

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

Я одержим генерацией рельефа, играми на основе сеток, симуляциями и тому подобным. И часто во всём этом присутствует вода, или, по крайней мере, её присутствие кажется естественным.

Допустим, вы генерируете карту для стратегической игры, но не хотите, чтобы границы карты были заполнены непроходимой пустотой (как в олдскульных RTS). Разве не будет здорово, если граница будет заполнена водой, как на этой карте из одного моего заброшенного проекта?

Распараллелить сборку большого проекта на несколько компьютеров? Легко! Разбираемся, как использовать Unreal Horde — новый инструмент внутри Unreal Engine 5.5. В том числе посмотрим, как с его помощью запустить анализ PVS-Studio.

[Прим. пер.: на Хабре уже был перевод этой статьи, но незавершённый примерно на четверть.]

Неправда.

Калькулятор должен показывать результат введённого математического выражения. А это намно-о-ого сложнее, чем кажется.

В этом посте я расскажу величайшую историю о разработке приложения-калькулятора.

На изображении выше показан калькулятор из iOS.

Заметили что-нибудь?

Он посчитал неправильно.

(10¹⁰⁰) + 1 − (10¹⁰⁰) равно 1, а не 0.

Android считает правильно. А причина, по которой он это делает, абсолютно безумна.

Привет Хабр!

В этой статье я хочу раскрыть механику создания онлайн сессии и подключения к ней. Все выполнено в с использованием Online Subsystem для возможного расширения вашей игры в контексте Steam, Origin, Play Station Store и т.д

Привет Хабр!
В данной статье я бы хотел разобрать мультиплеер со стороны игрового процесса. Опорой для написания статьи выступает популярный Network Compendium.

Создание документации — самая скучная часть в разработке игр. Так думают многие разработчики, а некоторые из них уверены, что «документация устаревает раньше, чем она написана». Отчасти они правы. В современной разработке игр жестким многостраничным документам нет места. Но это вовсе не значит, что документация бесполезна. Геймдизайн документ (диздок, GDD) как стандарт документации для создания игр эволюционировал вместе с индустрией.

Часть 1

Итак, теперь у нас есть первая приблизительная оценка видимости листьев из порталов, хранящаяся в массиве mightsee каждого портала. Вычислять, что именно видно через последовательность порталов, сложно, поэтому мы вместо этих вычислений используем «консервативную» оценку. Она ни за что не скроет лист, который должен оставаться видимым.

«Это просто задача отсечения»

Свет внезапно выключается. Вы сидите в огромном конференц-зале. Кто-то включает проектор. На экране сам Майкл Абраш! Похоже, это знаменитый доклад Quake Postmortem с GDC 1997.

Он говорит о порталах.

Мы берём плоскости отсечения, ограничивающие максимальный объём видимого, и отсекаем их по всё более дальним порталам, пока они не пропадут.

Когда я работал над программой для маршрутизации трафика через DNS-запросы, мне нужно было проверять наличие доменов в заранее определенном списке. В языке Си нет стандартной библиотеки для работы с хеш-таблицами, поэтому обычно используются сторонние решения или создаются собственные. Я попробовал несколько готовых реализаций, но оказалось, что они недостаточно эффективны для моих нужд, так как требовали слишком много памяти. В итоге я разработал свою собственную хеш-таблицу.

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

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

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

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

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

- Чем чревато брать float или double в качестве типа данных для хранения позиций объектов?
- Как это может повлиять на наличие багов в игре и ошибки синхронизации сетевой игры или реплеев?

Об этом вы узнаете в этом гайде с наглядными гифками и пруфом на C++

Normal Mapping

Абсолютно все микроконтроллеры программируются одинаково, если собирать код из make файлов.

Настало время освоить очередное семейство ARM-совместимых микроконтроллеров. За плечами уже AVR, MSP430x, LPC21x, STM32x, MDR32x, ESP32x, SPC58x, CC26x2, NRF53x, AT32Fx. Теперь вот YTM32x от компании YUN TU (Suzhou YTM Semiconductor Co Ltd).

С какой же стороны следует подходить к микроконтроллерам YTM32x?
Давайте разбираться...

Сказал как-то один французский дипломат...

Что же он такого мог сказать в 16 веке ? Разберемся в этой статье.

Вашему вниманию предлагается полный список разделов электронной книги (12 из 11 :)), посвящённой неопределённому поведению. Книга не является учебным пособием и рассчитана на тех, кто уже хорошо знаком с программированием на C++. Это своего рода путеводитель C++ программиста по неопределённому поведению, причём по самым его тайным и экзотическим местам. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.

Единственный разумный подход к оптимизации игры — это всегда иметь под рукой хорошие метрики производительности. Unreal Engine поставляется сразу с несколькими полезными инструментами профилирования. «Stat commands» — один из таких инструментов. Они позволяют нам измерять ряд показателей для различных фрагментов нашего (C++) кода.

В этой небольшой статье я объясню, каким образом вы можете извлечь из этого пользу.

Структура публикации

• Получение кватерниона из вектора и величины угла разворота
• Обратный кватернион
• Умножение кватернионов
• Поворот вектора
• Рысканье, тангаж, крен
• Серия поворотов

Получение кватерниона из вектора и величины угла разворота