1.4 XNA相关
在结束这一章之前，还有一些关于XNA Framework和XNA Game Studio Express的提示和技巧。如您所见，虽然您现在可以进行编码了而且程序工作得也很棒，但是当您遇到了难题或者不知道怎么解决一个特定的问题时，在您的浏览器上拥有一些书签可以去查找还是很有必要的。另外，本节将讨论一些.Net和C# 的优点以及XNA和托管DirectX之间的区别。
重要链接
您可以把下面的一些链接加入您的书签中：
- http://msdn.microsoft.com/directx/xna 微软MSDN上的XNA开发中心，里面有XNA Game Studio论坛和XNA Framework论坛，这些是您在网络上可以找到的最活跃的XNA论坛，您还可以在这里下载XNA的最新版本，浏览问题及解答，以及最新信息。
- http://en.wikipedia.org/wiki/Microsoft_XNA Wikipedia上的XNA，这里的内容更新很快，包含很多其它主题的链接，在页面的底部列了一些有用的外部链接。
- http://xnadevelopment.com 这是一个新站点，里面有很多链接、学习指南以及技巧来帮助您在XNA的世界中从头开始学习。
- http://xnaresources.com 这也是一个新站点，里面有很多新闻，一些非常有用的关于Tile引擎的学习指南，以及很多您可能会感兴趣的游戏组件。
- http://learnxna.com Blog形式的XNA新闻站点，包含很多视频学习指南，主要关注XNA的学习以及绘图工具的使用技巧。
- http://abi.exdream.com 本书作者的官方站点，在这里您可以找到更多我制作的游戏，像XNA Rocket Commander、XNA Shooter，还有本书中的XNA Racing Game，以及很多介绍它们的文档和视频指南。另外，我建议去看看Rocket Commander的介绍视频，它在Coding4Fun上非常受欢迎。
C#适合开发游戏吗？
在类似www.GameDev.net这样的站点上经常有帖子讨论C++和C#之间的区别，通常讨论讨论就演变成了语言之间的战争。回到.Net诞生的初期（2002年）我也参与了很多类似的讨论，但是郁闷的是当时几乎99.9%的人都站在C++的一边，根本没有任何方式来说服任何人，因为他们根本不理你。语言之战针对的并不是把C#作为一门开发，而是使用C#来开发游戏，因为C#和Java都是托管语言并且它们看起来极像，而Java尝试作为游戏开发平台失败了（除了作为手机游戏开发平台）。这和之前C取代汇编（Assembler）、C++取代C的语言之战很像，即使到了Bjarne Stroustrup发明C++语言已经20多年后的今天，一些游戏开发者仍然使用C而没有真正充分利用C++的优点，如果您看看一些著名的游戏引擎（像Quake和Half-Life）的源代码，您会发现它们更像是C而不是C++。
这在游戏编程世界是一件非常奇怪的事情，人们都害怕在转换到新的语言平台之后会有很多性能损失，而且可能会失去旧有的基础代码或者做很多工作把它们转换到新的语言平台。尽管如此，游戏开发人员会很快地采用新技术和脚本语言，而且总是在最新的硬件上进行开发。支持Shader Model 4的显卡还有一年的时间才会出现，但我们这些游戏开发者们却在尝试Direct3D 10了，即使没有相配套的硬件来运行。
在2001年底尝试了.Net和C#的测试版本之后，我很快就在2002年初采用了这套平台。我以一个新的游戏引擎作为开始，我们的工作小组也开始了一个新项目。在.Net的初期除了一些简单的2D游戏，几乎没有一个图形引擎可用，这使得在C#直接中使用OpenGL或者DirectX非常困难，必须要频繁地调用非托管的DLL，还要处理很多令人厌烦的指针逻辑，而且这些还必须得在C# 的非安全模式（Unsafe Mode）下进行。2003年微软终于发布了托管DirectX的第一个测试版本，这使得在.Net环境下开发新的DirectX应用成为了可能，而且使用托管的DirectX比使用原始的DirectX在性能上的损失只有1%-2%，仔细想想这并不是很重要（仅仅是CPU多做了一点点工作而已）。
但这并不是说游戏开发者都会转向C#，即使在我2004年发布了第一款基于.Net平台的商业游戏“Arena Wars”之后大家仍然持怀疑态度。然后又过了一年才开始有越来越多的开发者开始尝试.Net平台，尤其是学生和初学者都非常喜欢C#的简易性，更多的人开始使用.Net平台来开发游戏。但是C++和C#之间的讨论仍然存在，讨论的焦点也还是一样，只是现在双方的阵营已经趋于平衡了（很早之前我就已经不在看那些主题中包含“VS”字样的帖子，因为一遍遍地看这些相同的争论简直就是浪费时间）。
当您碰到那些告诉您C#只适合新手，C++更高级时，要谨记上面所说的。同样的事情在多年前也发生在汇编和C++身上，将来也一定会有新的语言让我们的工作更容易，也还会有很多人犹豫是否要立即采用它们。大多数大型的游戏工作室不能立即采用每一项新技术，他们或许正处在某个大项目的开发过程中，而且他们有太多的基础代码不能很容易地进行转换。不过，从长远来看，代码始终要被转换，我们也会更多地采用高级语言。
图1-15是我做的一张图片来表示C++中的DirectX和C#中的托管DirectX的区别。正如您所看到的，MDX（Managed DirectX）代码量只有非托管代码量的一半多。在XNA中代码量甚至会更少，而且更加容易地来导入texture并把它们呈现在屏幕上，不过XNA和MDX之间的比较会比较困难，因为它们的概念是不一样的。
图1-15
习惯内容管道
正如在您的第一个XNA项目中看到的，在XNA Studio中向游戏项目中拖拽添加一个texture是非常容易的。虽然把所有的游戏内容都放到一个地方并且直接和代码在一起很不错，但是，我所见过的大多数项目都不会直接把诸如texture、模型和shader内容放到Visual Studio的项目中，原因是直接手动复制这些文件并让游戏直接加载它们更容易。默认的Visual Studio不会复制任何内容文件到输出文件夹，您必须手动设置内容文件属性中的“生成操作（Build Action）”，把它从“无（None）”设置为“内容（Content）”，并且还要设置“复制到输出目录（Copy to Output Directory）”，把它设置为“如果较新则复制（Copy if Newer）”。这的确是一个麻烦事，不过XNA已经让这个操作更加容易了。
您或许会问为什么要改变之前载入texture的方式。如果想让您的游戏运行在Windows平台上，您可以动态地加载texture和shader而无需先把它们作为内容文件导入项目中，这样做的好处是您可以在游戏运行的时候改变texture和shader（XNA的内容管道不支持这一特性）。但是对于模型文件（Model Files）这样却行不通，因为除了使用ContentManager类（它只加载编译过的.xnb内容文件）中的加载方法之外没有其它的方法可用。
在Xbox 360平台上只能加载内容文件，不支持直接加载texture和shader。如果您用了直接加载texture和shader，那必须得把这些代码从Xbox 360平台上排除掉，Xbox的DLL文件不支持加载除了内容文件的其它任何东西。
有关更多关于模型文件的详细内容，请参考本书第二部分的相关章节，这个话题并不像使用texture那么简单。所以，本部分只讲sprite和2D texture处理，这样会使事情更加简单。对于简单的2D游戏这些的确很不错并且也很容易，不过要做一个专业点的游戏，您需要3D模型和很多非常酷的Shader特效。我还建议您找一个专门的设计人员为来做texture和3D模型，因为这是一个非常复杂的话题，您一个人做所有事情会浪费很多时间，而其他人可能更善于做texture和3D模型，要好好利用您写代码的特长而让其他人去做画面。如果没有设计人员可用，您可以使用本书中的以及XNA初学者工具包中的模型和texture作为开始。
和MDX的差别
如果您之前做的是MDX（Managed DirectX）的开发，现在想把您的游戏移植到XNA Framework中，那么可以访问XNA官方网站上的一个非常好的指导：http://msdn.microsoft.com/directx/xna/migration/ 。
您也可以在XNA帮助文档中找到相关帮助，这里我不再赘述。不过您必须要记住的是，默认地XNA使用的是右手系（right-handed）坐标矩阵，而MDX使用的是左手系（left-handed）坐标矩阵，另外还有一些新的类和结构让您不必再使用Windows.Forms命名空间（namespace）。因为没有固定功能管道（fixed function pipeline）的支持，旧有的使用Windows Forms和句柄（handles）以及考虑兼容老的个人电脑的配置的工作方式也不再需要。Graphics和Shaders将在本书的第二部分讨论。
更多的工具和技巧
您还应该看看XNA帮助文档中的关于“从头开始（Getting Started）”的帮助主题，会发现很多有关连接到Xbox 360、开始第一个项目以及其它初学者工具包的信息。
就像我之前提到的，TestDriven.Net是一个非常好的工具，测试驱动开发（test-driven development）在本书中也是一个非常重要的方法学（见第三章）。对于.Net开发另一非常好的工具就是Ants Profiler，和我提到的其他的工具不同的是，它不是免费的，但您可以在网上找到一些有相同作用的工具。Ants Profiler可以用来直接查看您项目的每一行代码执行所用的时间，个人认为它比一些更高级的应用程序性能测试工具更好用，比如NvPerf（Nvidia）、PIX（DirectX SDK）或者Performance Counters of Windows。您可以很快地查出为什么渲染代码执行很慢，监测一些bug等等。