Введение

Приветствую всех, кто заглянул почитать мою очередную статью.

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

В первой части (линк: habr.com/post/435202) я описал этапы проектирования и написания языковой ВМ, которая будет выполнять наши будущие приложения на нашем будущем языке.
В этой статье я планирую описать основные этапы создания промежуточного языка программирования, который будет собираться в абстрактный байткод для уже непосредственного выполнения на нашей ВМ.

Думаю, что не помешает сразу привести ссылки на сайт проекта и его репозиторий.

Сайт
Репозиторий

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

На YouTube много бесплатных обучающих и курсов и туториалов.



Я веду freeCodeCamp, YouTube канал без рекламы. У нас есть полные видеокурсы и учебные пособия по многим популярным языкам программирования и фреймворкам (включая JavaScript, Python, Java, Ruby, C, C ++, Angular и не только).

Есть и другие YouTube каналы с бесплатными уроками по программированию, которые ничуть не хуже, а иногда даже лучше, чем платные.

В этой статье я перечисляю десять YouTube каналов, которые можно посмотреть, чтоб прокачаться в программировании. Расположение каналов — случайное.

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

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

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


Предлагаю вашему вниманию перевод статьи, которая детально объясняет причину этого феномена и способ борьбы с ним.

Введение

О чём этот текст

Если человек услышит о «симуляции реальности», то в наиболее вероятно ему в голову придут или разные научно-фантастические произведения (типа Матрицы, Темного города, или Теоремы Зеро), или компьютерные игры. В случае людей, чьи головы засорены инженерным образованием, возможно всплывут пакеты типа КОМПАС-3D AutoCAD, Solid Edge или NX. Человек, слушающий научпоп, возможно вспомнит о всяком моделировании разных космических штуковин.

А ведь есть ещё один уровень Реальности, который окажется незаслуженно забытым: тот, на котором происходит вся химия — это уровень атомов и молекул. Его тоже можно вполне успешно моделировать на компьютере. Поскольку в данном срезе Реальности всем заведует квантовая механика, то подобные расчёты часто называют квантовой химией. И вот о её связи с Реальностью, изучаемой экспериментальными методами, мы и поговорим.

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

Текст рассчитан на людей понимающих и/или интересующихся тем, как живут атомы и молекулки.


Взято из xkcd.com

TL;DR

Я создал демо, показывающее, как реализовать прогнозирование на стороне клиента физического движения игрока в Unity — GitHub.

Введение

В начале 2012 года я написал пост о как-бы-реализации прогнозирования на стороне клиента физического движения игрока в Unity. Благодаря Physics.Simulate() тот неуклюжий обходной способ, который я описал, больше не нужен. Старый пост до сих пор является одним из самых популярных в моём блоге, но для современного Unity эта информация уже неверна. Поэтому я выпускаю версию 2018 года.

Что-что на стороне клиента?

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

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

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

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

Осторожно: 19 картинок и 3 анимации под катом.

Размытие изображения посредством фильтра Gaussian Blur широко используется в самых разных задачах. Но иногда хочется чуть большего разнообразия, чем просто один фильтр на все случаи жизни, в котором регулировке поддаётся только один параметр — его размер. В этой статье мы рассмотрим несколько других реализаций размытия.

Сортировки слиянием работают по такому принципу:

1. Ищутся (как вариант — формируются) упорядоченные подмассивы.
2. Упорядоченные подмассивы соединяются в общий упорядоченный подмассив.

^{Ханойские башни}
Про знаменитую игру Эдуарда Люка́ на Хабре не писа́л только ленивый. Кажется, все покровы сорваны и что-то ещё по поводу алгоритма добавить уже невозможно. Но нет, у данной темы есть ещё скрытые ресурсы. Сегодня, в частности, мы переделаем алгоритм решения этой головоломки в полноценную сортировку. (Зачем? Just for fun. В пятницу можно.)

Часть 1. Введение

Привет меня зовут baldurk. Я уже несколько лет работаю программистом графики, поэтому хоть я и не в коем случае не являюсь экспертом, кажется, я уже многое понимаю во всём том, что касается работы с графикой.

Идея этой серии постов уже давно витала где-то на периферии моего сознания, и снова всплыла после прочтения интересной статьи с разбором последней Deus Ex.

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


Есть много составляющих, необходимых для создания даже простой 3D-игры, не говоря уж о таком проекте, как Watch Dogs.

У меня есть только общее представление о том, что нужно рассмотреть в этой статье, но это будет зависеть от того, какие темы вызовут интерес. Тем не менее, основная идея заключается в том, чтобы создать общее описание того, что происходит внутри современной игры, не отпугнув при этом никого из читателей — я буду предполагать, что у вас нет знаний математики и программирования. Если вы знаете разницу между ЦП и графической картой, и отличаете оперативную память от жёсткого диска, то этого будет вполне достаточно, а остальное я объясню.

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

Поэтому, да, ковер из всего 11 полигонов. Просто, но изящно. Под катом перевод небольшого гайда.

Одна из самых популярных статей на моём сайте посвящена генерации полигональных карт (перевод на Хабре). Создание таких карт требует много усилий. Но начинал я не с этого, а с гораздо более простой задачи, которую опишу здесь. Эта простая техника позволяет создавать подобные карты меньше чем в 50 строках кода:


