KlayGE游戏引擎

上一篇把资源转成了用12的设备建立，下一步有点犯难了。 让我们做一个假设。要让一个最基本的系统能渲染起来，换句话说，关掉所有post process、UI、文字，就渲染一个三角形。至少需要一个vertex buffer、一个rtv、一个vs、一个ps、一次clear、一次draw call。Vertex buffer的问题已经解决；vs和ps本身和11的一样；clear和11的几乎一样，只要改成调用graphics command list上的函数即可；draw call也是。好了，那么问题就集中在 如何使用rtv； 如何组装起来渲染 但无论如何，这都是不归路。我们只能向前走，再也没法像前面那样，用11on12来让两者交互使用。 RTV D3D12里的RTV是放在一个heap里的，使用的时候把heap里的一个hand ...

上一篇我们讲了如何建立D3D12的设备，并在其之上建立出11on12的设备。接下去就要开始一步一步转移到纯D3D12下了。 第一个应该转的是相对独立的资源，包括buffer和texture。建立D3D12的资源，之后用前文说的CreateWrappedResource转成D3D11的资源，继续交给D3D11on12渲染就可以了。这样仍然可以往前走一小步，保证引擎还能工作。 Buffer Buffer包括vertex buffer、index buffer和constant buffer。 D3D12_HEAP_PROPERTIES heap_prop; heap_prop.Type = D3D12_HEAP_TYPE_UPLOAD; heap_prop.CPUPageProperty = D3D12_CPU_PAGE_PROPERTY_UNKNOWN; heap_prop.MemoryPoolPreference = D3D12_MEMORY_POOL_UNKNOWN; heap_prop.CreationNode ...

昨天晚上，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 ...