KlayGE游戏引擎

[zh] 又到了KlayGE的发布周期。今天，KlayGE 4.7正式发布了！在这个版本的开发中，有一些功能是由团队成员完成的，同时也有很多朋友提供了宝贵的建议和bug报告，在此表示感谢。由于开发设备的限制，难免有一些测试不足的情况，尽请见谅。KlayGE 4.7的主要更新如下： 引擎方面的改进 MacOSX成为完整的开发平台。上一个版本还需要在Windows上编译shader。这个版本可以独立在MacOSX上进行开发。（由钱康来完成） Transient Buffer。高效的GPU buffer管理，用来加速UI和文字渲染。（由林胜华完成） 硬件检测。支持引擎内的硬件检测能力，检测主板、内存的型号和频率等信息。（由裴博翔完成） 自动测试框架。引入一个单元测试的框架 ...

这几年Intel和AMD都推出了集成GPU的消费级CPU，并强调它们的内存是共享的架构，也就是UMA（Unified Memory Architeture）。最近AMD和NVIDIA的独立显卡也加入战团，开始逐步支持UMA。最新的D3D12直接内置了UMA的支持，开发者可以让自己的程序充分利用上UMA所带来的优势。那么UMA能带来什么好处？它的限制在哪里？ 各种平台的状况 自从PC上第一块GPU，NVIDIA Geforce 256问世以来，GPU一直都是自带一块显存的。当年的AGP总线是非对称的设计，数据传到GPU要远快于从GPU读回。CPU和GPU的访存是完全分开的。后来的PCIE总线让两端传输的速度相等了，并提供了一些相互访问的能力。在驱动里，system memory的区域可以映射成可以被GPU访问的，反过来 ...

在游戏引擎里，每一帧都可能有UI和文字的渲染。这些东西的特点是，琐碎，随机，但每一部分的数据量很小。比如UI由很多矩形块组成，每个只有4个顶点。这样的数据对GPU来说是很头疼的。所以引擎往往需要在Buffer上做一些工作来改善渲染的性能。 由于在目前常见的架构上，CPU和GPU不能同时读写一块内存，CPU在写入数据的时候GPU只能读取另一个地方来渲染。所以一定需要某个机制，来避免这样的冲突。 常见方法1：Discard 最古老的一个做法就是，自己维护一块内存，每一次需要画东西的时候先放在那块内存中。每一帧用一次discard的方式对GPU buffer做一次map，把数据拷贝进去。这么做很简单，所有复杂的同步都交给驱动去完成。 在内部，di ...

自从去年GDC释出了一些消息以来，D3D12 SDK终于在上个月底随着VS2015RC公开了。除了API的更新，D3D12还包含了一个称为11on12的库，让移植前所未有的快捷。目前KlayGE的D3D12插件正在开发中，本系列文章将会把一些方法和经验总结出来。简单起见，后续的代码省略了错误检查等细节。同时，阅读本系列的前提是对D3D11有基本的了解。 D3D移植的过去 纵观D3D的历史，几乎每个版本都是从新开发，和旧版本没有接口上的继承关系。也就是说，和一般COM组件的概念不同，不能从新版本的接口QueryInterface出老版本的接口。结果就是，每次需要移植到新的D3D版本，都会需要拷贝代码、修改代码，甚至重写。在整个渲染部分都换到新API之前，系统完全无法工 ...

Singleton是一个非常常用的设计模式。几乎所有稍大的程序都会用到它。所以构建一个线程安全，并且高效的singleton很重要。既然要讨论这个主题，我们就先来定义一下我们的需求： Lazy initialization。只有在第一次使用的时候才需要初始化出一个singleton对象。这使得程序不需要考虑过多顺序耦合的情况。同时也避免了启动时初始化太多不知道什么时候才会用到的东西。 线程安全。多个线程有可能同时调用singleton。如果只需要单线程，那实在没什么需要讨论的。 高效。因为singleton会被反复调用，如果效率低的话浪费太大了。 通用。适合现有的各种平台，以及未来可能出现的平台。 有了这些需求，我们就可以开始讨论如何构造这么一 ...

