KlayGE游戏引擎

上一篇提到了BC7的结构，以及压缩的巨大计算量。本篇将阐述FasTC算法，一种可以快速压缩BC7的方法。 慢的根源 之前讲过，传统BC7压缩之所以慢，是因为需要穷举所有的可能性，从中挑出最好的一种。在这种情况下，最快的实现靠的是GPU的巨大并行度，虽然能解决问题，但效率仍然很低，并依赖于D3D11的CS。 审视BC7的压缩步骤，可以看出首先有64个partition，8个mode，有的mode有2种颜色编码和3种旋转。很显然，占决定性作用的是64个partition。如果能有个算法不需要穷举就能决定一个partition，就能迅速把计算量减少几十倍。 Partition的确定 那么有没有可能直接确定出partition呢？09年刚完成BC6H/BC7 DirectCompute Encoder Tool的时候 ...

DXT到了D3D10之后，就改名为BC（Block Compression）。到了D3D11/OpenGL 4.2时代，又增加了BC6和BC7两种高效的压缩法，分别针对HDR和LDR。但是，由于BC6/7的压缩复杂度远超过以往的BC1-5，D3DX的压缩函数又不是特别给力，限制了它的应用。本系列将专注于介绍一个BC7的快速压缩算法。 和其他BC的比较 BC1的只能用于RGB565，或者RGBA5551。压缩质量不高但速度很快。BC2和BC3的RGB部分和BC1完全一样，都是RGB565。BC2的A是4bit采样，BC3的A是8bit插值。如果要用他们来压缩非颜色信息，比如normal，结果基本都不怎么样。因为最好的BC3也只能提供一个8bit通道和一个6bit通道。 BC4和BC5只有1通道和2通道。BC5在用于normal压缩的时候能提供2个 ...

前不久有人问我是否把版本控制考虑转移到git的事情，其实我在2013年就写过一篇从hg导入git的方法和坑，里面给出了转移的实验，但没有具体计划。已经1年多过去了，git的工具和工作流也慢慢成熟。虽然git仍有一些基础上的缺点，比如无法进行文件改名以及轻易就可以改变历史记录，但由于有submodule和轻量的分支，再加上github的发展，从用户采纳程度来看，在git和hg的竞争中，git已经胜利。是时候再次考虑这个问题了。 需要注意的是，目前KlayGE的hg repository已经超过500M，初次pull的速度很慢，每次push的性能也受其影响。如果能在转移到git的过程中解决这个问题，这样的转移才有意义。否则只是换汤不换药。 几个选择 转移到git有多种 ...

OSX版本完成之后，下一步就是iOS。 在之前的实现中，OSX的程序框架和别的平台很不一样，给维护和效率带来了一些麻烦。现在钱康来对OSX的进一步改进是，按照SDL2的方法，实现一个自己的消息循环。这么一来，程序主体和其他平台的结构达成了一致。同时，这个方法对iOS也有好处。于是在很短的时间内，KlayGE就已经完成了iOS的移植。目前，一些简单的例子已经可以运行，但诸如Deferred rendering框架这样的复杂情况，还有些问题。在iPad2等老的GLES2设备上，由于无法渲染到纹理的0层之外的mipmap level，建立multi resolution的时候失败了。GLES3设备上出错原因正待查明。 至此，KlayGE已经可以在Windows、Linux、MacOSX、Android、Windows ...

最近，钱康来的实验把KlayGE移植到了OSX平台上。在上一次更新中，绝大部分问题已经解决。现在，我高兴地宣布，所有的例子都已经可以在OSX上顺利执行，并都能得到正确的结果。至此，OSX版本已经完成。 另外，iOS版本也已经有了很好的进展，一些基本的例子已经可以执行。下一阶段，我们将进一步改进OSX和iOS的框架，按照SDL2的方法，调用Apple平台底层的函数，实现一个自己的消息循环，而不是把一切都交给Apple的程序框架。这样一来，程序主体可以接近其他平台的结构。性能优化等也会比较容易。

