Skip to content
上个月底,KlayGE已经基本完成了迁移git的任务。这个过程不是一个简单的镜像,而是在导入git的过程中,删除大文件、依赖库等,并可以通过cmake下载、解压和打补丁。对开发者来说,流程上没有什么变化,都是自动完成的。 对于第三方库,之前的做法是从原网站下载发行版代码包,从klayge.org下载补丁,用python patch打上补丁之后使用。对于有些下载速度特别慢的包,比如wpftoolkit,我也放到了klayge.org。同时,KlayGE所要的资源文件也都在klayge.org。这么以来,最近klayge.org的流量激增,本来速度就一般,现在响应更慢了。 第二个缺点是浪费。比如boost,下载包56M,解压后400M,删掉不用的文件,剩下36M我们需要的。这样对带宽和构 ...
KlayGE在2012年就启用了C++11的部分功能。但目前为止所有用到的C++11特性都要求有一个对应的C++98替代品。要么自己实现,要么用Boost的。 随着时间的推移,各个编译器对C++11的支持越来越好。KlayGE支持的所有平台上,都已经有可用的C++11编译器。实际上如果用的编译器是g++或者clang,-std=c++11都是打开的。所以其实只有Windows上的vc9/10还不能很好地支持C++11。 因为vc9已经无法编译boost,留着没啥意义。对于g++ 4.3之前的版本,或者clang 3.0之前的版本,也没什么人用,也没必要留着。这样在KlayGE支持的编译器中,不支持C++11的就剩下vc10。但至少这样就能直接使用vc10所支持的C++11特性。 所以我的计划是,在目前的开发版本 ...
经过越来越多的测试,在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个 ...
前不久有人问我是否把版本控制考虑转移到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的程序框架。这样一来,程序主体可以接近其他平台的结构。性能优化等也会比较容易。