从上周开始在公司做一个新项目，这是我上班以来参与的第四个商业项目。我以为不是程序员选择项目，而是项目选择了程序员，一直以来似乎每个阶段我都有一两件必须去做的事情，这就是冥冥之中的定数吧，既是缘分，我便全力以赴莫留遗憾，贡献和成就能做到哪个份上全看造化了。
新项目涉及到XNA和cocos2d，于是这十来天边看代码边查资料边做些地基构建。一直想看下cocos2d以便后面两个私人项目使用，却直到这次才真正潜心阅读，花了两天时间摸清了些来龙去脉，竟发现它的设计正是我当初对的预想。我顺带把cocos2d从最原始的python版看到obj-c版，再到c++版然后是两个c#版，没想到它一路从python的两万来行代码被人port到obj-c的四万来行再到c++杂七杂八的几十万行，我没去看javascript的版本，依javascript的表达能力料想简洁程度应不输python原版。c++果然是太罗嗦了。也许ogle2d我将来会按我自己的设计和cocos2d的思路用c写出来，node和action做的再抽象些再分离些，说远了，待我把cocos2d的脾气摸透了再说。从cocos2d做精简也是较容易的，除去action的cocos2d的功能基本上相当于XNA或者HGE外加node场景组织。
几年前读大学时稍微接触过一点XNA，当时给我的感觉它还是一个给人玩的试验品，我还是从微软学生中心下载到的它。如今它已经成了WP开发的主力和XBox360开发的重要一员。XNA是我见过微软搞出来的最精简的库之一，简洁到机制和限制都一目了然。XNA应是出于部署方便和运行时加载高效的思量，最常规的待加载资源都是在部署前预先将一个专用的content工程编译打包成单一的资源包中，对于游戏运行时来说这是很方便也很必要的，不过相关编辑器的开发却需要从任意文件（而非content包）创建出对象的能力。我在msdn（）捞到了一篇非常有用的文章和配套代码。这是微软官方写的一个在Winform上加载并渲染磁盘独立模型文件的东西，按它的方法任意XNA资源都可做成磁盘文件加载的模式。编辑器对音频、视频的文件加载倒不是很在意，不过贴图和字体是很需要的。 XNA中已经提供了从内存创建贴图的能力，配合System.Drawing.Image之类的东西贴图的文件加载可以方便解决，字体却比较难了，SpriteFont不能从内存创建，于是只能用上文提到的代码解决。官方加载模型的代码写的是：
contentBuilder.Add(fileName,
"Model",
null,
"ModelProcessor");
// ...
contentManager.Load
("Model");
只需改成如下即可在运行时编译加载创建出SpriteFont对象：
contentBuilder.Add(fileName,
"SomeFont",
null,
"FontDescriptionProcessor");
// ...
contentManager.Load
("SomeFont");
官方源码包里的文档写的很全面，基本能想到的问题都交待了，让人比较放心。它这种方式背后是使用了和VS编译content一样的机制，依赖于系统中的MSBuild和XNA Game Studio组件，只能用于PC且效率不高；因此只适用于一些不得不从磁盘独立文件加载且没有除此之外其它实现方式处理的资源，像用在字体上可酌情写个缓存或者使用固定路径创建并永久保存（将来可增量修订的）content来做优化。
这段时间又读了些文字也写了些文字，我一直尽最大的可能想让自己的博客不带一丝的说教感，每次读自己的和别人的文字却发现要做到这一点却不是那么容易的事情。最近总结出来一条新的规则：疑问句、祈使句、没有或省略主语的句子越是少文章的说教感就越是弱。我对这条规则的推理过程就不说了嗯，留给感兴趣的人自己思考，即使你有不同于我的意见，也欢迎提出来。也许只是种感觉吧。若哪天我的文字能用最普通不过的陈述句把别人感染了，或心照不宣，我便欣喜了。