Я не буду объяснять, как отрисовывать такие карты: это зависит от языка, графической библиотеки, платформы и т.д. Я просто объясню, как заполнить массив данными карты.

Шум

Стандартный способ генерации 2D-карт заключается в использовании в качестве строительного блока функции шума с ограниченной полосой частот, например шума Перлина или симплексного шума. Вот, как выглядит функция шума:


Мы присваиваем каждой точке карты число от 0.0 до 1.0. В этом изображении 0.0 — это чёрный цвет, а 1.0 — белый.

В этой части мы решим задачи об оптимальном размещении оружия на танке, пространственном расположении телепортов в MMORPG и сбалансируем бои четырёх классов персонажей RPG.

Задачи о размещении объектов

Электронные таблицы для этой части можно скачать здесь: (SuperTank) (телепорты, часть 1) (телепорты, часть 2)

SuperTank: задача решена!

В первой статье серии мы рассказали о примере задачи для игры под названием SuperTank. Во второй её части, мы познакомились с основными концепциями моделирования решений и я рассказал о решении простого примера с помощью инструмента «Поиск решений» в Excel.

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

Введение

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

Однако такой подход неудобен при работе с OSG. По этой причине машина состояний OpenGL инкапсулируется классом osg::StateSet, который берет на себя операции по работе со стеком состояний и их установке в процессе обхода графа сцены.

Привет, Хабр!

В сети довольно много статей про работу микроконтроллеров STM32 в энергоэффективных устройствах — как правило, это устройства на батарейном питании — однако среди них прискорбно мало разбирающих эту тему за пределами перечисления энергосберегающих режимов и команд SPL/HAL, их включающих (впрочем, та же претензия относится к подавляющему большинству статей про работу с STM32).

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

Восполнять данный пробел мы будем на примере STM32L1 — контроллера весьма популярного, достаточно экономичного и при этом имеющего некоторые специфические именно для этой серии проблемы. Практически всё сказанное будет также относиться к STM32L0 и STM32L4, ну и в части общих проблем и подходов — к другим контроллерам на ядрах Cortex-M.



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

• Ликбез по теории вероятностей (статья вводная, необязательная)
  
• Введение в системы линейных уравнений
  
• Методы конечных элементов
  
• Минимизация квадратичных форм и примеры задач МНК
  
• От наименьших квадратов к нейронным сетям
  

Итак, очередная статья из цикла «математика на пальцах». Сегодня мы продолжим разговор о методах наименьших квадратов, но на сей раз с точки зрения программиста. Это очередная статья в серии, но она стоит особняком, так как вообще не требует никаких знаний математики. Статья задумывалась как введение в теорию, поэтому из базовых навыков она требует умения включить компьютер и написать пять строк кода. Разумеется, на этой статье я не остановлюсь, и в ближайшее же время опубликую продолжение. Если сумею найти достаточно времени, то напишу книгу из этого материала. Целевая публика — программисты, так что хабр подходящее место для обкатки. Я в целом не люблю писать формулы, и я очень люблю учиться на примерах, мне кажется, что это очень важно — не просто смотреть на закорючки на школьной доске, но всё пробовать на зуб.

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



В данном конкретном случае я решаю эллиптическое дифференциальное уравнение, носящее имя Симеона Деми Пуассона. Товарищи программисты, давайте сыграем в игру: прикиньте, сколько строк в C++ коде, его решающем? Сторонние библиотеки вызывать нельзя, у нас в распоряжении только голый компилятор. Ответ под катом.

Дистанция атаки противников

Спасибо читателям за проявленный интерес, рад что материалы полезны.

Представляю вам четвертую статью цикла.

Сегодня я хотел бы разобрать такой важный элемент для любого монстра — дистанция атаки.

Их существует всего три:

• ближняя
• средняя
• дальняя

В первой части разберем типичные примеры поведения (паттерны).

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

Статьи становятся более сложными и основываются на предыдущих материалах.

Вы можете ознакомится с ними по ссылкам ниже:
«Монстры в играх или как создать страх»
«Монстры в играх или делаем страх разнообразным»
«Монстры в играх или как удивить игрока»

Поехали

Для записи трёхмерных поворотов программисты графики используют кватернионы. Однако в кватернионах сложно разобраться, потому что изучают их поверхностно. Мы просто принимаем на веру странные таблицы умножения и другие загадочные определения, и используем их как «чёрные ящики», поворачивающие векторы так, как нам нужно. Почему $$ и $$? Почему мы берём вектор и превращаем его в «мнимый» вектор, чтобы преобразовать его, например $$? Да кому это интересно, если всё работает, правда?

Существует способ описания поворотов под названием ротор, который относится к области и комплексных чисел (в 2D), и кватернионов (в 3D), и даже обобщается до любого количества измерений.

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

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

Было бы здорово, если бы начали вытеснять использование и изучение кватернионов, заменяя их роторами. Заменить их очень просто, а код останется почти таким же. Всё, что можно делать с кватернионами, например, интерполяцию и устранение блокировки осей (Gimbal lock), можно сделать и с роторами. Но понимать мы начинаем гораздо больше.