Как «ужать» мегаполис до размеров iPhone 4

Помните времена, когда трава была зеленее, мобильный интернет помегабайтным, а Apple осваивала непаханые поля смартфоно-игровых ферм? Начало 2010-х было очень интересным временем, когда мобильные студии создавали целые новые жанры, пытались перенести или адаптировать старые концепции и игры, попутно решая задачи, от которой у десктопного разработчика начинал дергаться глаз. Вот и EA решили взять культовые франшизы SimCity и The Sims со всеми их терабайтами ассетов, сложнейшей симуляцией дорог, пробок и отдельных симов, и попробовать затолкнуть это в карман. В кармане у пользователя тогда лежал условный iPhone 4 или 5 с уже тогда куцым бюджетом оперативной памяти в районе 100–300 МБ на всё про всё, но айфоновладельцы были "платящей" аудиторией, поэтому игровое подразделение метило в основном в них. Как не превратить смартфон в обогреватель и словить ООМ в первые минуты игры? Выкинуть честную симуляцию на помойку, превратить симов в конечные автоматы, а город сделать хитрой иллюзией из текстурных атласов и таймеров . Раскажу немного как устроены SimCity BuildIt и The Sims Mobile с инженерной изнанки, кода почти не будет, да он и не нужен тут для понимания, а еще будет немного грустинки по российскому подразделению EA, и фотки с закрытия офиса в 2016.

https://habr.com/ru/articles/1051440/

#с++ #игры_и_консоли #разработка_игр #программирование

Создаем потокобезопасную очередь с условными переменными: «академический» пример против реальности

Представьте, что вы едете в ночном поезде. Чтобы гарантированно выйти на нужной станции, придется не спать всю ночь и внимательно отслеживать остановки. Свою станцию вы не пропустите, но сойдете с поезда уставшим. Другой способ: узнать из расписания предполагаемое время прибытия поезда, поставить будильник на нужное время с небольшим запасом и лечь спать. Этого вполне достаточно, чтобы не пропустить свою станцию, но, если поезд задержится, пробуждение окажется слишком ранним. Идеальным решением было бы лечь спать, положившись на то, что кто-нибудь или что-нибудь разбудит вас незадолго до реального прибытия поезда на нужную станцию... Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков.

https://habr.com/ru/companies/yadro/articles/1051850/

#с++ #очереди #мьютексы #consumer #задача #многопоточность #producer

НЕкурс про создание собственного языка программирования: вдохновляемся неожиданными открытиями, чтобы сделать свои

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

https://habr.com/ru/companies/pvs-studio/articles/1050964/

#с++ #парсер #язык_программирования #курсывебинары #экспертиза #интерпретатор #интерпретаторы

Путеводитель по чужим STL

Надеюсь вам понравилась статья про работу с памятью на консолях , где каждый ездил на том велосипеде, который сам же и придумал, попробую рассказать про зоопарк теперь уже стандартных библиотек. Стандартных в отдельной студии или конторе, потому что у соседней будет свой стандартный стандарт. Забавно что любовь прикрутить очередную погремушку к своему велосипеду становится тем сильнее, чем становится крупнее контора, поэтому приходя в игровую студию есть очень немаленький шанс, что стандартный STL у неё нестандартный, обёрнут или вовсе запрещён религией кодстайлом. EA, Facebook, Google, Adobe, LLVM и рядок компаний поменьше тратят человеко-десятилетия в поисках ответа на главый вопрос жизни, Вселенной и всего такого «почему std:: это медленно, непредсказуемо и жрёт память». По аналогии с прошлой статьей вам не потребуется знать стандарт наизусть, а будет достаточно понимать, что такое указатель, чем вектор отличается от дерева и почему промах в кеше это дорого, а дальше я пройдусь по разным стандартным библиотекам и про каждую немного расскажу, что это, зачем оно появилось и где об него можно больно удариться, потому что про вот этот последний пункт обычно забывают "продаваны" и прочие студийные еванглелисты, когда расказывают какое там всё красивое, легкое и с++двадцатое.

https://habr.com/ru/articles/1042198/

#с++ #с++_программирование #ненормальное_программирование #игры_и_консоли

Мы вас видим

Есть такая забавная категория людей в разработке, давайте назовём их IT-волки. Это те самые ребята, у которых в 26 лет уже 12 лет опыта, в 27 два проекта и архитектура уровня «я тут всё с нуля поднял», а в 28 управление двумя командами под миллион MAU. Иногда смотришь такое CV и думаешь - ну всё, сейчас придёт человек, который видел боль, огонь и сломаный прод, а потом начинается интервью. И очень быстро становится понятно, что дело вообще не в синтаксисе или знаниях фреймворков, иногда это могут быть идеальные знания, что тоже пугает. Знания конкретных фреймворков, это вообще не проблема и можно забыть название паттерна, потому что этих самых паттернов овердофига и можно перепутать детали. Это нормально, у всех бывает, интереснее другое. Когда начинаешь спрашивать про реальные решения, про ошибки, про “что вы делали”, про “почему вы это сделали именно так”... вот тут часто начинается тишина.

https://habr.com/ru/articles/1050320/

#с++ #разработка_игры #управление_персоналом #управление_проектами

Динамический полиморфизм против std::variant на указателях: Разрушаем мифы о скорости std::visit

