谈谈小弟最近暗自干些什么勾当（LGame WP版开发进度汇报）

时间过得真快，一转眼又快到农历新年，小弟也很久没在博客露面，趁此机会出没一下，免得被人误解赶潮流“回老家结婚”去了……

其实小弟最近不出现，并不代表着放弃了这个博客，更不代表着这个博客的更新会缓慢下来。相反，小弟最近并非不再活跃，而是一直在暗地里搞阴谋诡计(^^)~话说SVN中的JavaSE与Android版LGame-0.3.3都更新了好几次，文档也偷偷写了一部分，C#版的扩展包也快写完（核心包去年就写完了），C/C++版也完成了将近一半。等到这些都搞定，小弟就有底气在网络上多折腾一阵。

文档中的两张LGame架构草图：

下面，小弟就坡下驴的谈谈LGame的WP版，即C#版本。

其实提到LGame的C#版，不过是一个LGame for XNA的版本，简称为"LFX"（版本号与LGame Java最新版同步，首个版本即LFX-0.3.3）。因为该版本底层封装于XNA，故而不仅可以使用在WP平台，也可以发布到Windows或XBOX360环境当中（算上Mono的话，范围将更广）。

以下为C#版与Java版的差异性声明：

1、C#版并不是Java语法的跨平台版本，而是API级别的架构迁移。因此，虽然与Java版基本架构一致，但细节处差异仍需要自行处理（比如C#版中函数首字母大写，重载方式，常用数据类型，关键字的不同等等）。而后续版本小弟会提供语法转义工具，可以实现Java与C#的语法互换。

2、C#版不具备全部的Android特有API（-_-|||……），但大多数常用Java API，则可以通过该版本提供的JavaRuntime类库进行调用（功能仿造，不用的话没有强制要求，光这点多用了150多KB的代码）。

3、C#版核心包中将不使用任何非默认引入References的支持库，以免生成Windows或XBOX360游戏时出现问题。比如C#版的Store包使用System.Data.Linq实现，而该引用非默认存在，所以保险起见暂时被剔除到核心包之外，以单独包可选方式存在。

PS：关于这点，小弟最近可能将JavaSE版的Store包代码移到此处，用IsolatedStorageFile再做一个文本存储的实现，而后让两种实现自动匹配。即环境允许使用DataContext时则使用，不能时采取纯文本操作，这样就不必外置了。不过，与Android版相比有一个进步，那就是C#版核心包中直接内置了Box2D接口，而不必调用扩展包(仅限Android版用到的Box2D API，用C#重写了一遍实现)。

4、Android版LGame中默认的屏幕大小为480x320（竖屏则为320x480），而在C#版中被修改为800x480（为了照顾WP模拟器的默认大小与微软菜市场需求），如需移植Android项目，请通过MaxScreen函数进行修订，否则LGame C#版屏幕大小会与直接移植的Android版屏幕大小出现差异（事实上，由于目前示例皆移植自Android版，所以移植的示例运行时画面全部使用了缩放，也就是设定了MaxScreen(480,320)）。

5、C#版中将不具备任何GLES接口（这个，是微软的东西……），在GLEx类中也将不能如Android版返回GL10或GL11的调用，而只能返回GraphicsDevice与SpriteBatch（不过，依旧仿制有常用OpenGL接口）。

6、事实上，使用LGame的C#版绝不意味着放弃XNA，因为C#版的执行类LFXPlus即Game的子类，它的API中已包含有LGame Android版的LGameAndroid2DActivity与XNA的Microsoft.Xna.Framework.Game类的全部函数，完全可以在其中进行正常的XNA操作，且能与标准LGame操作之间自由切换(C#版提供有一个特殊的XNAGame类，API和标准XNA的Game类一比一，可以同切换Screen一样直接切换该类)。

7、受环境限制，C#版在配置上会比Android版更麻烦一点，因此在C#版中新增了一个Android没有的XNAConfig类，用以通过预配置资源的方式简化流程，以求更简便的管理诸如spritefont等资源文件的切换，具体等正式发布时会细说。

C#版初始类代码结构如下图所示（因为LFXPlus是Game的子类，所以继承LFXPlus就等于继承Game）：

C#版Screen结构如下图所示：

