Аллокаторы для игрового движка - PullRequest
5 голосов
/ 28 апреля 2011

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

Я знаю, что это звучит немного тревожно для некоторых людей, и поэтому я думаю, что мне нужно немного оправдать свою позицию. Я прочитал ответы здесь и здесь (а также блоги, на которые они указывают здесь , здесь и здесь ). Но, видите, я пытался «сначала создать игру, снова и снова, а затем код, который вы повторно используете, - это ваш« движок »», и он мне не помог. Я обнаружил, что на самом деле увяз в том, что делаю снова и снова (возможно, не очень хорошо использовал мой код), и далеко не продвинулся ни в одной игре.

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

Я действительно оказался вне своей лиги, поэтому купил несколько книг. Архитектура игрового движка Джейсона Грегори (GEA) действительно хороша, между прочим, но у меня также есть Game Coding Complete (McShaffry) и Programming Game AI на Примере (Buckland). У GEA есть несколько действительно хороших идей о высокопроизводительных распределителях, и это действительно заинтересовало меня, поэтому я подумал, что смогу попробовать.

Я кодировал распределитель на основе стека и почти закончил распределитель на основе пула. Оба имеют возможность выравнивания памяти и могут быть назначены для работы с различными бюджетами памяти (т. Е. Любой распределитель может, например, использовать «розничную» память или память «разработки» и т. Д.). Я считаю, что создание этих компонентов очень полезно с точки зрения моих навыков программирования / уровня интереса.

Мне интересно, есть ли разработчики, которые бы порекомендовали какие-либо другие структуры распределителей, которые полезны или регулярно появляются в разработке игр. ? Или есть ли разработчики, которые никогда не использовали что-либо еще за всю свою карьеру?

Опять оправдываю мой вопрос (я почти слышу, как люди шепчут: «Просто создай свою собственную игру и посмотри, какие структуры тебе нужны ...», но ...) Архитектура Game Engine была для меня таким большим ресурсом, потому что автор готов и не стесняется сказать «эй, это то, что индустрия в основном делает Сорта». И это сэкономило бы мне много времени на написание целой кучи игр и выяснение того, что полезно, если бы кто-то мог сделать «повторное использование опыта» и сказать «подумать об этой структуре».

Ответы [ 2 ]

2 голосов
/ 28 апреля 2011

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

Если вы не разрабатываете для PlayStation или другого консольного барахла со сломанной стандартной библиотекой, вы даже не должны думать о написании своего собственного распределителя.Это полностью ортогонально к разработке игр и трата вашего времени.Это 2011, а не 1992, и вы не имеете дело с системами DOS с 2-4 МБ оперативной памяти, где вам приходится самостоятельно управлять кэшированием и удалением данных.Пусть система виртуальной памяти сделает всю работу за вас и потратит время на создание игры, а не на половину операционной системы.

1 голос
/ 28 апреля 2011

Честно говоря, больше всего я использовал Pool<T> для недолговечных объектов и предварительно выделенную кучу в качестве замены по сравнению с C ++ по умолчанию.

Но еще раз, разработайте то, что вам нужно, когда вам это нужно .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...