Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

По какой-то причине (за что, господи, за что?) моей областью стала разработка игр. Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.

Как бы то ни было, я именно это и сделал, и ненавижу себя за это. На удивление, вышло замечательно. Никто из нас не знает всего.

Проблема №1: ресурсы

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

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

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

Часть 2. Больше про сетевые протоколы и перемещение пакетов

Привет, Хабр! Представляю вашему вниманию перевод статьи Eli Bendersky, Understanding of lvalues and rvalues in C and C++.

От переводчика: предлагаю Вашему вниманию перевод интересной статьи об lvalue и rvalue в языках C/C++. Тема не нова, но знать об этих понятиях никогда не поздно. Статья рассчитана на новичков, либо на программистов переходящих с C (или других языков) на C++. Поэтому будьте готовы к подробному разжёвыванию. Если вам интересно, добро пожаловать под кат

В декабре прошлого года в Высшей школе бизнес-информатики НИУ ВШЭ проходил лекционный день по игровой индустрии. На мероприятии своим опытом с собравшимися гостями делились американский геймдизайнер компьютерных игр Richard «Levelord» Gray, директор продуктового департамента Rocket Jump Игорь Соловьев, игровой продюсер Сергей Гимельрейх, игровой маркетолог Сергей Зыков, основатели клуба игрофикаторов «Why42» Иван Нефедьев и Мирослава Бронникова. Под катом я собрал для вас видеозаписи и краткое описание всех докладов .

Это руководство поясняет работу простейшей программы, производящей вычисления на GPU. Вот ссылка на проект Юнити этой программы:

ссылка на файл проекта .unitypackage

Она рисует фрактал Мандельброта.

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

Шейдер, который рисует фрактал, написан на языке HLSL. Ниже приведён его текст. Я кратко прокомментировал значимые строки, а развёрнутые объяснения будут ниже.

Дамы и господа, здравствуйте.

Мы как раз закончили перевод интересной книги Яцека Галовица о STL С++ 17, которую надеемся выпустить чем раньше, тем лучше.


Сегодня же мы хотим предложить вашему вниманию перевод статьи Джулиана Темплмана с сайта «O'Reilly» с небольшим анонсом возможностей стандартной библиотеки нового стандарта С++.

Всех — с наступающим новым годом!

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

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

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

Но всегда можно посмотреть под другим углом.

Что, если попробовать выполнить двоичный поиск по графу? Большинство алгоритмов поиска по графам, такие как поиск в ширину или поиск в глубину, требуют линейного времени и были придуманы довольно умными людьми. Поэтому если двоичный поиск по графу будет иметь какой-то смысл, то он должен использовать больше информации, чем та, к которой имеют доступ обычные алгоритмы поиска.

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

На случай, если не хочется читать всю статью, вот:

howdoyou.do, lingoglobe, coffeestrap, wespeke, speaky, conversationexchange, easylanguageexchange, speaking24.com.

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

Алиасинг (aliasing) — это, возможно, наиболее фундаментальный и самый широко обсуждаемый артефакт 3D-рендеринга всех времён. Однако в игровом сообществе его часто недопонимают. В этой статье я подробно расскажу о теме сглаживания (антиалиасинга, anti-aliasing, AA) в реальном времени, особенно о том, что касается игр, и в то же время буду излагать всё достаточно простым языком.

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

Эту программу можно скачать здесь.

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

В этой статье я хочу обсудить шаблон проектирования «сущность-компонент-система» (Entity-Component-System, ECS). По этой теме можно найти много информации в Интернете, поэтому я не буду глубоко вдаваться в объяснения, а больше расскажу о моей собственной реализации.

Часть 1: Реализация шаблона Entity-Component-System на C++

Начнём сначала. Полный исходный код моей реализации ECS можно найти в репозитории на github.

Entity-Component-System, в основном используемый в играх — это шаблон проектирования, обеспечивающий огромную гибкость в проектировании общей архитектуры программного обеспечения^[1]. Такие большие компании, как Unity, Epic или Crytek используют этот шаблон в своих фреймворках, чтобы предоставить разработчикам очень богатый возможностями инструмент, с помощью которого они могут разрабатывать собственное ПО. Прочитать более широкое обсуждение по этой тематике можно в этих постах ^[2,3,4,5].

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

Вам также может быть интересна статья Десять возможностей C++11, которые должен использовать каждый C++ разработчик

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

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

Тогда как это удаётся играм?

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

Компьютерные игры являются отличным инструментом для изучения языков и обучения в целом, и вот почему:

• мотивация и минимальный риск (игра бросает определенный вызов, и его преодоление не расстраивает, а, наоборот побуждает пробовать еще);
• высокий уровень вовлеченности (гораздо интереснее играть и испытывать на себе что-то новое, чем просто идти по учебникам);
• динамичные компьютерные игры помогают лучше и быстрее учиться в целом (исследовали университета Rochester в США это достаточно давно доказали).

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

Для уровня Starter / Beginner

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

Gamestolearnenglish

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

В этой работе мы сосредоточимся не на скорости, а на чётком объяснении концепций. Код примеров написан наиболее понятным образом, который не обязательно является самым эффективным для реализации алгоритмов. Есть множество способов реализации, я выбрал тот, который проще всего понять.

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

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

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

Темой этой статьи как раз и будет реализация такого интегрирования.

Интегрирование уравнений движения

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

$$

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

$$

Ускорение — это темп изменения скорости от времени:

$$

Аналогично, скорость — это темп изменения позиции от времени:

$$

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

Оглавление

Часть 2: ядро движка

• Интегрирование
• Метки времени
• Модульная архитектура
  • Тела
  • Формы
  • Силы
  • Материалы
• Широкая фаза
  • Отсечение дубликатов контактных пар
  • Система слоёв
• Проверка пересечения полупространств

Часть 3: трение, сцена и таблица переходов

• Трение
• Сцена
• Таблица переходов коллизий

Часть 4: ориентированные твёрдые тела

• Математика вращения
• Ориентированные формы
• Распознавание коллизий
• Разрешение коллизий

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

У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.

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

Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.

Если вы программист, то, возможно, у вас возникали ситуации, когда в выбранном игровом движке или библиотеке нет нужной функции. За этим следовал ужасающий момент, когда вам приходилось обыскивать весь Интернет в поисках кода, написанного людьми, решавшими эту проблему до вас (я говорю о вас, пользователи StackOverflow). Конечно, в этом нет ничего плохого (я и сам так поступаю), но очень часто вы можете сделать это самостоятельно, даже когда речь идёт о таких теоретических задачах, как геометрия или перетасовка. Я один из тех людей, которые всегда пытаются понять, как всё работает, и разве есть способ понимания лучше, чем прийти к нему самому, заново изобретя решение на лету (если, конечно, оно существует)?

Ставим перед собой пример задачи

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