Windows Phone 7 开发日志(初试一、随便研究)
玩弄了一把 XNA4的开发。
首先说安装,两台笔记本安装顺利。没有完整下载包非常麻烦,我一共安装了6次。。。。。。
家里的台式电脑死活装不上,重装了window7才行,死活想来可能和曾经装过vs2010有关。
测试了一下windows 和 windows phone7 模拟器的开发,做个简单的图形操作,基本上还是Dx那组接口,看起来很熟悉,没碰到什么困难。就是在c#的语法上纠结了半天。说起来c++和c#,#就是把俩+重叠起来而已,着实还是差了不少,虽然曾经系统的学习过一点儿dotnet,年代久远,还是花了不少功夫。
一、关于引用。
1.windows平台和windows phone 7 平台乍一看引用的库差不多,展开一看差了还不是一点儿半点儿,以后要真搞,得随时关注使用windows phone 7 兼容的代码。
2.项目和 content项目,资源管道这东西真是没觉得有什么方便的,可能是被虐待惯了,非要给整个自动化的,反而绑手绑脚的。我就一直在拼命要从外部加载资源,这个有点儿成果了,等下再说。项目里能够引用的库和content里能够引用的库完全不能通用,看来dotnet还是博大精神啊,怎么能产生这样的限制我还没搞懂。于是在XNA4中RunTime处理资源几乎就不可能了,囧。
二、关于资源
看文档使劲介绍资源管道那个架势是让我们都按照这个路数来,增加自己的资源格式得这么跑一遍。我对这个很反感。
PC制作->content项目编译->runtime调用,这种固定下来的模式产生的限制禁锢了我的创意。
贴图、模型、shader,其它自定义格式,我要全面绕开microsoft给设计的这种玩意儿。
模型就是一堆顶点数据,贴图只要能lock表面写入,应该都没有什么问题。
于是我关注了一下Shader,吐血吐了一地,XNA4中找到的和Shader编译有关的模块全都只能在content项目中引用。
runtime编译Effect路完全被堵死了……
于是我用二进制格式打开由fx生成的xnb文件,做了一些分析测试。最起码我现在可以直接载入由fxc编译过的effect文件。
还看到XNA3.1里有一个ShaderCompiler模块可以在RunTime使用,我有时间再测试一下。
三、令人愉悦的地方
快速的移植,pc和windows phone7 上几乎可以用一致的代码。dotnet框架跨平台不是盖得。
对多点触摸的支持,堪称完美,在windows 7上和 我的Tx2z配合很好,多点触摸的接口很好用。而且tx2z在windows phone7 模拟器里也表现出完全一致的行为,在多点触摸调试这个问题上,只要有台支持多点触摸的屏幕,我们就可以忘了这是个问题。
最近HP又出了一台TM2,支持多点触摸,缓一缓在入手一台。
加速器的支持也有了,但在pc上一点用都没有,而且我一直觉得在地铁里用加速器来进行游戏很囧,不过这也是个令人兴奋的特性。
自动翻转屏幕,这个特性我还没测试在XNA里有没有直接的接口,即使没有,用加速器来判断也可以。这个也是不容易调试的功能--p。
比较新的DX,从研究effect的时候发现shader编译器的用的是 D3DCompiler_41 D3DX9_41 ,09年11月的dxsdk里是_42.
关于Effect文件我做的研究记录。
一、fxc 生成的 fx_2_0
通过二进制比较发现XNB里明码将fxc编译的fx_2_0文件直接插入。
二、独特的文件头
public Effect ( GraphicsDevice graphicsDevice, byte[] effectCode )effectcode,没有任何说明,看起来是code,弄个字符串放进去,一个异常给出了答案,需要编译过的code。找到xnb里的编译过的fx_2_0的文件头部,放进去,异常too。这还难不倒我们,嘿嘿。早料到你可能在前面加点儿什么没用的东西,一个一个试过去。for (int a = 0; a < 100; a++)
{
System.IO.Stream s = System.IO.File.Open("content\glow.xnb", System.IO.FileMode.Open);
int n = (int)s.Length;
byte[] b = new byte[n];
s.Seek(a * 4, System.IO.SeekOrigin.Begin);
s.Read(b, 0, n);
// byte[] fg = b + 12;
s.Close();
try
{
e = new Effect(GraphicsDevice, b);
npos = a;
}
catch(Exception)
{
}
}npos=42的时候通过了,多找了一些测试,结论稳定。
前面168是xnb的文件头,只要从168开就是 XNA4中使用的EffectCode格式了。
现在开始搞一些dx的effect文件来用fxc编译,载入测试,不通过。在
xna content 里创建一个默认的effect文件,用fxc编译,加上和xnb里一致的文件头
CF0BF0BC 0C000000 00000000 载入测试,通过。
看来这12个字节还有很多名堂在里面。
又多测试了,得到了更多的情报,首先虽然都是 fx_2_0 但有些fx在XNA content里编译不通过。
ColorOp[0] = SELECTARG2;
提示如下:
Error 1 Errors compiling E:UserslightsDocumentsVisual Studio 2010ProjectsXNAShaderXNAShaderXNAShaderContentGlow.fx:
Error: The effect state 'ColorOp' is obsolete and can no longer be used. E:UserslightsDocumentsVisual Studio 2010ProjectsXNAShaderXNAShaderXNAShaderContentGlow.fx XNAShader我不知道怎么设置fxc才能得到和XNA content里一模一样的编译环境。
总之过了这关单technique 单pass的effect文件用fxc编译过就可以载入了。
但是多个pass时,文件头不一样。。。。。。
CF0BF0BC 是一样的, 0C000000 一个pass 10000000 两个pass 14000000 三个pass
以四递增的,后面的 00000000 随便写什么数据测试无关, 一个pass 4字节 两个pass 8字节 三个pass 12字节
以四递增too。
写一段程序如下:
int passsize = 2;//pass数
{
System.IO.Stream s = System.IO.File.Open("content\glow.fxo", System.IO.FileMode.Open);
int n = (int)s.Length;
int headlen = 8 + passsize * 4;
byte[] b = new byte[n + headlen];
b[0] = 0xCF;
b[1] = 0x0B;
b[2] = 0xF0;
b[3] = 0xBC;
int tag = 0x0C + (passsize-1) * 4;
b[4] = (byte)tag;
s.Read(b, headlen, n);
s.Close();
e2 = new Effect(GraphicsDevice, b);
}
测试了几个情况,均OK,基本掌握了XNA4 Effect runtime载入的问题。
三、为什么要这样
写出结论来看着很简单,用16进制编辑器去分析可不是个愉快的事儿。
我做这个主要是想能够在运行时方便的载入shader,更进一步可以做出ShaderTree,在运行时生成Shader。
现在已经基本解决了载入的问题,剩下就是编译的问题。
现在有最不济的方式,将动态生成的effectcode存入文件,调用fxc编译,再载入。可行,不优雅,依赖windows平台。
还有方案二、写一个库,用XNA3.1编译Effect返回code,我还没测试。windows平台应该有一定的可行性,不知道windows phone7上的XNA会不会保留3.1
方案三、正式版的XNA4 会允许runtime compier effect,等吧,其实微软要是不解决,我们这个ShaderTree也成为技术特色了。
方案四、由于方案二经测试无果。XNA3.1的shaderCompier不包括fx。。。。,所以等XNA正式发布后,可以用c++调用DX来直接编译。不过c++原生代码调用DX估计只能在Windows平台上使用了。