Сегодня я выхожу в эфир со статьей, которая является неким потоком сознания. Сегодня не будет практической пользы, только мои размышления о Work Life Balance. Те, кто ждёт руководство или призыв к действию, проходите мимо! А те, кто остались, добро пожаловать на борт моего корабля. Мы отправляемся в круиз по волнам Work Life Balance, через рифы ночного кодинга прямиком на остров усталости!

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

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

Так делает imgui, равно как и все, кто использует stb_truetype. Сам процесс приятно напоминает процесс наборного производства на физических станках.

Причудливо, правильно, но в то же время напряжно.

Если нам нужно просто вывести какое‑то сообщение для дебага? Нет ли какого‑либо более простого метода?

В данной статье я опишу метод бестекстурной отрисовки дебаг‑текста. Вдобавок, отрисовка будет производиться в один вызов draw.

Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

Библиотека форматирования {fmt} известна своим небольшим влиянием на размер бинарников. Чаще всего её код в несколько раз меньше по сравнению с такими библиотеками, как IOStreams, Boost Format или, что иронично, tinyformat.

Давайте разберем, как можно уменьшить размер бинарников еще больше!

Введение

Мы покажем, что система, имеющая лишь команды GNU find и mkdir, полна по Тьюрингу.

Хорошо известно, что команды sed и awk сами по себе полны по Тьюрингу, но мне не удалось найти информации о Тьюринг-полноте find + mkdir.

Доказательство основано на реализации таг-системы.

Мы по порядку рассмотрим реализацию цикла, FizzBuzz и таг-системы.

Любой фанат Fallout в начале нулевых был бы без ума от счастья, услышав, что под крылом компании, подарившей ему любимое RPG-приключение на постапокалиптической пустоши, разрабатывается новая ролевая игра! Вы только взгляните на это глазами поклонника Fallout тех лет: проект с той же механикой, но события разворачиваются в средневековье на стыке фэнтези и исторической реальности! Но дело в том, что непосредственного участия Black Isle Studios в разработке новой игры, которую назвали Lionheart: Legacy of the Crusader, не принимала, ограничиваясь лишь консультированием. Создание проекта было доверено студии Reflexive Entertainment, которая может быть известна олдфагам по культовой (в своё время) игре Crimsonland. Однако одно дело – небольшая, как бы сейчас сказали, инди-игра, и совсем другое – масштабный и продуманный ролевой проект, который для молодой американской студии был вызовом. Все это осложнялось тяжелой финансовой ситуацией как в самой компании, так и у издателя Interplay Entertainment, который, услышав обещание сделать качественно и за малые деньги, согласился доверить столь крупный проект людям почти без опыта. Но даже при таком подходе денег у Interplay не хватало, что не могло не сказаться на итоговом продукте.

Итоговый проект, безусловно, не дотягивает до высот Fallout или Planescape: Torment, но всё же по-своему хорош и до сих пор любим многими. Так как же играется Lionheart в 2024 году, и стоит ли она потраченного времени? Об этом я постараюсь поведать в сегодняшнем обзоре.

Всем привет. Меня зовут Антон, я фронтендер в Сбере. Если вы ещё не осваивали технологию PWA, но хотели бы — или вдруг срочно понадобилось, — то я вам помогу и объясню, что это и как начать с ней работать. 

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

Задавались ли вы когда-нибудь вопросом, можно ли полноценно программировать при помощи директивы #define в языке C? Полнота по Тьюрингу шаблонов C++ известна весьма широко, например, люди пишут трассировщики лучей, делающие все вычисления во время компиляции (вместо времени исполнения). А как обстоят дела с препроцессором C? Вопрос оказался сильно нетривиальнее, и эта история является, на мой вкус, отличным анекдотом для курса лекций по теории компиляторов, что я готовлю в данный момент. В частности, для лучшего понимания происходящего здесь, рекомендую ознакомиться со второй статьёй, которую я опубликовал параллельно этой: лексер и парсер.

Чтобы не было обманутых впечатлений, предупрежу сразу, что рейтрейсера не будет, но про́клятый код будет очень даже! Итак, поехали. Для начала, почему я вообще задался этим вопросом? Если обычный код компьютерной графики вам скучен, следующий раздел можно пропустить, перематывайте до последней картинки.

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных.

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

Полосы прокрутки. Слышали когда-нибудь о них? Довольно крутая штука. Достаточно зажать и перетаскивать полосу прокрутки, чтобы перемещаться по контенту панели со скроллингом. Я это просто обожаю. Ежедневно целыми днями сижу за компьютером и тягаю полосу прокрутки. Но полосы прокрутки становятся мельче, и это оказывается всё более серьёзной проблемой. В статье я покажу скриншоты, но они настолько малы, что даже делать их было сложно. А разработчики продолжают делать их всё мельче, как будто не хотят, чтобы вы скроллили! Они говорят: «для этого ведь колесо прокрутки и существует». Друг мой, не у каждого есть колесо прокрутки и не каждый может свайпать по сенсорному экрану. И даже я, счастливый обладатель колеса прокрутки, хотел бы перемещаться по контенту быстро.

Ещё один способ играть в старые игры на современном железе. Шок от первого использования PCeM v17. И то, как он вернул радостные ощущения от игры с настоящим «Voodoo» без NGlide Wrapper.

Как и всегда, полно дилетантства, непрофессионализма и прочей ереси.