KlayGE游戏引擎

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模型。有兴趣的话仍然可以到这里下载。

网上看到的GPU比较，都是桌面和桌面比，移动和移动比。很多人对此没有概念，总觉得移动的CPU/GPU在性能上也能比肩桌面CPU/GPU。那么就让我们来看看把各家的顶级GPU放在一起比硬指标，是什么样的结果吧。资料来自wikipedia和厂商自家宣传。 计算单元对比 Model Fab (nm) Core Clock rate API Core (MHz) Memory (MHz) NVIDIA GeForce GTX Titan 28 2688 836-993 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 NVIDIA Quadro K6000 28 2880 901.5 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 AMD Fusion APU 8670D 32 384 844-950 1066 D3D 11.0, OpenGL 4.3, OpenCL 1.2 AMD ...

在渲染场景的时候，一般来说分辨率和输出大小，也就是窗口大小相同。但在移动平台上，基本上没机会让你随便切换分辨率，都是只告诉你大小。在这时候，你如果想要用特定的分辨率渲染，就不可避免需要一次放缩。另一个常见的情况是，如果一个平台性能达不到需要的帧速率，也需要渲染较小的图之后，拉伸到指定分辨率。在XBox 360等console平台，有个专门的硬件放缩机制，只要打开就能自动把输入图像拉伸到720p或1080i/p（DX11.2才开始引入这样的机制）。但在PC和移动平台上，这个事情得在引擎里自己完成。所以在post process后端，加一个resizer就成了必然之选。 框架 这个放缩的框架很简单，把窗口大小填充给screen resolution，而渲染的分辨 ...

最近不少朋友提出为何不把KlayGE推到github的问题，原因是目前github只支持git，而我暂时不打算从hg切换到git。我原先觉得，既然有hg-git这样的插件，这件事情技术上应该很容易，直接转就可以了。试验了一下，发现其实还存在一些坑，必须要对付。这里拿空明大牛的salvia的repository为例子，试验从hg转到git。 第一次尝试，直接转换 安装了hg-git之后，建立一个叫做salvia-git的目录，在里面初始化一个git repository。然后在到salvia-hg的目录，直接执行hg push ../salvia-git。结果在执行了很久之后，出现 pushing to ../salvia-git abort: The system cannot find the file specified 以失败告终。 第二次尝试，bare 在初始化git r ...