您的位置:首页 > 其它

我对DX11的理解和简化框架与快速游戏制作(续)

2011-10-30 01:31 232 查看

网上关于DX11的文章很多,tut也很容易google到,可有用的就只是些基本的功能性的介绍。其实DX11是紧跟NV的硬件而变的,微软做的就是DEBUG而已(用DX指令或称为语言来和硬件通讯)。至于OGL也做的是同样的工作。微软的范例是基本的功能语言过多的钻研或可能就是浪费生命了,你是跟不上DX的更新节奏的。我做的是打好个基本框架来适应DX、OGL的各种版本的测试包括发布应用,其中也涉及到一个用于的测试游戏范例和一个关卡编辑器。

先来看DX都干什么使的。显卡主要的工作就是显示2D图片和3D内容。它接受的数据类型只有一个“字节”或称为buffer或byte.很多人被包装后的程序弄的无所侍从,去讨论DX和OGL的性能比较之类的。还学习一些很快过时的语法。通过整理可以发现DX数据主要有几大类,1、Buffer类DX9 叫vertex/index;后来又DX10的 constant / struct buffer其实都一个意思buffer等于byte。2、resource类 texture2D/3D/Cube 一样=byte.3、变量类
指的是用户输入的浮点数据也是BYTE。4、运算指令 通过文本形式再经过编译变成机器语言来告诉显卡如何处理这些输入的数据。GSSL、openCL,HLSL和NV的编译器都是干同样的事编译出的机器语言的字节应该是完全相等的,编译后的字节排列标准由硬件厂商制定。

微软的DX输入字节的标准通过打包后的BUffer一次性传入显卡,效能在早期比OGL用CPU逐个输入要高效很多。

所以在我设计程序时就考虑到要做到程序的类型无关性,比如Texture类的制定就只是字节,无论是DX9或DX11都可以读写,存储也是一样,控制大小也很重要,尽量都转化为DDS来存储jpg就直接存了。

Mesh类比较复杂,由于每个模型我都规定了选中属性,所以都有个碰触检查特性。OCTREE我测试下来是最简化的高速的方式,因为模型始终被视为是动态的,测试中我也用CPU Raytrace 详细对比了效能,OCTREE 在单个BOX包含模型面数不多的时候和BSP完全等速的或高于它,当然GRID才是最好,在我以后的GPUraytrace介绍中就有它了。存储也不能一概都存,程序模型就简单的几个点就成。

还有个比不可少的Input类负责识别键盘鼠标输入。

相机,必须有个万能的好用的操作感好的相机部件可以快速查看场景中任何模型的角落。我参考的是MAX的相机。可以快速改造成可奔跳、碰闯的行走模式。

场景类,可以多窗口的快速和windows form (HWND)对接的类。

空间变形。所有应用到的BoundBOX/BoundSphere/BoundFrusm/Plane/Matrx/Vector/Dynamic类都包含其中计算公式也完全脱离dxmesh的类的调用全部自己数学了.

这些基本类都用极其简练的语法描述。为将来有些新想法准备的。翻查过去写的东西应该是种乐趣而不是恶梦。

未来所有的程序几乎都引用上面的类作为基础类。可以输出独立的 C++/C#应用程序。

我个程序都保持了和C#/C++的语言的双关性完全不用从写任何部件就可以在C#中直接使用我的C++的类。我个人更倾向C#它极大的简化了程序的编译时间,和选交通工具一样我选择飞机而不是马车,由于C#中使用的完全是C++的指针,所以在c#环境下可以与c++环境下的运算效能完全相等或更好更稳定。

先罗唆这些。第一次写博客了。是真的第一次了。

下面是我的应用程序的渲染画面。模型使用的SKTCHUP中调入和程序模型这也保证了渲染的无关性,SKP没有渲染功能更别说烘培了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: