Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

Введение

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

С давнего времени меня занимает проблема ИИ. В начале это были попытки сделать продвинутого чат-бота. Затем пришло осознание, что это будет всего лишь программа, которая на запрос будет давать ответ в соответствии со своей базой данных (БД). Благодаря тому, что все знания системы будут заполнятся относительно случайно (в процессе разговора, обучения), мы получаем псевдонепредсказуемые ответы, но ведь сама система не осознает, что она отвечает. Следом была попытка разработать систему с более подвинутыми источниками познания, в надежде, что это даст какой-то толчок к появлению ИИ. Обработка изображения с камеры, звуков с микрофона, попытка создать бинокулярное зрение, чтобы опознавать образы объемных предметов… Все это было всего лишь очередным вводом данных в БД. Бесспорно, все это полезно и необходимо в робототехнике, но к самому интеллекту не приведет.

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

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

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

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

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

Не прошло и года, как я добрался до продолжения статьи про асинхронность. Эта статья развивает идеи той, самой первой статьи про асинхронность [1]. В ней обсуждается достаточно сложная задача, на примере которой будет раскрыта мощь и гибкость использования сопрограмм в различных нетривиальных сценариях. В заключение будут рассмотрены две задачи на состояние гонки (race-condition), а также небольшой, но очень приятный бонус.

Предисловие

Эта статья является продолжением цикла статей про асинхронность:

1. Асинхронность: назад в будущее.
   
2. Асинхронность 2: телепортация сквозь порталы.
   

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

1. Универсальный адаптер
   

Введение

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

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

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

Умножение методом русских крестьян

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

Общее описание метода просто, но не слишком информативно. Тем не менее, давайте начнём с него.

Математика — это «язык, который ни читать, ни понять невозможно без инициации» (Эдвард Ротштейн, «Эмблемы ума»)

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

Для математики существует особый протокол чтения. Как мы учимся читать литературу, так и математику мы должны научиться читать. Школьникам следует изучать протокол чтения для математики так же, как они учатся правилам чтения романа или стихотворения, учатся понимать музыку и живопись. Замечательная книга «Эмблемы ума» Эдварда Ротштейна выявляет взаимосвязь между математикой и музыкой, неявно затрагивая протоколы чтения для математики.

Никогда не сдавайтесь

Действительно ли Билл Гейтс произнёс фразу «640 КБ должно хватить всем»? Её история довольно туманна, однако чаще всего её приписывают Биллу, так что, возможно, он действительно такое говорил.

Его довольно часто за это высмеивали. Мысль о общем пространстве памяти размером всего 640 КБ по современным стандартам смехотворна. В этот размер не уместится даже исполняемые файлы большинства программ-установщиков.

Для сравнения: калькулятор в Windows 10 занимает в состоянии простоя 16,2 МБ оперативной памяти — почти в 26 раз больше, чем объём доступной DOS-программам памяти в 1980-х.

Странные дела

Поверите ли вы мне, если я скажу, что до сих пор существует активное сообщество, использующее эту устаревшую платформу и разрабатывающее для неё ПО?

Наверно, вашим первым вопросом будет «Но зачем?» И я хорошо вас понимаю. Давайте рассмотрим некоторые группы, которые до сих пор заинтересованы во вложениях усилий в DOS.

В этой статье я покажу, как написать рудиментарный, нативный x86-64 just-in-time компилятор (JIT) на CPython, используя только встроенные модули.

Код предназначен для UNIX-систем, таких как macOS и Linux, но его должно быть легко транслировать на другие системы, типа Windows. Весь код опубликован на github.com/cslarsen/minijit.

Цель — сгенерировать в рантайме новые версии нижеприведённого ассемблерного кода и выполнить их.

48 b8 ed ef be ad de  movabs $0xdeadbeefed, %rax
00 00 00
48 0f af c7           imul   %rdi,%rax
c3                    retq

В основном, мы будем иметь дело с левой частью кода — байтовой последовательностью 48 b8 ed ... и так далее. Эти 15 байтов в машинном коде составляют функцию x86-64, которая умножает свой аргумент на константу 0xdeadbeefed. На этапе JIT будут созданы функции с разными такими константами. Такая надуманная форма специализации должна продемонстрировать базовую механику JIT-компиляции.

Данная статья служит одной простой цели: помочь человеку, который вдруг решил разработать свою операционную систему (в частности, ядро) для архитектуры x86, выйти на тот этап, где он сможет просто добавлять свой функционал, не беспокоясь о сборке, запуске и прочих слабо относящихся к самой разработке деталей. В интернете и на хабре в частности уже есть материалы по данной теме, но довольно трудно написать хотя бы “Hello world”-ядро, не открывая десятков вкладок, что я и попытаюсь исправить. Примеры кода будут по большей части на языке C, но многие другие языки тоже можно адаптировать для OSDev. Давно желавшим и только что осознавшим желание разработать свою операционную систему с нуля — добро пожаловать под кат.