今天小弟暂时脱离闭关状态，更新了一下LGame的SVN，更新的文件为：LGame-0.3.3-Beta(20120229).7z
所以特意上博客说一小声，是因为这次更新小弟偷偷在SVN中增加了LGame-0.3.3的C# Beta版本(支持Windows、XBOX、WP7等环境，如果算上Mono的存在，微调下代码也能跑Mac（MonoDevelop）、 iOS（MonoTouch）、Android（（MonoDroid））等等等等(刚才看了一下，Mono支持的手机很多啊)，不过这些需要额外花点 ￥(是Mono收的，不是偶……))。
从今天开始，LGame对外就有C#版了（其实早就有，就是没发……）。
本来小弟预期在2月发0.3.3正式版，结果有些事耽误了开发，进度比预计
中的慢。C#版虽然已经构建完毕，但以前许下的RTS模块还没写完（Java版和C#版的都没写完，从去年动笔到临近写完，到今天几乎没再添加代码，果然
自己不是一般的懒），而原来Java版的例子，除AVG和SRPG的以外，也都尚未移植到C#版本，至于文档就更别提了|||。所以，小弟本着“虱子多了
不咬，债多了不愁”的无产阶级大无畏精神，稍微改变下开发计划，现阶段依旧慢慢在SVN中更新0.3.3的Beta版，正式版等C/C++和HTML5版
本写完后，连皮带瓤四版一块发。
所以今天绝对不算正式发布，小弟只是慢慢走过来，用低沉鬼祟的嗓音悄悄招呼一声：“增加了C#支持的LGame-0.3.3-Beta已被上传”。这个，最多算跳票跳一半吧-_-
目前发布到SVN中的只有核心包dll与源码，以及附带2500个常用汉字字库的空项目模板（Hello
World），其它辅助包还得测试下，过两天调好再补到SVN当中。另外，例子暂时并没有上传，小弟准备等补全后一起发SVN（其实照搬Java版的
API就是了，除照顾C#用户情绪首字母大写外，真的一样（要求首字母大写，首先是保证C#中变量和函数重名时，编译不报错的需要。另外还有一个好处，就
是以后写脚本转换，将其它语法与C#互换时比较方便，统一处理即可）；况且小弟也增加了不少C#仿Java的函数）。
其实，就算大家不用LGame，有想研究C#游戏或引擎开发的，或者有需要将Java代码移植到C#的，也多少可以参考下小弟上传的源码，仅就2D开发而
言，就算目前发的是Beta版，也比看书或借鉴别的什么项目强太多了。希望小弟开头以后，国内原创的C#游戏和游戏引擎也能多起来，总山寨国外的到底不是
办法，否则老外真以为中国没活人了(话说把一些自己都不知道什么意义的代码照翻过来，真的很无聊，特别某些人还专喜欢照抄冗余的部分，显得代码深奥吗？
喂，这可是C#啊，某些从别的语言带来的啰嗦语法，能免则免吧……)。
预计4-5月之间小弟会将C/C++版（首个版本只保证支持Windows、Mac、iOS以及PSP运行，其他环境不敢保证，微调下可能能跑，也可能不 行|||不过会陆续扩展，反正是SDL的底子，好办~（简化了，只有部分需要的代码）），还有HTML5版发布，也就是LGame的0.3.3版这时才正 式公开。
PS:Java、C#、C/C++、HTML5(JavaScript)这四种基础版本搞定后，小弟无论如何也得组团，否则自行发展四种不同语法的版本几乎不可能，主要是这四者的可运行环境存在重复，反复调试耗时甚巨，个人无法承受~
而后，我会给C/C++版添加额外的语法支持（纯解释器方式，非虚拟机，不过我会让脚本能编译成一些足以糊弄苹果的东西，合理规避审核），初步考虑支持 Java和C#语法（语法特性只准备支持到JDK1.4以及.Net2.0，更高版本特性暂不提供），除此之外，也考虑在Ruby以及Python中再抉 择其一做语法支持，还没最后定下（另外有时间的话，小弟还想玩点新鲜的，实验下多语法混合使用）。估计这些写完至少得7，8月见，这个版本会是 0.3.4。
接着小弟准备翻回头来，替Java版增加JavaFX支持，给C#版增加Silverlight支持，这俩货倒简单，争取一个半月搞定(虽然有可能变成
“临终关怀”)。至此小弟就可以开始写可视化IDE了，总之尽量简化开发流程。把上述这些全部做完后，我将顺应国内潮流，走最阴险也是最大众化的一步，广
招技术水军强推-_-（话说在我国最大最公开的技术枪文发布“村”，小弟也是认识几个人的。另外还可以弄些Free的游戏，刷几个月搞几百万几千万下载量
之类）……
当然，一些功能扩展与优化，会混杂在这个过程中一起完成。
——————————————————
关于C#版和Java版的三点小差异：
一、屏幕大小
其实小弟以前也提过，C#版与Java版将存在屏幕默认大小的差异。
Java版LGame的屏幕大小默认为480x320(横屏。话说这个大小省图，所以定成了这样)，而C#版则为800x480(微软菜市场强制要求)。 假设都使用默认设置，那么直接移植Java版游戏到C#版时，就需要额外设置MaxScreen大小，才能让C#版的LGame自动缩放为Java版的屏 幕比例。
比如，我们将Java版本AVG示例的开始界面，毫无设定的直接运行在C#版中，会得到这样的效果。
因为原始设定是按照480x320跑的，而实际画面大小却是800x480，所以肯定会产生出入。
其实只要加入MaxScreen(480,320)这一行设定后，就会变成这样(从LGame的log数据也能看出差异)。
这时的效果与Java版如出一辙(当然，如果一开始就需要800x480的屏幕，或者希望根据屏幕大小产生效果差异，就什么都不用改了)。
另外，如果有一些屏幕先天不足或大于800x480的游戏需要移植，也可以通过此方法进行自动缩放，这在LGame的所有版本中都通用。
二、手柄支持
C#版在默认条件下，除Windows与WP7外，也可以运行在XBOX之上；不过，XBOX一般却都使用手柄，而非鼠标或触屏之类进行游戏，因此在游戏开发时需要额外引入手柄控制。
目前LGame的C#版提供了GamePadListener接口（只有它和PSP版有），其中已包含有全部XBOX游戏手柄的事件监听，我们只要实现这 个接口，并且通过Screen的AddGamePadListener函数添加相关监听（监听可以Add多个），就可以获得具体的手柄数据，进而操作游戏 了。
三、使用Content项目以外的资源
XNA默认使用管线技术（一种大家都知道怎么解密的混淆器……），将Content项目中的资源编译为xnb文件供用户加载。但是，C#默认提供的 Pipeline实现却并不多，无法满足全部的资源加载需求（而且用Mono的话，这项功能就废了。所以个人认为，自行实现Pipeline其实挺没 用）。因此，为了加载处理一些特殊类型的文件，我们有时将不能使用系统默认生成的xnb（所有能通过ContentManager的Load函数加载的资 源，都是这个后缀，只是系统默认屏蔽后缀罢了），而需要让资源文件保留原始格式。
这时，我们就要在VS中自行设置资源文件的格式了。而想获得非xnb格式的资源，需要满足下列两个条件。
1、文件不能位于XNA自动生成的Content项目中，否则要么被编译成xnb格式，要么系统报错打包失败。（这意味着，通常我们需要在游戏源码所在项目，Add一个新Folder）
2、在这个Folder中的资源，必须手动设置属性下Build Action项为Content或Resource（读Resource仅限LGame，而且需要已引入 System.Windows.Application支持），并且Copy to output项，不能为Do not copy，否则VS也不会将它们打包进XAP这个WP7应用包（LGame中有个省力的办法，用LPKUtils混淆全部资源，然后加载单独lpk包即 可。当然，一个个加也无所谓，毕竟属性可以批量设置）。
PS：顺带一提，如.spritefont之类文件在生成xnb后，我们就可以把.spritefont这种配置文件删掉了，以后直接解压xap把生成的 xnb拿出来用就行（本文再重复一次，xap这货其实就是个zip），反正真正打包时系统只认xnb文件而完全不需要.spritefont。否则你做中 文字体，一个完整字库少说得编译一、二分钟（两万多个汉字，将生成十几MB的xnb文件，偶都是写批处理挑字生成，几MB足矣），纯属浪费时间。
——————————————————————————————————
原本预计明天多写点东西才发，小弟刚刚却赫然发现，这个月居然只有29天（一直以为本月有30天）。今天不发就是彻底的跳票，所以先将C#版的核心源码上
传了。过两天例子都移植完时，小弟还会偷偷过来谈谈更具体的开发事宜（小弟偷偷的来，偷偷的走，打枪的不要，声张的没有，其它等“基础四版”构建完后再
说）。
都说跨平台是趋势，其实单纯的跨平台之类真是弱爆了，小弟今年准备呕血跨语法跨机种跨系统外加跨平台，额外支持多语法混合编程，附赠可视化游戏拖拽生成工具的（旁白：此人已疯，速打999）
