转载请注明出处为KlayGE游戏引擎,本文的永久链接为http://www.klayge.org/?p=3358

在前几个版本开发的过程中,每次都有一些对工程系统的改进,但也积累了一些问题。在KlayGE 4.8的开发刚刚开始之时,我打算尽量把之前发现的问题解决掉,让以后的开发和使用更为顺利。

改进依赖文件的管理

在上一个版本中,KlayGE的代码库迁移到了git,同时也把第三方库和资源文件等放到独立于代码库的地方,在CMake里下载。但是,原先只是通过文件名来检测是否已经下载过。只要文件存在就不动它。这对一般只下载发行版的用户来说没有问题,但对开发者来说有有点麻烦了。一有新版本的依赖文件,就需要手动删除旧的,并再次执行CMake生成。钱康来就曾在开发4.7的过程中遇到过这个问题。他提议应该用个MD5来校验下载的文件和已经存在磁盘上的文件。但当时我已经没有时间再去修改工程系统了,只能延后到这个版本。论坛上也有几个人提到过由于网络问题,下载下来的文件不全,造成后面的流程总是失败,却很难自动找到原因。这个问题也需要修正。

新工程系统在对依赖文件的管理上,加了一些校验机制,能防止前面提到的那两个问题。首先,每个文件都离线计算一个SHA1校验码,写入CMakeLists里。在CMake下载文件的时候,可以设定期望的SHA1。这是第一重校验,确定下载的文件没有错误。在编译的时候,每个依赖文件都会再次计算一次SHA1,和CMakeLists里的做对比,保证磁盘上的文件是我们所要的。在每次修改依赖文件的时候,都需要在CMakeLists里更新一下该文件的SHA1,通过两次校验,就能保证总是找到了对应的依赖。

对于第三方库,往往需要经过解压才能使用。目前这个地方有个假设,那就是解压后的文件和压缩包一定是对应的。如果修改了解压后的文件,编译系统并没有检测机制能自动重新解压。

迁移到C++11

KlayGE 4.2开始引入C++11的特性,但都是用一个经过包装的版本,以兼容老编译器。随着时间的发展,老编译器越来越少,支持C++11的编译器已经普及。所以现在是个全面升级到C++11的机会。目前开发版本的要求是vc11、g++4.6、clang 3.4。在这个要求下,绝大部分C++11特性可以直接使用,不需要包装。详细请见拥抱C++11,一步一步来(二)(三)

目前还有几个用到的C++11特性,还不是各个编译器都支持。所以仍需要经过#if来选择使用。这些都定义在了KFL/Config.hpp里。

VC里的全程序优化

我第一次使用全程序优化是在VS2005里。当时的情况很不理想,构建速度慢了很多,运行速度却没有明显的提高。所以这10年来我一直都没有启用全程序优化。最近在公司的项目里发现全程序优化实际上已经得到了巨大的改进,所以打算自己也试试看。

经过测试,打开全程序优化后编译速度反提高了一点点(Core的rebuild从86s变成84s)。编译后生成的文件大了不少,相信是因为更多东西可以被跨编译单元内联。执行速度有了大幅度提升。比如DeferredRendering的例子,从160FPS提升到178FPS。原先的瓶颈在场景管理的相交测试计算的调用上,经过内联,这12%的开销几乎没有了。速度也就提上来了。

VC里要求标明禁用warning的理由

在VC的编译选项里,KlayGE很早开始就已经warning当成error。对于第三方库的warning,以及一些无法回避的warning,原先都是简单地用#pragma warning(disable: xxx)来关掉的。但第三方库在发展,很多warning它们都已经修好了,但这个地方没改。

从这个版本开始,每一次禁用一个warning,都需要在注释里写明禁用原因,以便跟踪。在一项一项检查的过程中,我发现绝大部分第三方库的禁用warning可以直接去掉。剩下的现在都已经加上了原因。

未完成:Win10 UWP的支持

Win10 UWP可以让一个程序用于Windows的桌面、平板和手机。如果能支持Win10 UWP,会给开发带来很多便利,不用在维护三个版本了。但目前CMake的UWP支持还没完全完成,所以暂时还用不上。现在也只能等了。