Поиск контактных точек коллизии
Одна из важных тем при разработке своего физического движка - нахождение контактных точек. Применение этим данным масса - от определения центра удара, до построения градиента приложенных сил.
Давайте же посмотрим как это сделать!
Я исследовал некоторые open-source фреймворки — кандидаты на платформу для опорной сети пятого поколения операторского уровня, и хочу поделиться своими выводами. Под катом я сравню Seastar, mTCP, Boost.Asio, userver и ACE, расскажу, почему примитивы синхронизации — это плохо, а затем погружу вас в глубины Seastar.
Это ещё один маленький домашний DIY (апгрейд гирлянды) на, практически, самом младшем из младших микроконтроллеров из линейки ATtiny - на ATtiny10. Классический ЛУТ с ошибками любителя, и написание взрослой прошивки, для серьёзного мигания светодиодами. Все результаты доступны на гитхабе.
Привет, Хабр!
В данной статье сделан обзор на фреймворк планирования движения BMPF.
На данный момент подавляющее большинство средств планирования движения работает по одному и тому же принципу: вся сцена описывается как один робот, после чего выполняется планирование на сетке (чаще всего A*, подробнее можно прочитать здесь).
У такого подхода есть две основных проблемы:
1) планирование на сетке гарантирует допустимость только состояний в её узлах, промежуточные никак не оцениваются и не проверяются.
2) для сцены из нескольких роботов размерность пространства планирования получается слишком большой (алгоритмическая сложность планирования растёт как показательная функция).
Данный фреймворк решает обе озвученные проблемы. С документацией фреймворка можно ознакомиться здесь.
Поводом для размышления по этой теме послужил пост где поясняется на примерах два разных пути работы условного оператора if. Приводится генерируемый ассемблер где показано, что в одном случае после кода сравнения идет блок с кодом положительного решения, а в другом случае после сравнения идет отрицательная ветка. Я решил провести свои тесты в разных вариациях, чтобы проанализировать закономерность и как это можно использовать в оптимизации кода.
Привет, Хабр! Сегодня я хочу представить вам подборку интересных новостей и материалов из мира C++.
Это пилотный выпуск, так что любые советы, отзывы и рекомендации, как сделать наш дайджест лучше, в комментариях к статье или же напрямую мне в личные сообщения (habr, tg) приветствуются!
Приятного чтения!
Речь пойдет о библиотеках-аналогах numpy, pandas, scipy и sklearn на C++ (np, pd, scipy, sklearn соответственно).
Эти проекты изначально задумывались как хорошее дополнение к портфолио, однако затем наступило всё более и более плотное вовлечение в процесс работы над ними, челенджи становились всё более и более существенными, и проект превратился в несколько отдельных проектов, содержащих десятки тысяч строк кода...
Приветствую всех!
В этом посте представлен обзор написанной мной кроссплатформенной C++ библиотеки tubus реализующей транспортный протокол поверх UDP. Целевая аудитория C++ разработчики сетевых приложений.
Паттерн Шаблонный Метод (Template Method), описанный в книге по паттернам проектирования за авторством “банды четырех” (GoF), не связан с шаблонами (templates) C++ и является поведенческим шаблоном. Curiously Recurring Template Pattern (CRTP или “странно повторяющийся шаблон”) является усовершенствованием паттерна Шаблонный Метод и представляет собой идиому C++, в которой класс X наследуется от реализации шаблонного класса, используя сам X в качестве шаблонного аргумента. Название этой идиоме было дано Джимом Коплиеном (Jim Coplien), который наблюдал ее в самых первых образцах шаблонного кода C++. Эта методика позволяет достигнуть эффекта, аналогичного использованию виртуальных функций, без накладных расходов (и некоторой гибкости) динамического полиморфизма. CRTP можно использовать вместо Шаблонного Метода при условии, что вам не нужен динамический полиморфизм во время выполнения. Этот паттерн широко используется в библиотеках Windows ATL и WTL.
Мне давно хотелось узнать существуют ли программисты, которые понимают «делегирование» в рамках ООП так же, как я. А когда я случайно обнаружил что в Шаблонах проектирования (Design Patterns) в фундаментальных трудах признанных классиков концепций программирования пропущено описание для Делегирования, у меня появился повод написать эту статью.
Так получилось, что я сначала познакомился с этой техникой на практике разрабатывая DirectShow фильтры и COM-объекты, которые составляют эти фильтры и меня особо не интересовало как все это по-умному называется пока это все прекрасно работает. Проблемы возникают, когда ты пытаешься объяснить кому-то КАК это работает, или когда ты пытаешься предложить кому-то хотя бы попробовать использовать определенную технику программирования. Вот именно при таких попытках у меня получилось сопоставить что то, что я использую очень подходит под определение Design Pattern: Delegation.
Давайте посмотрим будет это поводом посмеяться или задуматься.
Должен предупредить что тем, кто воспринимает чужое мнение по техническим вопросам как оскорбление только потому, что он не согласен с этим мнением, не нужно читать эту статью.
Кто дочитает до конца найдет ответ на вопрос который задает название.
В этом году на C++ Russia я рассказывал про API дизайн. Эта статья — пересказ и переосмысление моего доклада.
То, что я здесь расскажу, основано на моем личном опыте — про API дизайн я думаю уже лет 15, с того момента как в 2008м начал читать ревью библиотек на входе в boost (кстати, всем рекомендую).
В первой части я сфокусируюсь на базовых вещах, которые применимы практически к любому императивному языку программирования, не только к C++. Будет также часть 2, более приближенная собственно к C++, в которой я расскажу о некоторых фичах языка и стандартной библиотеки, которые помогут вам сделать ваши API еще лучше.
Всем привет! Меня зовут Нурислам (aka tonitaga), и сегодня я бы вам хотел рассказать об Базовых алгоритмах на графах.
Мои эксперименты с нейронными сетями на Эльбрусе
В данной статье хочу поделиться своими наработками по теме нейронных сетей, запускаемых на Эльбрусе
Декодер изображений PNG из стандартной библиотеки языка программирования Wuffs работает в 1.22–2.75 раза быстрее, чем libpng (широко используемая реализация PNG декодера на C с открытым исходным кодом), C-библиотеки libspng, lodepng и stb_image, а также самые популярные библиотеки для работы с PNG на Go и Rust.
Статья рассказывает о том, как именно достигается такая производительность.
KPHP - компилятор для PHP. Он конвертирует PHP код в код на C++, компилируя который, ускоряет производительность в десятки раз. Это open-source проект, созданный ВКонтакте. Благодаря ему собирается огромный монолит ВКонтакте на 9 миллионов строк PHP кода в обычный бинарник, запуская который вы локально поднимаете полноценный ВКонтакте.
Наша задача - добавить в KPHP функции из PHP для работы с многобайтовыми строками. Добавляем фукнции мы в рантайм т.е. в С++ код, к которому имеет доступ код, транслированный из PHP.
Данная статья посвящена созданию и дальнейшим улучшениям джойстика (Joystick) на Arduino для управления ПК (имитации мыши).
В этой статье я хочу представить мой алгоритм оптимизации суммирования ряда чисел в массиве (на примере контейнера map).
Итак, дано задание
Есть некая электронная книга, которую одновременно читает неограниченное количество читателей. Нужно сделать так, чтобы любой читатель в любой момент мог проверить, сколько еще читателей читают ту же страницу, что и он. Предложена наивное решение хранить в map<int,int> в качестве ключа номера страниц, в качестве значения- количество прочитавших их пользователей. Конечно, при таком подходе программа медленно работает с большими тестами потому, что количество итераций по контейнеру map равняется числу прочитанных пользователем страниц. То есть, если пользователь прочел 1000 страниц из 1000 возможных, то в цикле нужно будет сделать 1000 итераций, и это сильно замедляет программу.
Чтобы уменьшить время работы программы, нужно упростить алгоритм подсчета пользователей. В этом алгоритме я отдельно считаю, сколько пользователей прочли столько же полных сотен страниц, как и искомый читатель, и затем уже постранично суммирую всех, кто прочел столько же страниц из той сотни, на которой сейчас находится читатель. Такой алгоритм позволяет вместо 999 итераций (если пользователь читает 999-ю страницу) сделать всего 108 (9 итераций сотням и 99 по единичным страницам).
Это вкратце, теперь перейдем к подробному описанию и для начала приведу код.
Я давний поклонник сити‑билдеров компании Impressions Games © и Саймона Бредбури, если кто не знает — его гений дал жизнь таким играм как Caesar 1/2/3, Space Colony и всей серии Stronghold, который по сей день трудится в студии Firefly Studios. Цезарь стал хитовым проектом и был продан более чем 400к копий на дисках за два года с 1998 по 2000. Но лучшей игрой серии считается Pharaoh + Cleopatra.
На Хабре есть две статьи, автор которых пишет виртуальную машину для исполнения простого байткода, а потом применяет различные оптимизации для ускорения этой виртуальной машины. Кроме того, есть и компилятор простого С‑подобного языка в этот самый байткод. Ознакмившись со статьями и этим компилятором, я подумал, что будет интересно изучить, как написать виртуальную машину этого языка, которая сможет делать JIT‑компиляцию байткода с помощью библиотеки libjit. Опыт этого я и описываю в настоящей статье. В интернете есть статьи, описывающие испльзование этой библитеки, но все, что я видел, описывают генерацию машинного кода с помощью libоit для конкретных программ, а не произвольного байткода: есть официальный tutorial, серия статей и ещё серия сравнений на Хабре.
Весь мой код приведён в моём репозитории.
Привет, Хабр!
В данной статье разобран алгоритм монотонной кубической интерполяции, предложенный Фритчем и Карлосоном в работе [1].
На рисунке красным обозначен результат обычной кубической интерполяции Эрмита, а синим - монотонной, кругами - опорные точки траектории.
Примеры кода написаны на C++, исходники всей библиотеки лежат здесь. Также написана копия библиотеки на Java, исходники лежат здесь.
