23 ноября 2011 года id Software поддержала собственную традицию и опубликовала исходный код своего предыдущего движка.

На сей раз настало время idTech4, который использовался в Prey, в Quake 4 и, разумеется, в Doom 3. Всего за несколько часов было создано больше 400 форков репозитория на GitHub, люди начали исследовать внутренние механизмы игры или портировать её на другие платформы. Я тоже решил поучаствовать и создал Intel-версию для Mac OS X, которую Джон Кармак любезно прорекламировал.

С точки зрения чистоты и комментариев это самый лучший релиз кода id Software со времени кодовой базы Doom iPhone (которая была выпущена позже, а потому откомментирована лучше). Крайне рекомендую каждому изучить этот движок, собрать его и поэкспериментировать.

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

Так как у меня была одна неделя до моего следующего контракта, я решил закончить мой цикл статей id. После Doom,Doom Iphone, Quake1, Quake2, Wolfenstein iPhone и Doom3, я решил изучить код, который я еще не рассматривал: idTech3 — 3D движок Quake III и Quake Live.

[Примечание переводчика: перевод первой части этой статьи уже есть на Хабре, но её автор почему-то не завершил работу.]

Рендерер Quake III

Рендерер Quake III стал эволюционным развитием рендерера Quake II с аппаратным ускорением: классическая часть построена на архитектуре «двоичного разбиения»/«потенциально видимых наборов», но добавлены два новых заметных ключевых аспекта:

• Система шейдеров, построенная поверх фиксированного конвейера OpenGL 1.X. Это было большим достижением для 1999 года. Она обеспечивала большое пространство для инноваций в эру до повсеместно распространённых сегодня вершинных, геометрических и фрагментных шейдеров.
  
• Поддержка многоядерной архитектуры: клиент-серверная модель OpenGL блокирует некоторые методы и система потоков частично решает эту проблему.

2 месяца назад я выложил на GitHub первую бета-сборку WebQuake — порта первого Quake, работающего в браузере через WebGL.

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

Я с удовольствием погрузился в изучение исходного кода Quake World и изложил в статье всё, что я понял. Надеюсь, это поможет желающим разобраться. Эта статья разделена на четыре части:

• Архитектура
• Сеть
• Прогнозирование
• Визуализация

ПШЕ AndroidStudio или как использовать VCS Tools по полной

- Все хорошо, только перед влитием обязательно засквошь коммиты.
- Заскво...Что?

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

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

Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал(и жалею).

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to use the JavaScript console: going beyond console.log()» автора Yash Agrawal.

Один из самых простых способов отладки чего-либо в JavaScript — вывод материала с помощью console.log. Но есть много других методов, предоставляемых консолью, которые могут помочь улучшить отладку.

Давайте начнем.

Самым базовым вариантом использования является вывод строки или группы объектов JavaScript. Довольно просто,

console.log('Is this working?'); 

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

