Skip to content

Archive

Archive for July, 2015
昨天晚上,sourceforge的宕机时间刚恢复,我就打算把新的develop和master分支推上去。笔记本上的本地git库是一个改动中的,和github等上的历史结构有些不同了。结果我不小心用了强制push,于是现在github、bitbucket、sourceforge、codeplex上的git库全都被更改了。 7月8号以来pull或者fetch过develop或者master分支的用户,会受到影响。需要用Reset develop/master to this的功能reset到“KlayGE: Rendering: Fix the black screen in WinRT. (ticket #295)”这个commit,SHA-1是1217bcff860130d6d187925cdf342fb0ea11ab96。如果在原有分支上有个修改的,需要同时cherry pick到新的分支上来。 对这个push事故,我深表歉意。给大家制造麻 ...
KlayGE里很早就支持屏幕空间实时非平面反射,并在后来扩展到了全方向的反射。虽然比传统的反射能少渲染一遍场景,速度有明显提高,但由于计算完全在像素级,开销仍然比较大。本篇将探讨一下如何加速反射的渲染,主要思路来自于SIGGRAPH 2014 Advances in Real-Time Rendering in Games里的Reflection System in Thief。 原始效果 拿Ocean例子来统计速度。在NVIDIA Geforece GTX 960上,没有反射的时候249FPS,有反射的时候就剩下159FPS了。也就是说,反射占了2.27ms左右。 加速1:半分辨率 既然是PS的瓶颈,那么最直接的优化方法就是降低分辨率。 原先的反射是在special shading里面计算的,必须是全分辨率。在新的改进里,render ...
继上一篇提到了把编译器要求升到了vc11/g++ 4.6/clang 3.4之后,develop分支又做出了一些改进。终于,我们完成了现阶段的C++11化改进。 constexpr vc14开始支持constexpr,所以可以用它来实现编译期字符串hash。以后还会进一步增加constexpr的使用,改善执行性能。在KFL里定义了一个宏KLAYGE_CONSTEXPR,在支持的时候是constexpr,否则定义为空。 emplace,move map里插入元素,原先的做法是insert(make_pair(key, value))。这么做代码比较长,在C++11里有了emplace,可以用emplace(key, value)来代替原来的写法。而且STL的实现里一般用了move semantic把key和value直接移入map,不用拷贝。如果原先已经有构造好了的pair,那么用insert和 ...
多年前我写过编译期字符串Hash和再探编译期字符串Hash两篇博文,分别证明了C++98下无法实现编译期的字符串hash,以及如何在C++11下用constexpr实现。过了这么多年,原有的实现在Clang上出现了严重的编译性能下降,需要一些修改才能顺利编译。而vc14也开始支持constexpr了,经过实验,发现问题仍很严重。所以这里不得不再次试着改进编译期字符串hash的方法。 旧方法回顾 上次的实现用了constexpr配合模板嵌套,实现了一个初步的编译期计算字符串hash的方法。 constexpr size_t _Hash(const char (&str)[1]) { return *str + 0x9e3779b9; } template <size_t N> constexpr size_t _Hash(const char (&str)[N]) { ...
在前几个版本开发的过程中,每次都有一些对工程系统的改进,但也积累了一些问题。在KlayGE 4.8的开发刚刚开始之时,我打算尽量把之前发现的问题解决掉,让以后的开发和使用更为顺利。 改进依赖文件的管理 在上一个版本中,KlayGE的代码库迁移到了git,同时也把第三方库和资源文件等放到独立于代码库的地方,在CMake里下载。但是,原先只是通过文件名来检测是否已经下载过。只要文件存在就不动它。这对一般只下载发行版的用户来说没有问题,但对开发者来说有有点麻烦了。一有新版本的依赖文件,就需要手动删除旧的,并再次执行CMake生成。钱康来就曾在开发4.7的过程中遇到过这个问题。他提议应该用个MD5来校验下载的文件和已经存在磁盘上的 ...
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 ...