上个月底，KlayGE已经基本完成了迁移git的任务。这个过程不是一个简单的镜像，而是在导入git的过程中，删除大文件、依赖库等，并可以通过cmake下载、解压和打补丁。对开发者来说，流程上没有什么变化，都是自动完成的。 对于第三方库，之前的做法是从原网站下载发行版代码包，从klayge.org下载补丁，用python patch打上补丁之后使用。对于有些下载速度特别慢的包，比如wpftoolkit，我也放到了klayge.org。同时，KlayGE所要的资源文件也都在klayge.org。这么以来，最近klayge.org的流量激增，本来速度就一般，现在响应更慢了。 第二个缺点是浪费。比如boost，下载包56M，解压后400M，删掉不用的文件，剩下36M我们需要的。这样对带宽和构 ...

KlayGE在2012年就启用了C++11的部分功能。但目前为止所有用到的C++11特性都要求有一个对应的C++98替代品。要么自己实现，要么用Boost的。 随着时间的推移，各个编译器对C++11的支持越来越好。KlayGE支持的所有平台上，都已经有可用的C++11编译器。实际上如果用的编译器是g++或者clang，-std=c++11都是打开的。所以其实只有Windows上的vc9/10还不能很好地支持C++11。 因为vc9已经无法编译boost，留着没啥意义。对于g++ 4.3之前的版本，或者clang 3.0之前的版本，也没什么人用，也没必要留着。这样在KlayGE支持的编译器中，不支持C++11的就剩下vc10。但至少这样就能直接使用vc10所支持的C++11特性。 所以我的计划是，在目前的开发版本 ...

经过越来越多的测试，在Windows上DXBC2GLSL已经可以取代Cg成为主要的shader编译工具了。由于DXBC2GLSL需要用d3dcompiler把HLSL编译成DXBC，在非Windows上，原先就只能仍然使用Cg来做HLSL到GLSL的转换。 后Cg时代 且不说Cg那差的要死的GLSL支持度，不久前NVIDIA宣布停止Cg的开发和维护，继续用Cg肯定不是个办法。那么在非Windows上编译HLSL就有几个选择： 开发一个自己的跨平台HLSL编译器。 用wine的HLSL编译器。 用wine载入d3dcompiler。 UE4用了第一个选择，但它需要花费的时间精力实在太大了，对于KlayGE来说不合算。第二个选择按说是最佳方法。Wine致力于实现可以在Linux上执行Windows原生程序的抽象层，其中包含了d3dcompil ...

从今天开始，KlayGE的源代码已经可以通过git来访问了。以后的更新也会都通过git进行，旧的hg访问会逐步删除。整个迁移的过程还算比较顺利的。最终经过精简的git库有90M左右，比原先需要下载576.8M的hg库小得多了，虽然精简过的hg库才16M。 新的地址 新的git地址可以在这里找到。国内访问github的速度应该会高于sourceforge或者bitbucket。 转移过程中遇到的问题 上一篇文章里记录了精简hg的方法。精简过的hg可以用TortoiseHg内置的hg-git转成git库。和从hg导入git的方法和坑的实验不一样的是，现在的hg-git可以直接在命令行下推到一个bare库，不需要经过bash。所以这个过程可以直接用一个bat搞定。 尚未解决的问题 目前把新的库推到了g ...

前不久提过关于迁移到git的想法，是时候做一个详细的计划了。为此，我专门在github上启动了一个KlayGE2Git的项目，用于存放迁移过程中需要的脚本。希望对其他也有类似计划的朋友能有所帮助。 需要完成的事情 最终选择的迁移方案是方案4：单一repository，下载外部库发行版。所以在迁移的过程中，需要考虑如何减少repository大小，以及考虑迁移之后工作流需要的改变。 删除当前工作目录的大文件 第一步应该是删除当前工作目录的大文件，主要是二进制资源文件。并且需要在cmake里面加上自动下载的脚本，以便在配置工程的时候可以从klayge.org上获取需要的文件。否则后面开发的时候会有问题。这一步已经完成，目前的hg上已经没有资源文件。 ...