Silverlight.XNA(C#)跨平台3D游戏研发手记：(七)向Windows Phone移植之双向交互
继完成游戏主体框架搭建后，接下来我将通过SL.XNA模式中Silverlight控件与XNA对象之间双向交互操作的例子，向大家进一步讲解框架的拓展使用及简单的承载演示。在此之前大家需要理解Windows Phone移动设备与传统桌面设备在操作方面的差异。
直观上看，桌面应用大多使用鼠标加键盘的操作方式：鼠标左键、中键、右键，包括单击(按下、放开)、双击以及滑动、拖动、滚动等；而Windows Phone的操作方式则以触控加虚拟键盘为主：按下、放开、按住滑动、各种(多指)手势等；当然，也可以实现像NDS那样通过麦克风实现语音与游戏的交互。而Windows Phone游戏开发中则触摸以为主要输入方式，下面我将分开讲解各种触控操作在Windows Phone中的代码实现。
一、XNA中的触控操作
在此之前，很有必要向新手朋友们简要阐述一下XNA的运行机制：XNA是通过传统的轮询(循环)方式呈现游戏的，即每秒钟对游戏逻辑进行N次数据更新(Update)并将对象重新绘制到屏幕上(Draw),这个频率N在代码中的设定为timer.UpdateInterval =TimeSpan.FromTicks(333333);即30fps(30帧每秒)。
举个例子：假如我们想让一名战士从(0,0)坐标向(300,300)坐标移动，若该战士的移动速度系数Speed=5，那么我们只需在Update()方法中让他的位置属性(X,Y)分别加上Speed(X+Speed,Y+Speed)，于是两秒钟后战士将到达目的地(X+2*5*30，Y+2*5*30)=(300,300)。根据前面所述游戏循环机制，每执行Update数据一次，屏幕就会擦除掉之前的画面然后重新Draw新的画面，于是在这两秒钟内，战士的位置会发生2*30=60次变化，依次为(0,0),(5,5),(10,10),(15,15)……(295,295),(300,300)。短短2秒钟的时间里战士位置连续变化了60次，游戏屏幕好比黑板一样，擦了60次，又画了60次，由于频率很高，好比电视欺骗人眼球同样原理，呈现的是一种连续的动态效果，最终便形成了游戏意义上的“战士移动”动画。
由此我们可以明确：XNA中无论编写什么都必须基于循环，因此XNA模式中无论是低级触控(按下、放开、按住滑动)还是高级(路由)手势，都得放在游戏循环（Update）中进行时时的监测(轮询式)：
XNA 触控
如果还不能理解XNA的游戏循环原理，大家不妨将游戏循环频率设定为每3秒/次，再进一步测试XNA中触控操作，是否发现了什么？
二、Silverlight控件的触控操作
如果你是一位Silverlight(Web)开发者，你会发现Windows Phone中的Silverlight控件相当给力(以Image控件为例)：
图中所有框住的事件均为路由触控事件，且慢，居然还有Mouse……事件，刹那间泪崩了，这不是BUG，我反正信了。就如智能感知提示的那样：Mouse这一系列事件是“触笔的笔尖接触屏幕”时发生的，类比桌面鼠标事件。而其余紫色框住的部分则为Windows Phone专有触控事件，其中Tap、DoubleTap、Hold和XNA中的一致，剩下的手势则可通过3个Manipulation连锁事件自由实现，灵活度相当高。此时或有有朋友会问：同样是路由的MouseLeftButtonDown和Tap到底有何区别？不妨拿起你手中的Windows Phone测试一下不就知道啦^ ^
当然，Silverlight同样也拥有类似XNA中的非路由低级触控。于是我将以上关于XNA与Silverlight的触控操作进行最终整合，以代码的形式封装成一个名为InputHandler（输入处理器)的类，内置了Silverlight与XNA的所有触控操作(注意了，如果使用该类中的XNA模式触控必须将MonitorTouch()和MonitorGestures()两个方法放置于主循环的Update()中方能起效)：
InputHandler
最后经过反复的对比测试，得出以下结论：Silverlight模式在触控方面与XNA最大优势在于：Silverlight的触控是基于事件驱动的(触发式)，是同步的。显而易见，针对低级触控操作，Silverlight模式性能更高；相对于具体控件，Silverlight触控事件效率更高，使用更方便；总体来说，不论是精确度、灵活度还是开发效率和维护效率，Silverlight触控模式都明显优于XNA模式。
因此，这也是为什么微软会在WP7.1开始重点推出SL.XNA模式的主要原因了：SL负责游戏的UI部分，而XNA则负责绘制游戏对象，分工明确，效率与性能兼具。
为了精确论证以上观点的完美可执行性，我特意编写了一个SL控件与XNA精灵交互的Demo：
如上图，不仅有2D精灵，也有3D骨骼动画模型；有Silverlight按钮(UI)，也有XNA按钮(UI)；所有对象均同屏显示，且可相互操作(封装了一个名为UIHandler的UI管理类，详见本文结尾处源码)。以最左边“SL控件+XNA 2D精灵”的“转向”交互为例，首先我们赋予XNA精灵一个Direction属性：
/// 获取或设置朝向
/// </summary>
public virtualDirectionsDirection{ get; set;}
当点击“转向”Button时，触发Click事件修改该精灵的Direction属性：
intdirection=( int)role1.Direction+ 1;
role1.Direction=direction> 3? 0:(Directions)direction;
};
同时，该精灵的Direction属性新值重新反馈给Silverlight的TextBlock控件并显示出来:
由此便完成了SL -> XNA –> SL这样一个双向交互的演示。从该案例中大家是否体会到了Silvelight UI和XNA Sprite之间的亲密无间？当然了，SL与XNA 3D对象的交互也同样方便快捷（详见源码），不过需要注意一点，在绘制模型代码段中必须加入以下三句话方能正常显示(否则会出现因与SpriteBatch混合作用而导致的贴图呈现部分透明状态)：
foreach(ModelMeshmesh incurrentModel.Meshes){
foreach(SkinnedEffecteffect inmesh.Effects){
......
effect.GraphicsDevice.DepthStencilState=DepthStencilState.Default;
effect.GraphicsDevice.SamplerStates[ 0]=SamplerState.PointClamp;
......
}
}
至于纯XNA界面与XNA精灵的交互例子我就不再多说了，开发过XNA的朋友都清楚，需要将UI绘制出来后时时判断触控点与各UI间的位置关系最终做出判断，代码量大，编码繁琐；总之XNA做UI吃力不讨好，巨蛋痛，真的。
结尾，我认为很有必要提醒大家一下关于游戏开发中使用非常广泛的Point结构体和Math数学库。WPF/Silverlight/XNA中的Point设计各不相同，移植时需特别注意；System.Math和Microsoft.Xna.Framework.MathHelper针对的领域各不相同，前者在三角函数方面更全面(double)，如正弦、余弦、正切、余切等；而后者则主要针对float类型的计算，比如弧度和角度之间的换算等常用的静态方法。
OK，至此我们摸透了SL.XNA中各元素的操控原理与实现，下一节我将对第5节的Demo进行移植，进而向大家展示该框架强而有力的实用性，敬请关注。
本节源码下载地址：SLXnaGame2.zip
手记小结：SL.XNA模式乃集大成者，无论开发2D或是3D游戏，Silverlight负责制作UI高效且便捷，XNA则专业绘制高性能精灵与模型，分工明确，结构合理，互利互补。掌握好SL.XNA开发模式，深刻透析游戏结构布局，分工合作处理好游戏各环节逻辑关系，游戏整体“效率”与“性能”必将最大化。