XNA и C # против 360-х в порядке процессора

14

Прочитав эту напыщенную речь , я чувствую, что они, вероятно, правы (учитывая, что Xenon и CELL BE оба очень чувствительны к ветвящемуся и кешированному коду ), но я слышал, что люди тоже делают игры на C # тоже хорошо.

Итак, правда ли, что с XNA невозможно сделать что-то профессиональное , или просто не хватает плаката, что делает XNA убийственным API для разработки игр?

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

Тем не менее, многие люди, кажется, прекрасно работают в этих условиях, создавая свои успешные игры, но, по-видимому, избегая любых проблем из-за упущения. Я не заметил, чтобы в играх XNA было что-то сложное, кроме того, что уже предоставлено библиотеками или обрабатывается шейдерами. Это избегание более сложной игровой динамики из-за ограничений C # или просто людей, концентрирующихся на достижении этого ?

Честно говоря, я не могу поверить, что война ИИ может поддерживать столько юнитов ИИ без какого-либо подхода, ориентированного на данные, или каких-то грязных взломов C #, чтобы заставить его работать лучше, чем стандартный подход, и я думаю, что это тоже частично мой вопрос, как люди взломали C #, чтобы он мог делать то, что программисты игр делают естественным образом с C ++?

Ричард Фабиан
источник
Рэнт действительно. Не найдя ЛЮБОЙ информации о парне и не увидев, что он (он?) Стартап, я хотел бы увидеть любую ощутимую информацию, подтверждающую это ...
Джонатан Коннелл,
По причинам, которые я не совсем понимаю, студии, похоже, не признаются в использовании XNA. Однако есть много примеров здесь ссылка
Тристан Уорнер-Смит
Ну, очевидная информация, подтверждающая это, заключается в том, что ЦП довольно плохо работает с ветвистым кодом, которым является C #. Что я хотел бы знать, так это то, что делают профессиональные пользователи XNA, что означает, что они не достигли мягкого предела, наложенного C #?
Ричард Фабиан
3
я не могу понять голосование против ...
FxIII
3
Я думаю, что многие люди осуждают вопрос Ричарда из-за (многочисленных) технических ошибок в его связанной статье, а некоторые смеются над словом «профессионал», что означает «производство на уровне гало», а не «зарабатывает деньги». Последний вариант - плохой выбор, но не стоит принижать его только потому, что вы не согласны с этой ссылкой - опровергните ее, ответив вместо этого.

Ответы:

21

