Программирование в gamedev (связано с производительностью)

Question

Мне просто интересно, как некоторые вещи работают в gamedev:

1. Я знаю, что производительность на самом деле крайне важна , поэтому до сих пор (и я думаю, что никогда не будет) нет места для использования управляемых языков / платформ в качестве Java / .NET только из-за их спектакль. Но ... недавно я читал где-то здесь о SO, что, хотя люди, создающие игры, используют C ++ в качестве основного языка, на самом деле они не используют STL или Boost (или их много). Думаю, это имеет что-то общее с производительностью, верно? Если я не прав, скажите, пожалуйста, по каким причинам вы избегаете этих библиотек (которые, как мне кажется, значительно облегчают жизнь разработчикам)? Это из-за лицензирования (Boost)? А как насчет версии STL от EA? Другие студии тоже делают свои версии?

2. Насколько "близко к металлу" программирование игры на самом деле? Вы идете глубже и ближе к машине? Вы иногда используете Assembly для критических внутренних циклов, или C ++ на самом деле является самым низким уровнем абстракции, который вы используете в данный момент? Я предполагаю, что в таких продуктах, где производительность является наиболее важной вещью, профилирование является очень, очень распространенной задачей - но иногда вы вынуждены использовать сборку для ускорения некоторых деталей, или хороший C ++ «достаточно хорош»?

Edit: Извините, возможно, это не совсем понятно, но мне интересны ответы людей, имеющих опыт в игровой индустрии. Я не заинтересован в некоторых предположениях, данных людьми, которые не имеют коммерческого опыта в разработке игр. Меня также не интересуют примеры некоторых нишевых игр, созданных на C # / Java. Однако, если вы знаете продукт, который выглядит лучше, чем FarCry2 (просто и пример, но ваше любимое современное название игры здесь прекрасно), и написан полностью в Java / .NET, и имеет производительность, аналогичную FarCry2. .. не стесняйтесь упоминать этот продукт! Спасибо.

Answer 1

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

Написание собственных контейнеров позволит вам писать кроссплатформенный код и упростить отслеживание памяти. Это особенно верно для консолей, где, например, PS3, требуется детальное знание аппаратного обеспечения, чтобы получить максимальную производительность от него. Что обычно в итоге означает, что вам нужен полный контроль над потоком памяти между PPU, SPU и RSX.

2. Ассемблер только "требуется" (в кавычках, поскольку это на самом деле не требуется, но помогает) для очень специализированных операций, например функции математической библиотеки. Что более распространено, это встроенные функции SIMD, которые векторизируют код. Тем не менее, большинство студий имеют устаревший код, который довольно оптимизирован, и, поскольку эти оптимизации находятся на довольно низком уровне, код не должен сильно меняться между поколениями оборудования. Я бы сказал, что на консолях гораздо чаще вы используете код более низкого уровня.

Answer 2

Я знаю, что производительность на самом деле имеет решающее значение, поэтому до сих пор (и я думаю, что никогда не будет) нет места для использования управляемых языков / платформ как Java / .NET только из-за их производительности.

Нет, вы не знаете это. Вы думаете об этом, вы хотите верить этому, потому что вы романтизируете разработку игр, и потому что вы думаете, что языки высокого уровня не могут быть быстрыми. Производительность .NET достаточно хороша для 90% игр. И это будет только лучше. Не существует внутренней причины, по которой управляемые платформы должны работать медленнее. У них есть потенциал , чтобы быть быстрее, потому что они JIT'ed. На практике их производительность примерно такая же, как у достаточно хорошего кода C ++, намного лучше, чем у типичного кода C ++, и немного хуже, чем у действительно хорошего кода C ++. И большинство больших игр в любом случае используют более одного языка. Они используют скриптовые языки, такие как Lua или Python, или некоторые домашние вещи, которые на несколько порядков медленнее, чем .NET.

Точно так же нет абсолютно никаких причин, по которым большая часть вашей игры не может быть написана на .NET. И затем три действительно критичные к производительности функции могут быть при необходимости перенесены на собственный C ++ позже.

Но ... недавно я где-то читал здесь о SO, что, хотя люди, создающие игры, используют C ++ в качестве основного языка, на самом деле они не используют STL или Boost (или их много). Думаю, это имеет что-то общее с производительностью, верно? Если я ошибаюсь, скажите, пожалуйста, по каким причинам вы избегаете этих библиотек

То же, что и ты, виновный в вышесказанном ... Суеверие в разработке игр. «О нет, мы не можем позволить себе использовать код других людей! Он слишком неэффективен». Разработка игр застряла в 80-х годах с точки зрения практики программирования и методологий. Другими словами, не беспокойтесь о том, что делают другие разработчики игр. Если STL или Boost облегчают написание вашего кода, используйте его! А затем, если у вас возникли проблемы с производительностью, профилируйте их и, если необходимо, замените этот конкретный компонент библиотеки своим собственным.

Но большая часть STL буквально равна нулю. И 95% кода в любой игре не критично для производительности. Относитесь к разработке игр так же, как к любым другим программам. Не относитесь к этому как к волшебной стране, где каждая строка кода должна быть идеально оптимизирована и где нормальные правила не применяются.

