Две сотни частиц слишком мало? Хочется тысячи или десятки тысяч? Тогда пора заменить неадекватно медленный алгоритм поиска коллизий на что-то чуть более изящное.

Уже лет 50, со времён выхода первого издания «Языка программирования Си» Кернигана и Ритчи, известно, что «числа с плавающей запятой» одинарной точности имеют размер 32 бита, а числа двойной точности — 64 бита. Существуют ещё и 80-битные числа расширенной точности типа «long double». Эти типы данных покрывали почти все нужды обработки вещественных чисел. Но в последние несколько лет, с наступлением эпохи больших нейросетевых моделей, у разработчиков появилась потребность в типах данных, которые не «больше», а «меньше» существующих, потребность в том, чтобы как можно сильнее «сжать» типы данных, представляющие числа с плавающей запятой.

Я, честно говоря, был удивлён, когда узнал о существовании 4-битного формата для представления чисел с плавающей запятой. Да как такое вообще возможно? Лучший способ узнать об этом — самостоятельно поработать с такими числами. Сейчас мы исследуем самые популярные форматы чисел с плавающей запятой, создадим с использованием некоторых из них простую нейронную сеть и понаблюдаем за тем, как она работает.

Это первая статья из цикла о том, как создать свой собственный ООП язык программирования с использованием LLVM.

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

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

Заблуждение 1. Форма Земли — это просто

Заблуждение 1. В сутках 24 часа или 86 400 секунд

Заблуждение 1. Любые символы, кроме управляющих, имеют предсказуемую ширину

Мы продолжаем цикл статей про математику и смежные дисциплины в компьютерной графике по курсу Александра Паничева, ведущего разработчика логики в UNIGINE. В этот раз поговорим о функциях плавности, которые используются в анимации (и не только).

Мне всегда нравилась визуальная эстетика дизеринга (dithering, псевдотонирование, псевдосмешение цветов), но я не знал о том, как он применяется. Поэтому я провёл кое-какие изыскания. Эта статья может содержать отголоски ностальгии, но в ней не будет никаких следов Лены.

Привет, Хабр! Меня зовут Глеб. Я работаю в компании Friflex над проектами по оцифровке спорта. Работая над idChess (приложением для распознавания и аналитики шахматных партий), мы расширяем наш датасет синтетическими данными. В качестве движка используем Blender. В этой статье рассмотрим основы взаимодействия с объектами, получение доступа через API, перемещение, масштабирование и вращение.

В предыдущих статьях мы использовали прямое освещение (forward rendering или forward shading). Это простой подход, при котором мы рисуем объект с учётом всех источников света, потом рисуем следующий объект вместе с всем освещением на нём, и так для каждого объекта. Это достаточно просто понять и реализовать, но вместе с тем получается довольно медленно с точки зрения производительности: для каждого объекта придётся перебрать все источники света. Кроме того, прямое освещение работает неэффективно на сценах с большим количество перекрывающих друг друга объектов, так как большая часть вычислений пиксельного шейдера не пригодится и будет перезаписана значениями для более близких объектов.

Отложенное освещение или отложенный рендеринг (deferred shading или deferred rendering) обходит эту проблему и кардинально меняет то, как мы рисуем объекты. Это даёт новые возможности значительно оптимизировать сцены с большим количеством источников света, позволяя рисовать сотни и даже тысячи источников света с приемлемой скоростью. Ниже изображена сцена с 1847 точечными источниками света, нарисовання с помощью отложенного освещения (изображение предоставил Hannes Nevalainen). Что-то подобное было бы невозможно при прямом расчёте освещения:

До прихода в индустрию я искал материалы про QA в геймдеве, чтобы понять отличия от других областей. Результатов нашлось не много — обычно пишут про общие или абстрактные вещи, или о том, что это простой путь в геймдев, или рекламируют курсы. В итоге захотелось закрыть некоторые вопросы самому, так как на собеседованиях я вижу, что далеко не все представляют себе эту профессию на практике.

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

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

Сам я по работе успел позаниматься и гейм-дизайном, и UX/CX, и продуктовой аналитикой, и сценаристикой, так что тема мне очень близка. Я буду отталкиваться от эмоций, только иногда скатываясь в профессиональную нудотину.

Осторожно, трафик!

Привет, Хабр! Уже три года живу я в Японии (два провёл в языковой школе, а сейчас эникею в фирме с русским руководством на Хоккайдо) и, несмотря на то что глобально говоря ничего я ещё не добился, рассказы об Японии вызывают у людей живой интерес. Почему бы его не удовлетворить?

И так, начнём с самого животрепещущего вопроса: стоит ли стремиться к трудовой миграции в Японию?