自己写游戏引擎——Get your hands dirty!!! (01)

jiangwei

你统一opengl和directx接口看似很好，但实际上有很多问题，比如你的DWORD    GetFVF() 函数返回的是DWORD类型，而这类型只在win32上定义，如果有人在linux系统下开发，没有相应的头文件这个类型将无法识别，当然，这个问题有很多解决办法，但我只是想说这样的接口不太好，还有一个问题，就是matrix类的问题，如果你为一个数学类比如matrix定义一个抽象接口，使得能将dx和opengl的自带矩阵函数统一封装起来，那么效率是个问题，我们都知道虚函数有相应的效率损失，如果把频繁使用的数学库封装成抽象类，并提供纯虚的函数接口对效率来说是不太现实的，你对这个问题是怎么解决的，想听听你的意见。

xjyhust

恩，这个问题考虑了很久的，关于公共的接口。现在没有考虑跨平台的库，ok.DWORD的问题就暂时不管了。数学类会完全不用抽象的，在引擎的内核里面会有简单，基本的几个数学类，这个方面效率不会比dx或者gl的效率差太多（数学我基本上是抄的ogre的，自己写水平还不到家），尽量用汇编级别的优化。其他的接口，小函数会尽量做成内联的，关于渲染，若不是管理的接口，能够在公共部分实现的，就在公共部分实现，这个时候的效率损失也是难以避免的（但是可以忽略，同渲染的流水线效率相比），其他的有多渲染器的引擎好像也都是这样解决的，我也在想改进的办法。

hlsl

挺好的，lz坚持写完哪

congy

首先 OGRE 的数学库效率并不高，和 d3dx 比起来，自己是几乎写不出来跟它一样的效率的数学库的，这个可以自己测试一下便知，实际上我怀疑 OGRE 的性能不高跟这个是有很大关系的。
如果你不用 cpu 扩展指令集来优化数学库，自己写的 asm 优化代码还不如编译器写得好，但如果你使用了 扩展指令集，就要对不同 cpu 进行分支判断，这种性能开销也不小，目前做得最好的就是 D3DX 数学库，我相信不会有人能做出性能又高，又能做到动态决定使用目标 cpu 指令集的数学库来，大家可以看看 Release 下编译出来的 D3DX 代码。
对于这个问题，我的做法是是封装函数库，但不用 c++ 虚拟机制，这样就不会存在虚函数的调用开销，而是把函数库封装在 static lib 里，封装的类内部调用的是 d3dx 或者是 opengl 的数学函数，并且强制内联。不过这样在不同平台上使用要重新编译，不能做到运行时切换。不过虽然这样，经过测试发现还是有一些效率的损失。

jiangwei

这里存在很大的矛盾，如果要统一接口就必须使用虚函数，而要保证效率就不能使用虚函数，所以我认为在整个引擎接口设计上需要改进，我认为没必要使用统一接口，而是分别提供UHEDirectXEnvioronments大环境和UHEOpenglEnvioronments大环境来分别封装DX(包括D3DX）和OpenGL，因为使用抽象类接口最大的目的就是两个目的：1.方便以后进一步添加相应的功能，进行扩展。2.提供用户统一界面。先讨论第一个目的，这个目的放在这个问题就需要考虑一下了，因为这么多年了，全世界真正被应用的图形库只有两套：DX和OPENGL，并且将来可能很长时间内都是这两套API，所以这就失去了第一个目的 地意义了；再看第二个问题，其实在两个大环境中可以使用统一的界面这个不是问题，并且这样可以解决虚函数效率问题以及大量的downcasting转换问题，并且将来也只可能使用这两套图形库，所以不管你将来怎样扩展你的引擎并不会使接口变得很臃肿，也不用太多的代码重写，但可以带来很多好处。
大家一起来探讨一下。

xjyhust

恩，同意congy和jiangwei的观点，我也是这样想的。
关于虚函数的效率而言，是有一定的损失（不过经常的被夸大），但是经别人测试过发现这种损失也是可以接受的，特别是在游戏引擎中，时间几乎都是花在了渲染上，应该把优化的功夫尽量花在这个上面。
另外，c＋＋中的虚函数效率似乎也有待改进（好像新标准正在研究这个问题），有人测试过，几十级的虚函数运行时解析起来速度竟然比java还要慢（当然是代码水平上的速度，忽略java虚拟层），希望新标准出来以后这一点会得到改善（c＋＋CLI），的确，虚函数和纯虚类是设计的利器。

congy

jiangwei: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

这里存在很大的矛盾，如果要统一接口就必须使用虚函数，而要保证效率就不能使用虚函数，所以我认为在整个引...

能说说你的这种方案的具体实现吗？我没看懂。不统一接口，你的引擎内部与 Renderer 的交互怎么办？除非你说的“大环境”是两套引擎。

congy

其实 Renderer 的抽象已经是图形引擎的工业标准了，现在主流的的商业引擎都是这种方式来实现跨 Graphic 平台的。不过我也见过为不同的 3D API 写两套引擎实现的，比如 Renderware，是我目前接触到的商业引擎中效率最高的。
像 xjyhust 说的，使用 c++ 虚拟机制，在效率上也不会有太大的开销。我觉得对性能的影响还是要看引擎的整体架构设计，是否最小化渲染状态切换，是否合理的组织场景等等，是否最优的资源管理等等，这应该是引擎设计中一开始就要考虑的问题。

congy

jiangwei: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

你统一opengl和directx接口看似很好，但实际上有很多问题，比如你的DWORD    GetFVF() 函数返回的是DWORD类...

对于这个问题，我习惯于定义自己的类型，我会把所有 c++ 基本类型和 windows \ linux 类型都 typedef 成自己的名字，然后创建一个 PlatformConfige.h 来配置， 这样在不同的平台下有不同的定义实现，引擎内部使用自己的类型定义，在不同平台上发布时只要改变一下配置再编译就可以了。

jiangwei

congy: Re: 自己写游戏引擎——Get your hands dirty!!! (01)

其实 Renderer 的抽象已经是图形引擎的工业标准了，现在主流的的商业引擎都是这种方式来实现跨 Graphic 平台...

很好，但你的数学库比如matrix,vector怎么统一，难道不考虑效率而依然使用虚函数吗。