А как насчет версии STL от EA? Другие студии тоже делают свои версии?

Насколько я знаю, нет. EA сделала это частично для внутреннего использования, а также как вклад в сообщество C ++ в целом, в качестве примера того, что они (и многие разработчики игр) хотели бы увидеть в будущих версиях стандарта (он был представлен комитет по стандартам)

Answer 3

Могу порекомендовать книгу C++ for game programmers. В нем подробно обсуждается стоимость производительности функций C ++, таких как STL, исключения и RTTI. Это также касается наличия собственного менеджера памяти и различных общих оптимизаций производительности.

Кажется, есть новая редакция , но у нее другой автор. Что с этим?

Answer 4

Мы используем 'STL' (т. Е. Стандартную библиотеку C ++) и небольшое количество Boost. Однако некоторые из них избегаются или осуждаются (std :: map, std :: list, boost :: shared_ptr), как правило, из-за чрезмерных политик выделения памяти или плохой когерентности кэша. Обычно это можно обойти, например. с пользовательскими распределителями, но вместо этого у нас есть другие подходы к тем же проблемам с их собственными преимуществами.

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

Однако будьте осторожны, утверждая, что Java / .NET и т. Д. Никогда не используются. Не всем нужна производительность FarCry2 (что является довольно завышенной спецификацией), поэтому вы видите все больше и больше игр, написанных на управляемых языках с C ++ только для оптимизации.

Answer 5

О 1:

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

Повышение может быть очень полезным, но оно действительно зависит от конкретной части повышения, полезно это или нет для кода, критичного для производительности. Например, Boost :: filesystem была очень полезна для меня, в то время как boost :: сигналы были едва применимы из-за очень низкой производительности. Поэтому я реализовал свою собственную библиотеку сигналов, используя вместо этого FastDelegates.

О 2:

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

Например, мой собственный движок 2D-игр работает без аппаратного ускорения. Я разработал его, когда 3D-драйверы все еще были довольно глючными, и у большинства казуальных игроков устаревшие драйверы видеокарт, поэтому совместимость была важнее, чем чистая производительность в то время.

Тем не менее, в нашей последней игре Gemsweeper мы используем много альфа-смешивания с 8-битными альфа-масками, и игра все еще должна работать на процессорах с частотой 500 МГц. Таким образом, альфа-смешение оказалось критической областью производительности.

Чтобы оптимизировать это, я использовал компилятор VectorC, чтобы я мог использовать MMX, SSE и тому подобное без необходимости написания ассемблерного кода. Но один и тот же код может быть быстрым на одном процессоре и медленным на другом (например, Intel против AMD), поэтому я также несколько раз компилировал код альфа-смешивания с различными настройками оптимизации. Игра запускает тест во время выполнения, чтобы найти самый быстрый модуль блиттинга для каждого метода блиттинга, и использует этот модуль с тех пор.

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

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

Answer 6

Правда, при разработке игр STL не используется. Несмотря на то, что некоторые люди всегда спешат утверждать, они также никогда не используют Java, C # или другие управляемые языки.

Я не говорю о небольших загружаемых играх X-Box Live Arcade, играх для веб-браузера или о подобных вещах. Я говорю о разработке высокого уровня в играх ААА.

Они не используют STL. Тем не менее, они используют свои собственные пользовательские реализации, которые очень похожи на STL. Будут умные массивы, будут хеш-таблицы, будут умные указатели, просто они не будут STL.

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

Большинству игровых студий также нужен код, который они могут адаптировать к другим платформам. Блокировка реализации от MS / Sony / Nintendo значительно усложняет процесс переноса игры на новую платформу. Предоставленные библиотеки шаблонов (которые не обязательно должны начинаться с STL) часто менее звездные. По крайней мере, они находятся на раннем этапе аппаратного цикла, когда студия прорабатывает движок, который они планируют использовать в течение следующих пяти лет.

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

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

Answer 7

Вы можете узнать сами (в некоторой степени), посмотрев SDK для игр.

Почти во всех играх id Tech 4 (DooM III, Prey, Quake IV, ET: QW) есть SDK, включающие в себя системы физики, сценариев, искусственного интеллекта, математики и т. Д. Единственный асм используется для специализированного математического кода, все остальное - чистый C ++.

Crytek имеет Crysis SDK (для установки SDK вам понадобится игра), а Far Cry SDK.

Valve имеет Source SDK, доступный любому, кто приобрел игру Source через Steam.

Есть намного больше, если вы посмотрите. Большая часть кода не является особенно чистой или гибкой (иногда даже не быстрой), но я полагаю, что в написанном вами коде легче настраивать, а не монолитные библиотеки, полные трудного для понимания шаблона.

Answer 8

Нет, вы в значительной степени ошибаетесь. И .NET, и Java использовались в коммерческих играх, конечно, в Windows (и, вероятно, также на консолях).

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

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

Я предполагаю, что исторически на некоторых платформах хорошие реализации STL не были доступны, особенно на таких устройствах с ограниченным объемом оперативной памяти, как PS2.