KlayGE游戏引擎

经过越来越多的测试，在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上已经没有资源文件。 ...

上一篇提到了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个 ...