KlayGE游戏引擎

从Android SDK R17开始，模拟器就支持OpenGL ES 2。如果能让KlayGE在模拟器上跑起来，开发和测试就能方便许多。于是我装了最新的R21和Android 2.1的ARM v7a的镜像，经过几个小时的努力，终于成功执行了一些原来能在Android x86 2.3上跑的简单例子。途中发现了一些小陷阱，这里总结一下。 屏幕宽高 原先我的做法是通过ANativeWindow_lock获得buffer，再拿buffer的width和height。在ICS上，这么做会导致后面eglCreateWindowSurface失败。原因似乎是ANativeWindow_lock之后这个窗口就被连到2D API，那么在eglCreateWindowSurface的时候就会说那个窗口已经被别的API连接了。即便是ANativeWindow_unlockAndPost也没用。解决方法是改成用ANativeW ...

如果选择了一条路，就要走到底。 前天做了第一次用C++11替代Boost的实验，用C++11的组件替换掉了很多Boost组件。这两天进行了第二次实验，对一些不能整个库替代的组件，做一些局部取代的尝试。同时，因为VC11提供了filesystem，我也测试了一下这个。 可以直接替换 Utility的result_of 唯一的区别在于boost::result_of不能作用于成员变量的指针，但KlayGE没用到这个，所以直接替换了。 稍作修改后可以替换 Filesystem MPL的if_ VC11提供了一个基于Filesystem V2的库，而Boost.Filesystem是V3，接口上有略微不同，但不难处理。这里一个额外好处是，原先在Metro下因为一些API的原因，Boost.Filesystem不能编译成功，所有用 ...

长期以来，KlayGE的很多代码都依赖于boost。（这里有个列表）。上次我提到过，随着C++11编译器和库的普及，boost中的很多东西都可以用C++11来代替。我这两天正试着在KFL中做这件事情，以下的过程中总结的经验和教训。当然，这里只涉及到KlayGE使用的boost组件，没使用到的我没做测试。所有这些替换都保证了可以通过宏来切换回boost的实现。 可以直接替换 标记了*的表示需要编译才能使用的boost组件。下同。 Array Chrono * Foreach Regex * System * Static Assert Type Traits Typeof Unordered 这些boost组件都可以直接用C++11的相应组件替换掉。Foreach、Static Assert和Typeof是语言核心提供的，需要写个宏来统 ...

随着KlayGE的发展，逐渐出现了glloader、kfont、MeshMLLib等多个子库。这几个子库原本是完全独立的，但这样难免出现很多重复代码。受到Salvia的eflib和MFC的启发，在KlayGE的开发版本中加入了称为KlayGE Foundation Library的公共库，简称KFL。（不能叫KFC了，这个名字满大街都是） KFL包括了一些平台/编译器检测的宏、类型定义、数学库、线程、Log记录、XML读写等常用代码，能用极大地减少几个子库之间的重复，减轻维护和开发的负担。KFL不依赖于KlayGE的其他任何部分，所以甚至别的项目也可以利用到它。 KFL目前存在于开发版本中，将会随着KlayGE 4.3一起发布。

经过多名成员几个月的努力，KlayGE 4.2在上周顺利发布！和上一个版本相同，在KlayGE 4.2的开发过程中，已经把一些ticket规划入KlayGE 4.3，并在十二月中旬已经提前进入了开发阶段。 时间线 这里列出几个重要的时间点，以供进度参考。 2013年5月31日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2013年6月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2013年6月30日，release：正式发布KlayGE 4.3。 必然出现 这些特性一定会出现在KlayGE 4.3中。其中有些需求来自于KlayMark。 Script plugin LEAN mapping Build by official Android NDK Improved deferred rend ...

时间过得真快，离上一次讨论编译期字符串Hash已经差不多2年了。上次的尝试失败了，只能产生优化期常量，没有做到编译期常量的效果。现在有了C++11，情况会不会有所改变呢？ constexpr 上次的帖子中，在回复mtlung的时候，我提到了C++0x的constexpr可能会成为救星。现在C++11的标准出来了，GCC 4.6+和Clang 3.1+也开始支持constexpr了。首先尝试宏的做法，代码和上次几乎相同： constexpr inline size_t HASH_FUNCTION(size_t seed, char ch) { return seed ^ (ch + 0x9e3779b9 + (seed << 6) + (seed >> 2)); } #define HASH_RECURSE_00(seed, str) (*(str + 1) == 0 ? HASH_FUNCTION((seed), *(str)) : HASH_RECUR ...

[zh] 经过KlayGE团队的努力，今天KlayGE 4.2正式发布了！这个版本不但提升了速度，提高了效果，还增强了工具链。KlayGE 4.2的主要更新如下： 一个新的子项目MeshML library 实验性支持WinRT平台 体积光（由王清源完成） 改进的DoF，并支持Bokeh 贴花渲染 JudaTex打包工具（由Honyeung Lau完成） 工具集增强 摄像机路径功能（王毅和胡勤协助完成） 多视口支持 优化的顶点结构 全方向SSR 更好地支持compute shader 改进的Juda texture GPU排序 KlayGE 4.2仍然使用双协议：开放源代码的GPL和封闭的KlayGE Proprietary License（KPL）。详细情况请见Licensing。 从此处下载KlayGE 4.2。祝大家新年快乐！ ...

Surface的GPU是Tegra3，但它对应的D3D能力，在网上却很难查到。昨天我自己在Surface上执行了一下Windows Kits 8带的ARM版dxcapsviewer，dump出了这个文件。我已经去掉了Microsoft Basic Renderer Driver和WARP这两个和PC上相同的部分，就剩下Tegra3本身的。 从这个列表可以看出，Surface只能支持D3D_FEATURE_LEVEL_9_1。估计是因为Tegra3不支持完整的occlusion query，以及最大纹理只支持到了2048，必须放弃9_2和9_3。很可惜的是MRT的功能也因此被禁用了。

上次对各编译器对C++11的支持比较之后，很多观众提议加入Intel C++ Compiler（ICC）和Clang。这次修订还加入了在VC11 Nov 12 CTP中对C++11的提升。上回表中的Yes/No标识也被我改成了写明支持一个feature的最低版本号，feature的顺序也调整了一下。为了方便查询，还加入了Proposal的链接。 C++11 Core Language Features Language Feature Proposal MSVC GCC ICC Clang 替代方案 Rvalue references N2118 10.0 4.3 12.0 2.9 Boost.Move     Rvalue references for *this N2439 No No No 2.9 Initialization of class objects by rvalues N1610 9.0 4.3 11.1 2.9 Non-static data membe ...

昨晚在升级了Intel和NV的显卡驱动之后，突然发现原先在程序中启用Optimus的NvOptimusEnablement失效了。及时回滚到老的驱动，仍无法解决问题。试了多种方法之后，最终发现在NV Control Panel的Manage 3D Settings里面点一下Restore，即便在UI上看不出什么，但NvOptimusEnablement恢复了作用！之前尝试失败的朋友不妨也用这个方法试试看。