前几天，KlayGE 4.6刚刚发布，现在新版本的开发已经开始了。这里公布一下我对KlayGE 4.7的一些计划。和以前一样，欢迎有兴趣、有时间加入KlayGE 4.7开发阵营的朋友们继续参加。 KlayGE 4.7将会更加高效，并继续发展移动平台的支持。 时间线 这里列出几个重要的时间点，以供进度参考。 2015年5月31日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2015年6月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2015年6月30日，release：正式发布KlayGE 4.7。 必然出现 这些特性一定会出现在KlayGE 4.7中。其中有些需求来自于KlayMark。 Transient Buffer。高效buffer管理 ...

在KlayGE走上OSX的实验中，我提到了目前OSX的版本还有两个主要问题，一是没法打开post processing，而是shader编译用的是Cg，以至于不能支持GL3+的功能。钱康来这几天又做了一些实验，在很大程度上解决了这些问题。 Post processing 原先一打开HDR、FXAA、Gamma校正等流水线末端的post processing之后，只能看到黑屏或一片混乱。在xcode的调试中看到的是，back buffer中有正确的结果，但swap到front buffer就只有错误的画面。这就排出了是depth或stencil没用清空造成的错误，只能是swap的地方有什么蹊跷。 经过一番尝试和查阅资料，发现了OSX和其他平台在swap上有所不同。Windows上的SwapBuffers，以及Linux上的glXSwapBuffers，都可以 ...

[zh] 大家圣诞快乐！又到了KlayGE的发布周期。今天，KlayGE 4.6正式发布了！这个版本创造了很多个第一次，下面会给予逐个列出。在这个版本的开发中，我因为一些个人原因，投入的时间比以往有所减少。幸运的是，由于有了一次新的开发人员招募，新老成员完成了不少组件，同时也有很多朋友提供了宝贵意见和bug报告，在此表示感谢。KlayGE 4.6的主要更新如下： 引擎方面的改进 现代化OpenGL，由刘瀚阳协助完成。增加uniform buffer、debug output等OpenGL 3.x的特性。OpenGLES插件也会做相应修改。 改进的DXBC2GLSL。林胜华进一步增强了DXBC2GLSL，增加了HS/DS/CS的支持。 支持最新的OpenGL 4.5。 改进OpenGL在AMD和Intel显卡上 ...

长期以来，把KlayGE移植到iOS的呼声很高。从别的平台直接移植到iOS，跨度有点大。所以我的计划里把MacOSX当作一个中间平台，先移植到OSX，把OSX当作开发平台来开发iOS版本。现在，KlayGE的OSX版本有些进展，在这里总结一下。 OSX几乎完全由新加入的组员钱康来完成的，在此表示感谢。这也是第一次不是由我亲自完成的平台移植。除了需要对付平台API的差异之外，还需要把一部分窗口相关代码用ObjC完成，在通过跨语言调用接入引擎的其他部分。目前有些初步的结果，在不加上post processing的情况下，一些sample可以顺利执行了。post processing一加就黑屏，具体原因正在调查中。 下面是一些结果。 除了post processing，还有 ...

不久以前，KlayGE附带的boost破例升级到了1.56.0。随着boost的开发进度重回正轨，1.57又如期发布了。所以KlayGE第三方库的boost再次回到传统的只更新单数版本的规则。 在boost 1.57之前，any用的是C++原生的typeid，在使用的时候必须打开编译器的RTTI。于是我提交了一个补丁，让any使用Boost.Core中的一个替代typeinfo。由于现在有了更完善的Boost.TypeIndex，any可以直接使用它。这样就能在不打开RTTI的情况下使用any。再加上1.57更好地兼容了WinRT和Android，原先很多修改变得不必要了。这么一来，要在KlayGE支持的所有平台上都使用boost，需要修改的地方前所未有地少了。 接下去我还打算把Boost.SmartPtr等地方用到typeid的也都改成 ...