KlayGE游戏引擎

随着工程代码量越来越大，pdb的尺寸也会一直增长。比如KlayGE核心没多大，但pdb已经到了73.7M。一个偶然的机会让我发现了vc的link一直以来都有个undocument的选项/pdbcompress。加上之后可以在生成pdb的时候自动打开NTFS的压缩。 由于pdb里面大量内容都是文本信息，即便是NTFS的压缩都可以得到比较高的压缩比。经常可以压到剩下1/3的大小。NTFS压缩的算法比较简单，压缩和解压的的速度也不错。所以在生成和调试的时候，读写速度并不会有很大影响。所以能用这个选项的时候还是尽量使用吧。 话说，这年头还有人不用NTFS吗？

D3D11.1和OpenGL ES都提供了discard frame buffer的方法，分别成为DiscardView和GL_EXT_discard_frame_buffer。虽有文档，但却很少有例子来表达这功能在什么情况下使用。这里我只能根据我的理解做一些探讨。希望有更了解的朋友可以一起讨论。 从tile-based说起 移动平台上最常见的GPU架构是tiled-based。它把frame buffer划分成许多大小相同的tile。每个rasterizer一次处理一个tile，把这个tile中包含的三角形光栅化到那个区域。为了提高性能、减少功耗，tile-based硬件会有一个片上空间，真正的光栅化仅仅发生在这个片上空间，当一个tile的所有三角形都渲染完成之后，才写入位于video memory的frame buffer。可以认为，那个片上空间是个ca ...

几个月前我提到过如果通过IE10或单独装补丁的方法，可以在Win7上获得部分D3D 11.1和DXGI 1.2的能力。代价是，由于debug layer的不同，那么做的话无法用D3D11_CREATE_DEVICE_DEBUG标志建立设备，所以就不能使用调试模式的D3D。Win8.1再次修改了debug layer的名字，使得这个现象在Win8.1上也会出现。如果在Win8.1上使用VS2012及以前的Win SDK，就无法建立debug设备。 Win7上的D3D11.1 从文件日期可以看出，安装了D3D11.1后的Win7，d3d11.dll已经被升级了。原先的debug layer叫做d3d11sdklayers.dll，而在Win8 SDK里有了个d3d11_1sdklayers.dll。新的d3d11.dll会去找那个文件，而不是原先的。如果把Win8 SDK或者VS2012里的d3d11_1sdklayers.dl ...

MinGW-w64是另一组人做的修改版GCC，比起原先的MinGW，它的好处是可以编译出x64和x86的Windows程序，而且对Windows API的支持更好。原先用MinGW编译KlayGE的时候，需要对MinGW的头文件（或者说w32api的头文件）做一些修改，才能完成。如果用MinGW-w64，会不会好些呢？ 版本的选择 和其他第三方的MinGW一样，由于选项的不同，MinGW-w64在Windows上其实有多个不同的版本。C++ Exceptions有DWARF、SJLJ、SEH三种处理方式；GCC Threading Model有Win32和Posix两种实现；编译器本身还分Win32和Win64的，虽然都可以交叉编译出x86和x64的代码。这些方式组合爆炸后，最终的binary版本就眼花缭乱了。我这里测试的是x32-4.8.1-release-win32-sjlj-rev ...

2006年以来， KlayGE一直都是用Variance Shadow Map（VSM）来表达阴影。VSM只比标准shadow map（SSM）增加了几行代码，但却能通过插值，极大减少边缘的锯齿，甚至模拟软阴影的效果。VSM的缺点是，需要抓用两个32F的通道。这么一来，带宽消耗大得多了，并且没办法通过编码到RGBA8的技巧在不支持浮点纹理的设备上使用。另外，VSM的light leak也是很讨厌的毛病，需要仔细调参数才能减轻。 Exponential Shadow Map 实际上在VSM出来不久之后的2008年，就有了Exponential Shadow Map（ESM）的方法。和VSM类似，ESM也是通过巧妙的方法使线性插值成为可能，从而完成各种blur。比较一下SSM、VSM和ESM的生成和使用，就能看出来ESM在代码上比VSM简单， ...

去年我写过两篇博文《在程序中掌控NVIDIA Optimus》和《在程序中掌控NVIDIA Optimus后续》，讲解了如何利用NV提供的导出NvOptimusEnablement的方法，在程序里切换到独立显卡。然后，当我升级到Win 8.1后，发现Optimus有了一些变化。 右键菜单中没有了选择用哪个显卡启动的选项。 不管NvOptimusEnablement设置成什么值，只要导出了NvOptimusEnablement，D3D程序都会用独立显卡来执行。 程序中获取显卡名字的话，能正确地返回NV独立显卡的名字，而不是一味返回Intel集成显卡的名字。 原先我以为是显卡驱动没装好，装了最新的Intel驱动和NV驱动之后，情况照旧。会不会是Win8.1的新功能？查了WDDM 1.3的新特性后，发现还确实是这样的 ...

KlayGE的源代码包里带了包括boost在内的所有第三方库。如果使用完整版的boost，那么大小会吃不消的。因为只用了boost中很少的一部分（列表在这里），以前用的方法是手工删掉了libs和tools等目录下所有不使用子目录，以及帮助文件和例子。通过这样的缩减，已经让boost从356M减少到了96.8M。但是，头文件的目录仍不容易直接删减，因为互相依赖很大。 上周空明流转大牛说他在SALVIA里也遇到了类似的问题，打算用boost自带的bcp工具处理一下。所以我也做了一下测试，用bcp来砍掉所有不用的库： bcp atomic chrono filesystem program_options regex system thread algorithm any array assert assign bind circular_buffer container foreach ...

HDR post process几乎存在于所有PC桌面引擎中，也开始在一些高端移动平台上得到了支持。HDR太常见了，以至于这年头如果看到一个不带HDR的真实感实时渲染，就会觉得很突兀。（比如，在SIGGRAPH展会上，看了Qualcomm的展台，再看ARM和Imagination的，就有一种回到dx8时代的感觉。大部分原因就来自于Mali和PowerVR缺乏很好的HDR。）在这方面，KlayGE的目标是在不同平台上，都能尽量多地复用HDR post process里的组件，同时效果也尽量接近。首先让我们看一张只有LDR的图。 啥都支持的平台 代表的平台有D3D11 level 10+，OpenGL 3+。支持包括B10G11R11F在内的各种浮点纹理。在这样的平台上，KlayGE的HDR流程是这样的。注意红字标出来的数据 ...

前一阵子在把KlayGE的OpenGLES插件升级到OpenGL ES 3的过程中，原先还满怀希望地觉得GLES3总该全面支持浮点纹理的读写了，结果发现GLES3的标准支持float16和float32的读取，但不支持渲染到float16/float32的纹理上。只有支持GL_EXT_color_buffer_float或GL_EXT_color_buffer_half_float扩展的硬件，比如Tegra 4和Adreno 3xx才能很好地支持。所以，在其他设备上如果要渲染到浮点纹理，就得另想办法了。 编码和解码 单通道的float是32-bit，RGBA8也是，所以按说把float编码到RGBA8的纹理中应该没啥问题。很可惜的是，不支持浮点纹理的硬件往往也不支持整数指令和位运算操作。所以在这里需要有些限制。在网上搜了一下，最靠谱的应该是大牛Aras ...

之前放出过两批3D模型，这次继续几个整理好的高质量3D模型。有兴趣的话仍然可以到这里下载。