XNA和C＃与360的订单处理器

读过这个咆哮之后，我觉得他们可能是对的（因为Xenon和CELL BE 对分支和caching无知的代码都非常敏感），但是我听说人们也在用C＃制作游戏。

那么，是不是真的不可能用XNA做任何专业的事情，还是海报只是想让XNA成为游戏开发的杀手锏？

对于专业人士来说，我并不是说可以从中赚钱，而是更多的是因为更专业的游戏有一些看起来超出语言范围的视觉模型和animation系统，而这些内在的障碍是有一定的障碍的。如果我想为我的游戏编写一个碰撞系统或stream体动力学引擎，我不觉得C＃为我提供了这样的机会，因为运行时代码生成器和内部函数的缺乏会影响性能。

然而，许多人似乎在这些限制之内做了很好的工作，使他们的成功的游戏，但似乎避免任何遗漏的问题。我没有注意到任何XNA游戏除了已经由图书馆提供的东西或者由着色器处理的东西之外都做任何复杂的事情。这是否避免了更复杂的游戏dynamic，因为C＃的限制，或只是人们集中精力完成？

坦率地说，我不能相信AI战争可以保持那么多的AI单位而没有一些数据导向的方法，或者一些肮脏的C＃黑客使它比标准方法更好地运行，我想这也是我的一个问题，有人剽窃C＃，所以它可以做什么游戏编码器自然与C + +做？

好吧，只是为了捅你连接的咆哮中的一些漏洞：

“C＃依赖”Just In Time“解释器” – 错误 – 它是一个JIT 编译器 。在一个方法被JIT 一次之后 ，编译的代码将被重复用于每个调用。编译后的代码非常接近原生预编译代码。
“氙气CPU是一个”就地“处理器” – 他的意思是“为了”？ – 和： “氙气CPU没有分支预测” 。他暗示这意味着JIT编译自然会产生不好的代码，必须由CPU重新sorting，并导致大量的分支 – 这是绝对的废话 。在这个CPU体系结构上运行的性能建议同样适用于C ++和C＃。
“[JIT]需要360不断刷新” – 错误的是，编译后的代码可以像任何正常编译的代码一样保存在caching中。（如果他意味着管道冲洗，请参阅上述要点。）
“generics使用代码生成” – generics与其他所有事物一样被打乱，和其他所有事情一样，JITted代码是快速的。使用generics没有性能损失。
“语言的所有性能都需要分支预测…” – 这不适用于C ++吗？ – “…或者就地代码生成” – 是否意味着JITting？我提到它速度快吗？（我不会进入桌面 CLR使用实际代码生成的所有地方 – Xbox 360不支持的function！）
“[C＃没有]大量的C ++库” – 除了XNA本身？还有更多。（但是，这是一个有点公平的点。）

Xbox 360上的XNA运行在.NET Compact Framework CLR的修改版本上。我毫不怀疑，这是不符合桌面版本的标准。 JITter可能不是那么好 – 但我不认为它也不好。我很惊讶他没有提到与桌面CLR相比可怕的垃圾收集器 。

（当然，你不应该在专业开发的游戏中打垃圾收集器，就像你在任何专业级游戏中必须小心分配）。

（关于.NET Compact Framework的实际技术讨论，可能从本系列文章开始：概述， JIT编译器， GC和堆）。

对他的术语完全没有特定性的方式使得很难理解他的意思。要么他处于最高级的模式，要么不知道他在说什么。

现在我们已经弄清楚了，下面是在360上使用XNA时错过的一些东西，而不是原生的 ：

访问SIMD / Vector单元来完成真正快速的CPU浮点运算

使用本地语言代码的能力可能会比C＃更快一些

能够对分配内存的方式稍微懒散些

XBLIG游戏只能访问6个内核中的4个（但是我们仍然可以获得全部3个CPU，而且它们不是全内核，所以我们不会错过） – 不确定这是否适用于非XBLIG XNA游戏

全面的DirectX访问，用于做非常模糊的graphics欺骗

还值得指出的是，这些只是CPU端的限制。您仍然可以在GPU上完全自由的访问。

我在这个答案中描述了这个问题，这个问题和这个问题是一回事。正如我刚才提到的那样， XNA绝对适合“专业”开发 。

你要避免的唯一原因是因为你不能雇用C＃人才，许可C＃引擎，重复使用现有的C＃代码，就像你现有的C ++知识基础一样。或者因为您可能也瞄准了不支持C＃的平台。

当然，对于我们中许多不是“专业”的开发者来说，XNA是我们唯一的selectXbox 360的select，使得这个观点没有实际意义。

回答你的其他问题：

C＃中的任何内容都不会阻止您使用基于数据的方法，这与您在C ++中使用它们的方式基本完全相同 。

C＃缺乏在编译时自动内联代码的能力，而且（无需检查）我很确定紧凑的CLR的JITter不能内联方法（桌面CLR可以）。因此，对于性能关键的代码，您可能需要在C＃中手动内联，C ++提供了一些帮助。

在C＃中碰撞检测和stream体模拟等常见的CPUmath密集型的东西，可能是一个更大的原因是缺乏访问vector单元（如上所述）。

你必须定义“专业”。你可以做愤怒的小鸟，植物大战僵尸等？绝对。你可以做孤岛危机2，化学需氧量，晕？我对此表示怀疑。使用C＃只会影响游戏的CPU密集程度，并且还需要压缩内存的每个最后一个字节（因为垃圾收集而丢失），所以还有很多事情可以做。

作为人们入门的学习工具，原型工具，能够处理交易的游戏平台等等，这是非常棒的，有很多的力量和简单性，它只是没有被devise来制造你所需要的打电话给'AAA'游戏。它也带走了很多人们不得不担心跨平台移植和兼容性的痛苦和苦难。

如果你想出了一个令人惊叹的游戏，并且遇到了你可以用XNA做些什么的限制，那么我建议你直接联系MS，如果这个想法真的足够好的话，他们可能会让你得到一个全面的开发套件。

简单的事实是，您不需要高多边形数量，完整的HDR照明或世界上最有趣的物理学来制作一个有趣的游戏，如果您的游戏计划不包括任何这些，那么为什么不去更快开发时间解决scheme

更专业的游戏有phsyics模型和animation系统

这是错的。职业游戏有他们需要实现他们的游戏玩法，并实现他们的艺术外观，没有什么更多的，事实上，毫无疑问。游戏不是更专业，因为它看起来更现实或更详细的物理。专业的游戏可以按时，按预算等达到游戏性和视觉化的目标，并可以获得利润。