Всем привет! Меня зовут Гриша, и я основатель CGDevs. Продолжим говорить про математику что ли. Пожалуй, основное применение математики в геймдеве и компьютерной графики в целом – это VFX. Вот и поговорим про один такой эффект – дождь, а точнее про его основную часть, требующую математики – рябь на поверхности. Последовательно напишем шейдер для ряби на поверхности, и разберём его математику. Если интересно – добро пожаловать под кат. Гитхаб проект прилагается.

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

В этой статье я расскажу, как реализовать данный эффект на UE4. Существуют несколько способов, с помощью которых вы можете создать этот эффект. Один из этих методов был выбран мною.

Вычислять факт попадания в играх на основе полученной меткости можно по разному:

• сравнивая с одним псевдослучайным числом (которое тоже можно получать по разному [1]);
• сравнивая с наибольшим или наименьшим из двух псевдослучайных чисел;
• сравнивая среднее из двух и более случайных чисел (среднее тоже можно считать по разному).

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

Точно также по разному можно рассчитывать наносимый урон, особенно на основе дайсов (кубиков).

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

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

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

1. Мы должны иметь возможность рендерить любой шрифт любого размера в реальном времени, чтобы адаптироваться к системным шрифтам и их размерам, выбранным пользователями Windows.
2. Рендеринг шрифтов должен быть очень быстрым, никаких торможений при рендеринге шрифтов не допускается.
3. В нашем UI куча плавных анимаций, поэтому текст должен иметь возможность плавно перемещаться по экрану.
4. Он должен быть читаемым при малых размерах шрифтов.

Не будучи в то время большим специалистом в этом вопросе, я поискал информацию в Интернете и нашёл множество техник, используемых для рендеринга шрифтов. Также я пообщался с техническим директором Guerrilla Games Михилем ван дер Леу. Эта компания экспериментировала со множеством способов рендеринга шрифтов и их движок рендеринга был одним из лучших в мире. Михиль вкратце изложил мне свою идею новой техники рендеринга шрифтов. Хотя нам вполне было бы достаточно уже имевшихся техник, меня эта идея заинтриговала и я приступил к её реализации, не обращая внимания на открывшийся мне чудесный мир рендеринга шрифтов.

Pathfinder: Kingmaker (далее PF:K для удобства) — компьютерная ролевая игра, созданная студией Owlcat Games и вышедшая этой осенью в Steam и GoG. Проект, вдохновлённый классическими играми от Bioware и разделяющий с ними такие особенности, как использование правил популярной системы настольных игр, сражения в реальном времени с паузой, камера с изометрической проекцией, нелинейность прохождения и возможность получить несколько уникальных завершений.

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

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

Адаптировано из нашей будущей книги «Рефакторинг UI»

Видели эти модные генераторы цветовой палитры? Когда выбираешь цвет, настраиваешь несколько параметров с музыкальными словечками типа «триада» или «четвёртый мажор» — и получаете пять идеальных цветов для своего веб-сайта?



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

В серии статей от tyomitch «Компиляция» (тут, тут, тут, тут, тут и здесь) было рассмотрено построение транслятора игрушечного языка jsk, описанного в 4 части.
В качестве back-end для этого транслятора tyomitch предложил реализацию байт-кода и интерпретатор этого байт-кода.

На мой взгляд, более разумным подходом было бы использование существующих решений для backend, например llvm, и следуя принципу «Критика без конкретных предложений — критиканство», я предлагаю вариант реализации этого маленького языка jsk с llvm.

Что это даст для jsk? Настоящую компиляцию, то есть результатом будет исполняемый файл, который не зависит ни от каких runtime, возможность серьезной оптимизации, профилирования кода и автоматически получим документацию по back-end (что облегчит сопровождение).

От переводчика: ровно 175 лет и 3 дня назад были изобретены кватернионы. В честь этой круглой даты я решил подобрать материал, объясняющий эту концепцию понятным языком.

Концепция кватернионов была придумана ирландским математиком сэром Уильямом Роуэном Гамильтоном в понедельник 16 октября 1843 года в Дублине, Ирландия. Гамильтон со своей женой шёл в Ирландскую королевскую академию, и переходя через Королевский канал по мосту Брум Бридж, он сделал потрясающее открытие, которое сразу же нацарапал на камне моста.

$$

Памятная табличка на мосту Брум Бридж через Королевский канал в честь открытия фундаментальной формулы умножения кватернионов.

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

ДИСКЛЕЙМЕР

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

Здесь приводится опыт, который выдернул меня из состояния «читаю со словарем».



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

Возьмем такой предмет, как английский язык. Там куча понятий: 12 времен глагола, страдательный залог, причастия и т.п. Кто их ввел? Видимо, некие ученые мужи, для которых английский язык был РОДНЫМ. Они жили себе в каком-нибудь Oxford’e или в Cambridg’e и вряд ли знали русский язык.

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

Вспомните, как вы в школе изучали русский язык. Подлежащее, сказуемое, дополнение, определение… и штук 200 правил, из которых куча исключений, которые все благополучно забывают, кроме собственно учителей русского. И которые потом нужны – максимум – при разборках с бюрократическими документами («казнить нельзя помиловать»).

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

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

Статья ориентирована именно на таких.

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

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

Это звучит достаточно просто, и в каком-то смысле так и есть. Первый источник проблем заключается в том, что эта операция будет активно использовать кодеки — и да, она будет ограничена вычислениями, а не памятью и вводом-выводом. Поэтому нам нужна не просто рабочая, но и эффективная реализация. И по дороге мы столкнёмся со множеством других сложностей: взаимодействия с буферизацией ввода-вывода, обработка конца буфера, тупиковые ситуации в битовых сдвигах, определённых в C/C++ и в разных архитектурах процессоров, а также другие особенности битовых сдвигов.

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

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

