KlayGE游戏引擎

One step closer 继拥抱C++11，一步一步来第一篇和第二篇之后，develop分支又经过了一次改进。现在，编译KlayGE所需要的编译器提升到了vc11、g++4.6和clang 3.4。相比上一次的vc10和g++4.3这样刚开始支持C++11的编译器来说，11和4.6基本支持了所有的C++11特性。所以代码里面可以比较自由地使用C++11，而代码更简单。 全部支持的特性 目前vc11、g++ 4.6和clang 3.4都支持的C++11特性如下，远多于vc10、g++ 4.3和clang 3.0这个组合。 语言核心部分 Static assertions (N1720) Multi-declarator auto (N1737) Right angle brackets (N1757) auto-typed variables (N1984) Extern templates (N1987) Rvalue references (N2 ...

在上一篇拥抱C++11，一步一步来里，我制订了一个一步步使用C++11的路线图。KlayGE 4.7去掉了早于vc10、g++ 4.3和clang 3.0的编译器支持，但由于时间关系，还没来得及把它们都支持的C++11特性改为默认开启，仍然用了wrapper层。现在，KlayGE 4.8的开发已经开始，也有足够的时间真正地来执行C++11的计划。目前已经在develop分支里做实现了一部分。 全都支持的特性 整理一下vc10、g++ 4.3和clang 3.0都支持的C++11特性，可以得到一个列表： 语言核心部分 Static assertions (N1720) Right angle brackets (N1757) Extern templates (N1987) auto-typed variables (N1984) Rvalue references (N2118) Declared type of an exp ...

在KlayGE 4.7发布之前，4.8其实已经完成了大部分的计划。今天新版本的开发也已经开始，这里公布一些我对KlayGE 4.8的计划，更开发组成员和用户参考。和以前一样，欢迎有兴趣、有时间加入KlayGE 4.8开发阵营的朋友们继续参加。 最近几个版本都是在注重新增一些渲染功能。KlayGE 4.8除了继续保持之外，还会把现有的功能做一些重构和优化，使其更方便使用。同时，移动平台的支持还将继续发展。 时间线 这里列出几个重要的时间点，以供进度参考。 2015年11月30日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2015年12月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2015年12 ...

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

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

上个月底，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上已经没有资源文件。 ...