翅膀与祈祷怎么做,司马懿之死,回文联大全
玩弄了一把 xna4的开发。
首先说安装，两台笔记本安装顺利。没有完整下载包非常麻烦，我一共安装了6次。。。。。。
家里的台式电脑死活装不上，重装了window7才行，死活想来可能和曾经装过vs2010有关。
测试了一下windows 和 windows phone7 模拟器的开发，做个简单的图形操作，基本上还是dx那组接口，看起来很熟悉，没碰到什么困难。就是在的语法上纠结了半天。说起来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, aspx">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平台上使用了
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Windows Phone 7编程实践—推送通知(剖析推送通知实现架构)
Esri for Window Phone 7（一） 加载BingMap
浅谈ListBox在Windows Phone 7 中的使用
我要评论
网友评论