Подтвердить что ты не робот

Является ли C все еще широко используемым в игровых двигателях?

Название немного неверно, я действительно имею в виду "C с классами".

Позвольте мне объяснить, недавно я купил книгу ShaderX7, которая пришла с облегченной (и старой) копией движка Unigine для одной из статей о методах теневого отображения.

Я разбирался в коде, когда понял, что, хотя автор использовал С++ и наследование и все доброту С++, большинство, если не весь контент метода, был по существу кодом стиля C; например:

int Shader::get_param(const char *name,char *src,String &dest) const {
    char *s = src;
    int size = (int)strlen(name);
    while(*s) {
        if(!strncmp(s,name,size)) {
            if((s == src || strchr("\n\r",*(s - 1))) && strchr(" \t",*(s + size))) {
                src = s;
                s += size;
                dest.clear();
                while(*s && strchr(" \t",*s)) s++;
                while(*s && strchr(" \t\n\r",*s) == NULL) dest += *s++;
                if(dest.isEmpty()) {
                    Log::error("Shader::get_param(): can't get \"%s\" \n",name);
                    return 0;
                }
                memmove(src,s,strlen(s) + 1);
                return 1;
            }
        }
        s++;
    }
    return 0;
}

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

Действительно ли лучше/быстрее использовать этот тип кода, чем идти по общему пути OO?

Я попал в ловушку "слишком большой абстракции"?

Изменить: исправить имя метода, чтобы он дал понять, что он делает.

4b9b3361

Ответ 1

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

В стороне, у меня есть несколько слов об оптимизации, "испортить" языки и так далее.

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

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

  • Некоторые языковые функции могут быть дорогостоящими. Исключения в С++ - хороший пример.
  • Некоторые языковые функции могут фактически сохранить ваш код и будут стоить немного или ничего во время выполнения. Хорошим примером могут служить шаблоны на С++, хотя вы все равно можете создать много кода во время компиляции, что потенциально приведет к увеличению двоичного файла и, следовательно, к снижению производительности.
  • Инфраструктуры (например, STL) являются общими. Сделав решение, специфичное для вашего домена, вы МОЖЕТЕ улучшить свою производительность. Простой пример:— если у вас есть вектор, который всегда будет длиной 3 элемента, вы определенно будете лучше, чем реализация stl:: vector. Тем не менее, это не всегда так. Для дальнейшего чтения см. Главу 11 "Эффективный С++" Дова Бульки. Это отличная книга в целом для вашего вопроса.

В общем, использование C с классами - хороший старт для написания быстрого кода, сохраняя структурированный и хорошо продуманный проект, но не следует пренебрегать всеми превосходными функциями С++. Чаще всего попытка развернуть собственное решение проблемы, связанной с С++ (например, полиморфизм), будет медленнее, чем готовое решение, если вы не сможете сделать решение ОЧЕНЬ конкретным для проблемы.

Ответ 2

С++ без STL

Как я видел в своей профессиональной истории, то, что в основном используется в разработке игр, - это не C с классами, а скорее С++ без STL. Некоторые части STL считаются слишком медленными для разумной производительности игрового движка, в первую очередь потоков. Другие части обеспечивают разумную общую производительность, но способ распределения памяти в основном неприемлем для игр - это относится к строковым и векторным библиотекам в большинстве сценариев. Отличное подробное обсуждение этого можно найти в белой бумаге EASTL. Разработчики игр часто используют boost или даже реализуют свою собственную альтернативу части всей STL (см. Game STL или EASTL).

Без исключений

Существует одна особенность языка, которая никогда не используется в каких-либо частях, зависящих от производительности, - обработке исключений. Это связано с тем, что на самой важной платформе разработки игр (Visual Studio x86/x64) исключения являются довольно дорогостоящими, и вы платите некоторую стоимость, даже если не удаляются исключения. Исключения исключаются из-за того, что некоторые платформы консолей разработки даже не предоставляют их, или поддержка, как известно, является неполной, ненадежной и в основном "сломанной".

Используется для C

Кроме того, часто случается, что программисты используют C вместо С++ просто потому, что они привыкли к нему.

Ответ 3

Если вы действительно хотите рисовать графику как можно быстрее, и начинайте с

int size = (int)strlen(name);

который выглядит как лаять неправильное дерево.

Что получает get_something? Он не выглядит графическим.

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

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

Ответ 4

Если это:

  • Работает, и вы довольны этим, не трогайте его.
  • Не работает, меняйте его так, как вам нравится, пока он исправлен.
  • Работает, и это не достаточно быстро, сделайте это быстрее (НЕ сначала без профилирования).

Я предполагаю, что вы попадаете в случай 1, поэтому я бы посоветовал оставить его в покое. Если вам нужно что-то изменить, и у вас нет серьезных проблем с производительностью, обязательно используйте некоторые из них на С++. В общем случае мне трудно читать программисты на С++ C-style, они либо:

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

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