Хорошо, просто чтобы пробить дыры в той разглагольствованию, которое вы связали:

  • «C # опирается на интерпретатор« Just In Time »» - неправильно - это JIT- компилятор . После того, как метод JITted один раз , скомпилированный код повторно используется для каждого вызова. Скомпилированный код очень близок к такому же быстродействию, как и предварительно скомпилированный код.
  • «Ксеноновый процессор - это« на месте »процессор» - он имеет в виду «по порядку»? - И: «Ксеноновый процессор не имеет предсказания ветвления» . Он подразумевает, что это означает, что JIT-компиляция естественным образом создает плохой код, который должен быть переупорядочен ЦП и вызывает много ветвлений - что является абсолютной чепухой . Один и тот же совет по производительности для работы на этой архитектуре процессора применим как к C ++, так и к C #.
  • «[JIT] требует постоянного сброса на 360» - неправильно, скомпилированный код может храниться в кеше, как любой обычно скомпилированный код. (Если он имеет в виду конвейерную очистку, см. Пункт выше.)
  • «генерики [...] используют генерацию кода» - генерики JITted, как и все остальное, и, как и все остальное, код JITted быстрый. За использование дженериков не снижается производительность.
  • «все сексуальные составляющие языка [...] требуют предсказания ветвлений ...» - как это также не относится к C ++? - «... или [...] генерация кода на месте» - он имеет в виду JITting? Я упоминал, что это быстро? (Я не буду вдаваться во все места, где CLR для настольных компьютеров использует фактическую генерацию кода - функция, не поддерживаемая Xbox 360!)
  • «[C # не имеет] огромных библиотек [C ++]» - кроме, скажем, самой XNA? И многое другое . (Тем не менее, это несколько справедливо.)

XNA на Xbox 360 работает на модифицированной версии .NET Compact Framework CLR. Я не сомневаюсь, что это не соответствует стандарту настольной версии. JITter, вероятно , не так хорош, но я тоже не думаю, что это плохо . Я удивлен, что он не упомянул сборщик мусора, который ужасен по сравнению с настольным CLR.

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

(Для реального технического обсуждения .NET Compact Framework, возможно, начните с этой серии статей: Обзор , JIT-компилятор , GC и куча .)

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


Теперь, когда мы получили , что из пути, вот некоторые вещи , которые вы бы пропустить с помощью XNA на 360, а не идти родным :

  • Доступ к блоку SIMD / Vector для действительно очень быстрой математики с плавающей запятой процессора
  • Возможность использовать код на родном языке, который, вероятно, будет немного быстрее, чем C #
  • Возможность быть немного немного ленивее с тем, как вы выделяете память
  • Игры XBLIG имеют доступ только к 4 из 6 ядер (но мы по-прежнему получаем все 3 процессора, и они также не являются полными ядрами, поэтому мы не пропускаем много) - не уверен, применимо ли это к не-XBLIG XNA игры
  • Полный доступ к DirectX для выполнения действительно непонятного графического обмана

Также стоит отметить, что это только ограничения на стороне процессора. У вас все еще есть совершенно бесплатный доступ к графическому процессору.

Я описал эти вещи в этом ответе на тот же вопрос, что и этот. Как я уже упоминал в этом ответе, XNA абсолютно подходит для «профессионального» развития .

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

Конечно, для многих из нас, кто не является «профессиональным» разработчиком, XNA - наш единственный вариант, чтобы перейти на Xbox 360, что делает вопрос спорным.


Чтобы ответить на другие ваши вопросы:

Ничто в C # не мешает вам использовать ориентированные на данные подходы практически так же, как вы используете их в C ++.

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

Вероятно, еще одной причиной, по которой вы не часто сталкиваетесь с такими сложными математическими процессорами, как обнаружение столкновений и симуляция флюидов в C #, является отсутствие доступа к векторному блоку (как упоминалось выше).

Эндрю Рассел
источник
Я не помню себя, но разве C # не мешает вам перебирать простые массивы? Я помню кое-что об этом, объединяя первоклассные типы, такие как int, float, char, и из-за этого некоторые ориентированные на данные подходы работают не так быстро, как могли бы. Это правильно? Что я помню?
Ричард Фабиан
2
C # будет содержать типы значений (а не только встроенные - вы можете создавать свои собственные типы значений), если вы назначите их objectтипу. И в версии 1 (до генериков) вы не могли поместить их в контейнер, не являющийся массивом, без упаковки в них. Но в наши дни писать код без коробки очень просто. И CLR Profiler позволяет вам обнаружить любое место, где вы можете заниматься боксом.
Эндрю Рассел
Возможно ли даже иметь переводчика JIT? Звучит парадоксально.
Коммунистическая утка
Я видел несколько методов многопоточного кода, которые я бы классифицировал как JIT-интерпретацию. Это определенно крайний случай.
1
@Roy T. « XNA Math Library » (часть DirectX) и « XNA Framework » - это две совершенно разные вещи с очень неудачным конфликтом имен. Связанная с вами документация не относится к XNA Framework. Математические типы XNA Framework не используют единицу SIMD / Vector .
Эндрю Рассел
5

Вы должны определить «профессионал». Не могли бы вы сделать Angry Birds, Plants vs Zombies и т.д.? Абсолютно. Не могли бы вы сделать Crysis 2, COD, Halo? Я в этом сомневаюсь. Использование C # действительно только повлияет на игры, которые сильно нагружают процессор, а также должны сжать каждый последний байт памяти (вы проигрываете сборщику мусора), так что вы можете сделать очень много.

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

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

Роджер Перкинс
источник
Вы могли бы сделать дерьмовое продолжение Duke Nukem? ;)
Джонатан Коннелл
1
Большинство тестов показывают, что код C # работает где-то на 30-70% медленнее, чем эквивалентный код C (на ПК). Если учесть, что большинство игр не привязаны к процессору, а также что критические части кода C # могут быть написаны с использованием небезопасного кода, который может работать почти так же быстро или быстрее, чем эквивалентный код C (быстрее, потому что JIT имеет гораздо больше информации, доступной для это не компилятор, поэтому он может сделать лучший выбор оптимизации) , вы видите, что C # отлично подходит для игр AAA.
BlueRaja - Дэнни Пфлюгофт
@BlueRaja: небезопасный код не подходит для большинства разработок XNA на Xbox 360.
1
@BlueRaja: Стоит отметить, что unsafeкод часто медленнее, чем безопасный эквивалент, потому что он уменьшает количество оптимизаций, которые может выполнять CLR. Вы должны измерить это.
Эндрю Рассел
2
@Blueraja "Когда вы считаете, что большинство игр не связаны с процессором", цитата нужна очень? Я не работал над профессионально разработанной игрой, которая не связана по всем направлениям. если бы не было, мы бы нашли способ переложить нагрузку на эту часть машины!
Ричард Фабиан
3

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

более профессиональные игры имеют физические модели и системы анимации

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

DeadMG
источник
1
Большое количество полигонов и HDR упадут на видеокарту, не так ли? Поэтому вы должны ожидать одинаковую производительность в C # и C ++.
BlueRaja - Дэнни Пфлюгофт
@BlueRaja: Для них тоже есть стоимость процессора и памяти - особенно на 360.
DeadMG
Более или менее, есть немного больше накладных расходов на вызовы графической библиотеки, чем было бы в нативном коде. С другой стороны, современные графические библиотеки ОЧЕНЬ стараются уменьшить количество обращений к драйверу на кадр, поскольку это одно из основных узких мест.
drxzcl