Часть 1. Знакомство с Marching cubes

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

Вот пример из No Man’s Sky: видео.

Аналогичная техника применяется для отображения изображений с МРТ, metaball-ов и для вокселизации рельефа.

В этой части я расскажу о технике создания разрушаемого рельефа Marching Cubes, а в более общем применении — для создания плавного граничного меша твёрдого объекта. В этой статье мы начнём с рассмотрения двухмерной техники, затем трёхмерной, а в третьей части рассмотрим Dual Contouring. Dual Contouring — это более совершенная техника, создающая тот же эффект.

Доброго времени суток! Представляю вашему вниманию вольный перевод статьи от GDE (Google developer expert) Dmytro Danylyk. Собственно, вот оригинал. Статья описывает правильные подходы для работы со strings.xml и особенно полезно это будет разработчикам, которые разрабатывают мультиязыковые приложения. Прошу под кат.

Давайте поговорим о физике транспортных средств

Физика транспортных средств в видеоиграх не очень сильно обсуждается. Статьи в Интернете о физике транспорта в видеоиграх немногочисленны и поверхностны; обычно они посвящены самым основам. Программист транспорта для видеоигр ощущает себя сегодня в относительном вакууме. Возможно, такая ситуация возникла, потому что эту тему довольно сложно объяснить, а может быть, мы просто стыдимся признаваться в использовании хаков, упрощений и хитростей, которые мы вносим по сравнению с «правильной», реалистичной симуляцией физики. Как бы ни обстояло дело, видеоигры имеют уникальные проблемы в симуляции транспорта, а значит, об этом стоит писать. Это захватывающая тема, относящаяся к физике, работе с камерой, звуку, спецэффектам, а также к восприятию и психологии человека.

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

Давным-давно я имел радость играть в замечательнейшую RTS под названием «Периметр: Геометрия Воины» от отечественного разработчика K-D Labs. Это игра о том, как огромные летающие города под названием «Фреймы» бороздят просторы «Спанджа» — цепи соединенных между собой миров. Сюжет достаточно странный и абстрактный, но гораздо более интересной и инновационной составляющей игры была одна из ее технических особенностей, а не сюжет. В отличие от большинства RTS, где сражения происходят на статической местности, в «Периметре», одной из ключевых игровых механик был терраформинг. У игрока были средства манипулировать ландшафтом с целью возведения на нем своих сооружений а также целый арсенал боевых единиц, способных этот ландшафт превратить в потрескавшийся, поплывший и изрыгающий раскаленные камни/противных насекомых ужас.

Как известно, мир RTS нынче переживает некоторый упадок. Инди-разработчики слишком заняты тем, что клепают ретро-платформеры и rouge-like игры зубодробительной сложности, и поэтому, переиграв в «Периметр» некоторое время назад я решил, что должен и сам попробовать реализовать что-то подобное — идея была интересной и с технической и с геймплейной точек зрения. Обладая некоторым практическим опытом в разработке игр (ранее я совершал попытки сделать кое-что на XNA), я подумал, что чтобы добиться хоть какого-то успеха в одиночку мне придется воспользоваться чем нибудь более высокоуровневым и простым. Выбор мой пал на Unity 3D, чья пятая версия только-только вышла из под пресса.

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

TL;DR: кроссплатформенный клон WPF. От других попыток сделать нечто с XAML-ом выгодно отличается наличием полностью своей системы отрисовки со сменными бакэндами (сейчас поддерживается Direct2D и Cairo). В наличии инспектор, дизайнер (см. видео). Биндинги сделаны на стероидах под названием ReactiveExtensions (старый стиль тоже можно использовать). Умеет работать с Windows/Linux/MacOS, поддержку мобильных платформ планируется добавить в начале следующего года посредством отрисовки через MonoGame.

Я как-то писал о своём выборе роуминговых опций наших сотовых операторов. Тогда я остановился на «Ноль без границ» от МТС для входящих и на тарифе «Вокруг света» от Мегафона для исходящих и интернета. Но уже прошло три года, многое изменилось. Решил задокументировать нынешнее состояние дел.

Для начала — почему только Европа. Тут всё просто — я обычно езжу в отпуск в Европу. Не так часто, как некоторые ездят, но сильно чаще, чем сам езжу в другие части света.
Почему вообще возник такой вопрос, почему не купить местную симкарту в стране пребывания? Во-первых, туристу это не всегда возможно. Во-вторых, туристу это не всегда выгодно, особенно если приехал на пару дней. Но если я в стране на неделю и больше, то местную симкарту стараюсь приобрести.

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

Что за байда!

Китайский антивирус «Baidu» распространяется вирусными методами malware/adware, устанавливается вне зависимости от работы других антивирусов, в результате конфликт антивирусов порождает чрезмерное замедление работы ОС Windows.
Удаление ПО Baidu затруднено из-за того, что штатные программы удаления существуют только для двух компонент, драйверы уровня ядра ими не удаляются, более того, при следующей загрузке компьютера это ПО устанавливается повторно. В то же время удалить драйверы байды сложно из-за того, что они блокируют запись в «свои» ветки реестра и блокируют доступ к своим файлам.

Я написал простую инструкцию по полному удалению вредной Байды из Windows 7 и 8 без использования загрузочного носителя, она предназначена для использования техниками по обслуживанию компьютеров («эникейщиками») и подходит любому более-менее опытному пользователю.

Инструкция особенно актуальна для 64-битных версий Windows, поскольку в них не работает AVZ (точнее, нет 64-битного драйвера AVZ Guard).