Это сборник информации, которая мне понадобилась, чтобы реализовать этап установления соединения между участниками сетевой игры типа «равный к равному» (peer-to-peer) с использованием протокола UDP.

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

Опытные геймдевелоперы вряд ли найдут тут для себя что-то новое. Но буду благодарен за замечания и комментарии.

В сегодняшнем материале мы собрали одни из наиболее популярных книг, отобранных самими разработчиками — резидентами Reddit, Quora, Stack Exchange, Stack Overflow и Hacker News.

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

Данная статья является седьмой частью серии статей, предназначенных, по словам автора, для тех, кто не может разобраться с внедрением зависимостей и фреймворком Dagger 2, либо только собирается это сделать. Оригинал написан 30 декабря 2017 года. Перевод вольный.

Смешивание цветов

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

Привет, Хабр! ASP.NET Core поддерживает открытый веб-интерфейс для .NET (OWIN), а OWIN позволяет отвязывать веб-приложения от веб-серверов. Он определяет стандартный способ использования связующего ПО при обработке запросов и соответствующих ответов. Приложения ASP.NET Core и связующее ПО совместимы с приложениями, серверами и связующим ПО на базе OWIN. Подробнее об этой паре читайте под катом.

Черная пятница, черная пятница… надоело. Объявляю свой личный Белый понедельник — за пару ночей написал небольшую игру и выкладываю ее код на всеобщее пользование, со скидкой 90%. Зачем мне это надо? Ну я вижу следующие плюсы — тот самый открытый код для поиска работы (да да, сейчас я нахожусь в активном поиске), почитать в комментариях о своих косяках, наконец то сменить статус на Хабре.

Казалось бы, простой вопрос: может ли среда CLR вызвать финализатор объекта, когда экземплярный метод не завершил свое исполнение?

Другими словами, возможно ли в следующем случае увидеть «Finalizing instance.» до «Finished doing something.»?

internal class GcIsWeird
{
    ~GcIsWeird()
    {
        Console.WriteLine("Finalizing instance.");
    }

    public int data = 42;

    public void DoSomething()
    {
        Console.WriteLine("Doing something. The answer is ... " + data);
        // Some other code...
        Console.WriteLine("Finished doing something.");
    }
}

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

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

Некоторые из них для наглядности будут показаны на примере языков программирования PHP или JavaScript, но в целом они работают независимо от ЯП.

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

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

Поехали!

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

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

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

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

Самым графически впечатляющим проектом нашего хакатона был Skyeng Action. Когда автор накануне мероприятия презентовал свою идею, мало кто верил, что она будет доведена до рабочего состояния за двое суток. Тем не менее, команда из трех не знакомых до того ни друг с другом, ни с Unity разработчиков с задачей успешно справилась. Рассказываем, как это было.

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

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

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

Всем привет! Давно уже хотел написать статью о UniRx на Unity3d. Начнем с небольшой философии RX программирования. Например, разрабатывая игру, мы создаем кнопку, наблюдаем событие клика этой кнопки и реагируем на это каким нибудь кодом.

Реактивное программирование — это всё то же самое, только на стероидах, то есть мы можем создавать потоки данных всего. И также наблюдать за ними и реагировать. Update, OnCollisionEnter, Coroutine, Event, Mouse input, Keyboard input, Joystick input — все это потоки.
Все что нас окружает это потоки.

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

В этот раз мне понадобилось понять, как создаются пользовательские объекты в NanoCAD с помощью MultiCAD.NET API. В блоге компании Нанософт есть статья от 2013 года, в которой объясняются базовые вопросы создания пользовательских примитивов. Но согласитесь было бы не интересно, просто воспроизвести эту статью, поэтому мы ее немного дополним.

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

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

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

Так или иначе если вы интересуетесь: проектированием, САПР, NanoCAD, разработкой под .NET и в частности на C#, а также овцами и Улицей Сезам, то возможно эта статья как раз для вас.

Вам тоже интересно причем тут овцы и Улица Сезам? Тогда милости прошу под кат.

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

Продолжая сравнение топовых 3D-движков — Unreal Engine 4 и Unity, на этот раз мы рассмотрим их достоинства и недостатки при разработке 2D-проектов. Мы выясним, чем хорош Unreal для 2D, как организована работа с основными элементами двухмерной игры и какими средствами можно реализовать 2D-персонажей со скелетной анимацией.

Вступление

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

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

С этой статьей я начинаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Тема IDisposable была выбрана в качестве разгона, пробы пера. Вся книга будет доступна на GitHub: DotNetBook. Так что Issues и Pull Requests приветствуются :)

Disposing (Disposable Design Principle)

Сейчас, наверное, практически любой программист, который разрабатывает на платформе .NET, скажет, что ничего проще этого паттерна нет. Что это известный из известнейших шаблонов, которые применяются на платформе. Однако даже в самой простой и известнейшей проблемной области всегда найдется второе дно, а за ним еще ряд скрытых кармашков, в которые вы никогда не заглядывали. Однако, как для тех, кто смотрит тему впервые, так и для всех прочих (просто для того, чтобы каждый из вас вспомнил основы (не пропускайте эти абзацы (я слежу!))) — опишем все от самого начала и до самого конца.

IDisposable

Если спросить, что такое IDisposable, вы наверняка ответите что это

public interface IDisposable 
{
	void Dispose();
} 

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

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

Оглавление

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

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

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

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

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

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

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

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

В этой части туториала мы рассмотрим следующие темы:

• Простое распознавание коллизий
• Генерирование простого многообразия
• Разрешение импульсов силы

Дóжили. Недавно была обнаружена проблема синхронизации игрового процесса с реальным временем не где-нибудь, а в игре "Quake Champions". Название игры "Quake" раньше было синонимом чего-то крутого, высокотехнологичного и идеального. И в голову не могло придти, что через какую-то пару десятков лет и камня на камне не останется от былого превосходства, а в новой игре с именем "Quake" появятся грубые ошибки, приводящие к тому, что один из игроков может получить преимущество только потому, что у него лучше "железо". Дело в том, что скорость стрельбы в новом шутере зависит от fps, то есть, количество пуль, выпущенных игроками с разным значением fps за один и тот же промежуток времени будет разным, а значит один из них может получить преимущество.

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