const foo = { id: 1, verified: true, color: 'green};
const bar = { id: 2, verified: false, color: 'red' };

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



Как видите, имена переменных не видны, что не очень удобно. Это можно решить объединив все переменные в единый console.log ({foo, bar}). Это также уменьшает количество строк console.log в нашем коде.

Недавно мне выпала возможность пообщаться с довольно большим количеством начинающих специалистов по разработке на языке C#. Многие из них интересуются языком и платформой, и это очень круто. Среди зеленых юниоров распространено мракобесие по поводу очевидных (только что прочитавшему книгу про память) вещей. И это же натолкнуло меня на мысль о создании этой статьи. Статья в первую очередь нацелена на начинающих разработчиков, но думаю, что многие факты будут полезны и практикующим инженерам. Ну и самые очевидные и неинтересные заблуждения, разумеется, опущены. Здесь собраны наиболее интересные и значимые, особенно с точки зрения прохождения интервью.

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

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

Содержание

• О разделяемых ресурсах
• Возможные проблемы при работе в многопоточной среде
  • Deadlock
  • Race-Condition
  • Busy-Wait
  • Thread Starvation
• Средства синхронизации
  • Interlocked
  • Monitor.Enter, Monitor.Exit, lock
  • SpinLock, SpinWait
  • Monitor.Wait, Monitor.Pulse[All]
  • ReaderWriterLockSlim
  • Семейство ResetEvent
• Выводы

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.
Вторая часть доступна здесь

Необходимость делать что-то асинхронно, не дожидаясь результат здесь и сейчас, или разделять большую работу между несколькими выполняющими ее единицами была и до появления компьютеров. С их появлением такая необходимость стала очень ощутимой. Сейчас, в 2019, набирая эту статью на ноутбуке с 8 ядерным процессором Intel Core, на котором параллельно этому работает не одна сотня процессов, а потоков и того больше. Рядом, лежит уже немного потрепанный, купленный пару лет назад телефон, у него на борту 8 ядерный процессор. На тематических ресурсах полно статей и видео, где их авторы восхищаются флагманскими смартфонами этого года куда ставят 16ти-ядерные процессоры. MS Azure предоставляет менее чем за 20$/час виртуальную машину со 128 ядерным процессором и 2 TB RAM. К сожалению невозможно извлечь максимум и обуздать эту мощь не умея управлять взаимодействием потоков.

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

Зачем вообще уметь это? Транзисторы достигают своего минимального размера, закон Мура упирается в ограничение скорости света и поэтому рост наблюдается в количестве, транзисторов можно делать больше. При этом количество данных растет, а пользователи ожидают немедленной реакции систем. В такой ситуации "обычное" программирование, когда у нас один выполняющий поток, уже не эффективно. Нужно как-то решать проблему одновременного или конкурентного выполнения. Причем, проблема эта существует на разных уровнях: на уровне потоков, на уровне процессов, на уровне машин в сети (распределенные системы). В .NET есть качественные, проверенные временем, технологии для быстрого и эффективного решения таких задач.

TL;DR

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

Введение

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

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

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

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

Этот документ разделён на пять частей:

1. Как звук влияет на производительность
2. Разбираемся с параметрами импорта
3. Рекомендуемые мной параметры для PC и консолей
4. Рекомендуемые мной параметры для мобильных платформ
5. Предостережения и замечания

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

Специально для любителей книг из серии "С++ за 24 часа" решил написать статью про ASP.NET Core.

Если вы раньше не разрабатывали под .NET или под какую-то аналогичную платформу, то смысла заходить под кат для вас нет. А вот если вам интересно узнать что такое IoC, DI, DIP, Interseptors, Middleware, Filters (то есть все то, чем отличается Core от классического .NET), то вам определенно есть смысл нажать на "Читать дальше", так как заниматься разработкой без понимания всего этого явно не корректно.

Всем день добрый! Это статья о том, как профайлить Unity игры на Android с Android Studio. Я расскажу о том, как настроить Android Studio и получить максимальное кол-во данных. Вопросы анализа и выводов на основе полученного результата находятся вне рамок данной статьи.

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

Говорить о чистом коде можно бесконечно, но следующая статья Дэйва Николетта очень метафорична и, надеемся, действительно достойна перевода. Пусть и немного «назидательна», о чем автор заранее преуведомляет читателей в оригинале статьи.

Приятного чтения.

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

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

Визуально персонажи 3D-игр имитируются с помощью использования моделей, текстур и анимаций.

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

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

Возможность многократного применения анимаций позволяет использовать анимации из Asset store и с таких вебсайтов, как mixamo.com, для ваших собственных персонажей. Это экономит кучу времени!

В этом туториале вы узнаете, как подготовить гуманоидную модель в Blender и как перенести её в Unity. В частности, вы научитесь следующему:

• Создавать арматуру (скелет) персонажа и выполнять её риггинг (привязку скелета к мешу)
• Модифицировать персонаж добавлением аксессуаров и объектов
• Экспортировать модель в FBX
• Импортировать модели Blender
• Создавать и настраивать гуманоидный аватар
• Прикреплять к персонажу объекты
• Анимировать гуманоида в Unity