实际游戏运行画面如下图所示（AVG模块运行）：

WP中最让人郁闷的地方在于，封闭空间的特性，逼得人只能将额外资源放入网络或者XAP文件中（编译WP项目生成的文件即XAP，如同Android的APK），但设定上又比Android或iOS麻烦，因为WP环境下模拟器动不动就弹“System.MethodAccessException”（更准确的讲，是常规资源加载方式至少在模拟器层面都会弹出这个异常，也就是正常加载的路被微软堵死了，逼着人用Content.Load方式，但这货又不支持文本和压缩文件等|||）很多资源加载方式根本不能用，虽然很可能是模拟器的权限问题，但小弟对此又不放心（不敢肯定微软究竟有什么阴谋……），目前只好先按照最低环境走，LGame将只支持声明好的资源文件数据流加载.

也就是说，C#版LGame必须先手动声明资源的编译类型（即加载非Content.Load支持的，诸如Texture，SpriteFont，Model等类型之外的资源时），才能正常加载数据（包括上图中出现的def.loon文件）。

具体的讲，LGame的数据流加载支持"Build Action"设定为Content或Resource模式构建的资源，不过有两点需要注意：

一，如果资源类型设定为Content，则Copy Output directory不能是Do not copy，否则不能将资源打包到编译产生的XAP。

二，如果资源类型设定为Resource，则必须引入了System.Windows支持（标准WP应用，标准Silverlight应用，乃至Silverlight与XNA混合应用都默认加载了这个支持库，唯独标准XNA默认没有此支持库，才吓得小弟默认情况下不敢往dll存资源，生怕跨平台会出问题，不然根本不必额外配置资源部署），否则不能读取dll中文件。

三，如果直接向自动生成的Content项目拖拽或添加非标准文件（向没用过WP的同志说明一下，这货是创建基于XNA的WP项目时微软自动生成的，专门用来存资源），则编译可能无法正常进行(WP默认的Content工程只能引入如下图几种管道支持的文件，不得不说，WP在权限这点上简直被塞班附体了)。所以，上述操作建议在主体工程进行。

PS：但是，如果以Content模式运行资源编译，目录又与Content文件夹一致（即在主体工程新建个"Content"文件夹，再往下面放资源），打包后的文件目录同样会在默认的Content目录下，运行时也不会有任何特殊情况发生，不知道微软限制个什么意思|||。

附带一提，微软的XAP包本身不过是一个标准的不能再标准的Zip文件，解压后是含dll在内的全部游戏资源，用Reflector反编译dll，产生的源码足以直接生成原始工程。亲测了几个比较热门的WP游戏与应用，稍微配置下都能直接运行……不是小弟拿微软说事，单论代码安全性，XAP简直还不如APK包（好歹反编译出的APK源码很难直接生成可用的Java工程啊~而XAP面对Reflector则一律秒杀成可用C#项目~），哎。

所以，使用WP的话，就请在资源保护上多下点力气吧，否则你每发布一个应用，同时也上传了一个100%的开源工程。

————————————————

说真的，LGame的C#版，应该说今天也能发布，因为核心包已经完全能够在WP环境正常运行（生成Windows游戏也没问题，XBOX360没环境，无法测试，理论上讲无碍）。小弟发这篇博文前，就曾思虑再三要不要今天先放出来再说，不过考虑到有点小问题还没处理好（在SPRG模块上有隐藏Bug，而且新增的RTS模块还没写完），所以暂时还是先不发布了……不过很快就会解决。

实际上，封装XNA做引擎比直接用Java做游戏引擎简单太多（好吧，小弟承认最近语言排行榜C#和C++上升也有小弟一份功劳，在Google查相关资料，多少也会影响点结果）。最近几天会先把C#版彻底搞定，然后就能踏踏实实做C/C++版了。话说Java版和C#版在平台局限性上比较强，同时使用Java、C#、C/C++三种语言也稍微麻烦点，如果想移植更简便，始终要靠C/C++版做全平台支持（LGame的C/C++版渲染核心为SDL的二次封装，跑PSP都没问题（亲测））。

移植开发真的很省事，既不用考虑逻辑问题，又不必考虑算法，只要做代码转义照搬即可，不过到年底小弟垒码率自然下降到平时50%机能，所以拖了很久~