Недавно пришлось собирать ffmpeg под Windows компилятором MSVC. И знаете — я чуть не помер. Официальная документация по сборке проекта под Windows безнадежно устарела. В Интернете есть даже статьи, которые так и заявляют: "Официальная документация по сборке ffmpeg под Windows безнадежно устарела — вот как теперь это делается". И смех в том, что эти статьи уже тоже устарели и не дают работающего решения "press X to compile".

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

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

Довольно типичный случай — у вас есть вполне себе нормальная структура, которая хранит информацию об одном объекте. Но самих объектов очень и очень много. Скажем, у вас 1000x1000 клеток террейна. А это уже целый миллион объектов! И вот ваша структура размером с несчастные 32 байта множится миллион раз и разрастается до объемов 30.5 Mб оперативной памяти.

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

Есть такой род статей на Хабре — читаешь ее и думаешь — вот как она была написана? Материал большой, длинный, много кода, и он в процессе повествования эволюционирует, улучшается. Автор показывает результаты выполнения, прогоны, бенчмарки. У статьи есть сюжет, драматургия, насколько это возможно для технической статьи — баги, тупики, отчаяние, метания и неожиданные озарения.

Я не раз вопрошал в восхищении: "вот как?..". Ведь если задуматься — чтобы автору выплеснуть на вас все палеонтологические слои своего кода, все версии от самых ранних и неуклюжих шагов к цели до матерого кода, обросшего абстракциями — как автор должен выстроить свою работу, чтобы в результате статья случилась такой, какой она есть?

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

Эта история заставила меня задуматься о том, какой тяжелой ценой и какими временными затратами в докомпьютерную эпоху ученым давались некоторые эксперименты. Этой статьей я хочу отдать дань уважения таким упорным мужам, как Керрич, и показать, насколько далеко мы продвинулись в прогрессе. И как это можно круто замесить с C++, оптимизацией, многопоточностью и щепоткой ненормального программирования.

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

Итак, в предыдущих сериях мы: познали боль и дисбаланс; написали логику карточной игры на питоне; внедрили в игру ботов и заставили их играть друг с другом тысячи и тысячи партий; описали метрики, которые мы собираем с игры; пообещали себе, что доведем дело до конца и получим оптимальные настройки карточной игры

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

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

На самом деле, HTML — самый важный язык вычислений, из когда-либо созданных. Недооценивайте его на свой страх и риск.

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

Продолжаем писать собственные плагины для Obsidian. Первую часть статьи можете найти здесь. В ней мы:

Выяснили, что можно писать плагины даже проще, чем это предлагает делать официальная документация

Написали три маленьких плагина, которые уже вовсю используются на продакшене лично мной

Грозились написать четвертый финальный босс-плагин

Вот и приступим.

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

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

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

В C++ уже больше 10 лет существует constexpr, который позволяет программисту ушло возложить часть вычислений на компилятор. В свое время это взорвало мне мозг, ведь компилятор может посчитать какие-то достаточно сложные вещи еще до запуска программы!

В какой-то момент я подумал: если компилятор сможет сам посчитать все за тебя, то зачем тогда тебе вообще рантайм? Что ты там будешь делать — ответ выводить что ли? Глупости какие-то. Это неспортивно.

На этом моменте и зародился мой челлендж:

"Без рук" или "даже не думай запускать exe-файл"

Код из КДПВ — кусок дерьма; кошмар, который вот-вот случится. Чтобы понять, почему и как это исправить, сначала нужно понять главный урок, который мне преподал Rust: силу использования системы типов для обеспечения инвариантов.

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

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

В данной статье мы будем воспроизводить звук в браузере на примере небольшого проекта под названием Punk riff generator.

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

Это перевод одной из глав книги Game programming patterns Роберта Найстрома. Так как книга по сути состоит из подробного описания шаблонов проектирования, каждая глава может рассматриваться как самостоятельная статья, чем я и воспользовался и перевел, как мне кажется, статью с самым важным паттерном в игростроении — Game loop.

В этой статье я хотел бы поговорить о том, почему вы могли бы предпочесть использование Arc<[T]> вместо Vec<T> в качестве варианта по умолчанию в вашем Rust-коде.

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

Это история про то, как не довести дело до конца, но получить уйму опыта, и вообще ни разу не обломаться.

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

Осторожно, очень много картинок!

Rust же создавали, чтобы держать программиста в ежовых рукавицах? Так почему бы не заставить git скооперироваться с Rust и не издеваться над программистом на пару?

На самом деле статья не сколько про Rust, сколько про git, поэтому если вы не особо знакомы с Rust, не смущайтесь сильно — повествование будет скорее про флоу разработки нежели чем про язык. Rust в статье выбран скорее за его удобный пакетный менеджер cargo, который сделает суть повествования лаконичнее и нагляднее.

C++ последний десяток с лишним лет стремительно развивается. Тем не менее в наших кодовых базах все еще присутствуют многочисленные helper-файлы и классы, которые помогают восполнить пробелы в стандартной библиотеке языка. Как же так вышло, что там в этих ваших helper-файлах, и когда это закончится?