В экосистеме современного C++ прочно укоренилось мнение: классический динамический полиморфизм через виртуальные функции ( vtable ) — это устаревший, медленный и недружелюбный к кэшу процессора механизм. В качестве «серебряной пули» модно предлагать связку std::variant и std::visit . По интернету кочуют статьи, утверждающие, что std::visit выполняет диспетчеризацию за фиксированное время O(1) и полностью уничтожает старый добрый ООП-подход. Но в таких сравнениях авторы часто совершают методологическую ошибку: они противопоставляют вектор указателей std::vector<Base*> вектору сырых объектов std::vector<std::variant> . Разумеется, std::variant побеждает, но не из-за механики вызова, а благодаря стопроцентной локальности данных в кэше процессора. Давайте снимем розовые очки, уравняем условия и изолируем саму механику вызовов. Представьте реальный сценарий: объекты тяжелые, создаются динамически в разное время и разбросаны по куче (Heap), а мы оперируем массивами их адресов. Мы столкнем лоб в лоб std::vector<Base*> и std::vector<std::variant<TypeA, TypeB, TypeC>*> в условиях раздельной компиляции (когда оптимизатор -O2 не видит тела функций и не может применить тотальный инлайнинг).

https://habr.com/ru/articles/1045494/

#динамический_полиморфизм #с++ #cplusplus #visit #variant

C++101

Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации. Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr , ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые кострукции, которые в более поздниях стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх. Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами. Когда я собирал оглавление Game++ , раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе. Перед вами то, что могло бы стать половиной Game++ , но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе. Вероятно вам потребуется вспомнить некоторые правила вывода шаблонов, и что такое конструктор и деструктор, чем стек отличается от кучи, что у объекта есть время жизни, но это не точно. Я также намеренно убрал обработку краевых случаев и разные проверки из кода, которые в реальном коде заняли бы половину всего текста и утопили бы саму мысль в деталях. Паттерн механизма в моем случае важнее конкретной реализации, и почти каждая из них существует в десятке вариаций под разные компиляторы и стандарты.

https://habr.com/ru/articles/1044450/

#с++ #с++_программирование #игры_и_консоли #разработка_игр

C++101

Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации. Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr , ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые кострукции, которые в более поздниях стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх. Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами. Когда я собирал оглавление Game++ , раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе. Перед вами то, что могло бы стать половиной Game++ , но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе. Вероятно вам потребуется вспомнить некоторые правила вывода шаблонов, и что такое конструктор и деструктор, чем стек отличается от кучи, что у объекта есть время жизни, но это не точно. Я также намеренно убрал обработку краевых случаев и разные проверки из кода, которые в реальном коде заняли бы половину всего текста и утопили бы саму мысль в деталях. Паттерн механизма в моем случае важнее конкретной реализации, и почти каждая из них существует в десятке вариаций под разные компиляторы и стандарты.

https://habr.com/ru/articles/1044450/

#с++ #с++_программирование #игры_и_консоли #разработка_игр

Почему игровой GUI пишут заново (Ч.1)

Если показать любому игровому программисту лекции про пользовательский интерфейс года эдак 2006, а потом показать ему что он наклодовал в современной игре, то он узнает в них почти всё, но с небольшими оговорками. Поменялись названия API и язык кодогенерации, но архитектура и основные идеи остались те же: дерево контролов, свойства с рефлексией, связи между свойствами, шаблоны, абстракция над движком и вечная война за пиксель-в-пиксель. Пользовательский интерфейс в играх это место, где встречаются все худшие архитектурные требования сразу, на них накладываются требования дизайнера UI, который сидит через стол и просит, чтобы окно появлялось «вот так с анимацией», причем «вот так» зависит выпил ли он чашку кофе или еще нет. Вечером приходит художник, который нарисовал кнопку в фотошопе и хочет, чтобы на экране она выглядела пиксель-в-пиксель, и вы обязаны учесть эти требования, потому что в этой цепочке принятия решений художник стоит ближе к финальной картинке. А еще есть программист игровой логики, который не хочет знать, как называется конкретный лейбл, и не должен этого знать. Под конец приходит локализатор, который превратил «1 enemy / 2 enemies» в «1 враг / 2 врага / 5 врагов» и зависимость от рода. Иногда заскакивает инженер по портированию, которому надо то же самое окно крутить на PC, консолях или мобилках с разными разрешениями и соотношениями сторон, ну на него пофиг, он сам себе программист и если что, допишет код. И всё эти требования должны как-то жить вместе. Большая часть студий начинала с написания системы GUI «по месту», т.е. для конкретной игры, под конкретный рендер, с захардкоженной раскладкой, а когда выходила следующая игра, выяснялось, что вытащить старый GUI почти невозможно. Такой UI насквозь срастается с рендером, инпутом, звуком и игровой логикой и каждый следующий проект начинается с фразы «давайте сделаем нормально один раз», и каждая следующая итерация показывала, что «нормально» это не одна задача, а много и одновременно. Не переключайтесь, будет еще вторая часть про то как этот самый UI мучали от игры к игре... Погрузиться в глубины

https://habr.com/ru/articles/1039592/

#с++ #с++_программирование #программирование #игры_и_игровые_приставки #никто_не_читает_теги

Менеджер ресурсов

В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек вида LoadTexture(" bark.dds ") , а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы. Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме. Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds , которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться. Более явный пример для шейдеров будет, когда lighting.fx , скомпилированный с дефайном SIMPLE_BUMP_MAPPING , и lighting.fx , скомпилированный с PARALLAX_BUMP_MAPPING , физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый. С мешами история та же самая, и ship.mesh , загруженный в менеджере ресурсов, и тот же ship.mesh , лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет. Грузись текстурка, большая и маленькая

https://habr.com/ru/articles/1039266/

#с++ #программирование #разработка_игр #игры_и_игровые_консоли