KlayGE游戏引擎

[zh] 在PC上的C++开发中，boost已经很普遍。但对于Android这样的移动平台呢？由于KlayGE正在移植Android，作为依赖库之一的boost也必须移植过去。官方的boost并没有提供Android支持，看来得自己做了。 受MysticTreeGames的Boost-for-Android启发，我想用最新的Crystax NDK来编译boost 1.47。 准备工作 需要下载 boost 1.47 Crystax's NDK r6 MysticTreeGames的Boost-for-Android 补丁 首先，MysticTreeGames的补丁是基于boost 1.45和官方的NDK r5，在最新版上不一定能完美运作。因为有些源文件在1.45到1.47的过程中更改了，无法自动打上补丁。所以我手工地在原始的boost 1.47上根据补丁进行修改。其实不太难，因为只有12 ...

上文介绍了D3D11的两个重要特性compute shader和multi-threaded，本篇专注于两个不能在D3D10硬件上使用的、纯D3D11的新特性tessellation和BC6H/BC7纹理压缩。 Tessellation 很 多人会说D3D11增加了tessellation shader这个stage，但真相是增加了hull shader、tessellator和domain shader三个stage。Hull shader的输入是patch的控制点（三角形、四边形这样的图元，最多有32个控制点），计算出tessellation等级、确定 tessellation的方法等。它的输出被送给固定单元的tessellation进行细分。Domain shader的输入是细分后的bary centric坐标、来自hull shader的控制点，它负责计算插值后的顶点坐标。 Tessellation早就存在于一些GPU。 D3D9 ...

上文介绍了feature level和option features这两个最容易被误解的D3D11特性，本篇主要探讨一下另外两个重要特性，compute shader和multi-threaded。他们同样可以在D3D10级别硬件上使用，但存在很多细节需要注意。 Compute Shader compute shader（也叫DirectCompute）是D3D11新增的主要功能之一。在D3D11的GPU上，compute shader是完整的5.0版本，而在D3D10.x的GPU上，compute shader有个简化的4.x版。两者的具体差别请见Compute Shaders on Downlevel Hardware。 CS 4.x的一个很重要缺点是不支持RWTexture，所以shader无法写入texture，只能写入buffer。（这是NV造成的。AMD的硬件很 早就可以做到写入RWTexture，但因为CS 4.x要求同时兼 ...

仅以此文献给那些自以为了解D3D11的专家 D3D11正式发布已经有两年多了。在这短短的时间里，各GPU厂商 都相继推出了支持D3D11的显卡，许多游戏引擎也迅速推出了对D3D11的支持。但在国内，D3D11的接受度几乎为零。国内很多“大”游戏公司的“技 术人员”对于D3D11完全出于一知半解的状态，却又在不懂装懂地指手画脚。 关于D3D11，有些事情你确实必须了解。 Feature Level 从KlayGE 3.11.0发布以来，几乎每个月都会听见有人问我，“为什么要去掉D3D9和D3D10插件，仅保留D3D11和OpenGL？”。（最近这个频率显著 提高，基本到了每周1-2次的程度）。在他们的观点里，D3D11就得在D3D11的硬件上跑，而现在D3D11硬件尚未普及，这么做会影响到 KlayGE ...

上篇文章讨论了两个API在功能上的交集，以及互操作的方法。本篇作为系列的结局，将讨论一些平台相关的问题。 平台 长久以来，一直可以听到一种说法，D3D只能在Windows上用，而OpenGL可以用在所有平台。那么，我们就来看看在各个平台上，几种3D API的可用性。 桌面平台 Windows Windows 平台在这方面相当全面，D3D11、D3D10、D3D9、OpenGL、OpenGL ES都支持（需要注意的是，只有Vista+支持D3D10和D3D11）。由于OpenGL 4.1可以建立OpenGL ES的context，NV和AMD的驱动都提供了原生的OpenGL ES。这也为浏览器中WebGL的实现提供了方便。 Mac OS X Mac OS X所支持的OpenGL比较老旧，也不支持D3D和OpenGL ES。 Linux Linux的主打API是OpenG ...

上一篇讲到了如何填平OpenGL和D3D之间一些原本被认为位于底层的区别。本篇将剖析两个API在功能上的异同，以及直接相互访问的可能性。 功能 D3D9的功能早已被OpenGL 2.0所覆盖，网上可以找到很多资料，这里就不提了。本文注重的是新的GPU特性。下表列出了D3D10+的新功能，以及实现该功能所需要的OpenGL扩展或核心。 D3D 10的功能 OpenGL所对应的 Geomrtry shader GL_ARB_geometry_shader4或OpenGL 3 Stream output GL_EXT_transform_feedback或OpenGL 3 State对象 无，需要在上层封装GL_EXT_direct_state_access Constant buffer GL_ARB_uniform_buffer_object或OpenGL 3 Texture array和新的资源格式 ...

上一篇提出了跨越OpenGL和D3D的基本问题，介绍了一些能在不改变API的情况下，通过输入数据来消除OpenGL和D3D之区别。本篇的重点是如何利用现代OpenGL提供的扩展和新功能，消除一些无法在上层解决的问题。 顶点颜色顺序 D3D9 最常用的顶点颜色格式是BGRA格式（也就是D3DCOLOR），而OpenGL默认用的是RGBA格式。D3D9用BGRA纯粹是因为历史原因，早期硬 件不支持UBYTE4的格式，只能用D3DCOLOR，然后再shader里调用D3DCOLORtoUBYTE4。现在的GPU都支持 UBYTE4，D3D10+也是可以直接使用RGBA，所以这已经不是问题了。 如果需要兼容已经生成BGRA格式数据，现代OpenGL提供了GL_EXT_vertex_array_bgra这个扩展，也可以使用BGRA作为顶点颜色输入格式 ...

多年来，在论坛和各个网站上不断能看到拿OpenGL和D3D进行比较的帖子和文章。他们经常制造很多谜思，使得初学者和一些从业人员对OpenGL和D3D产生了各种各样的流言。 有人说，OpenGL直接调到驱动，性能高于D3D。 有人说，Shader都得写两套，很麻烦。 有人说，OpenGL和D3D在底层有很多区别，而且不可设置。 有人说，图形引擎如果要兼容两者，就只能取其功能的交集，最后还不如任何一种API。 真的么？ 本文试图： 找出现代OpenGL和D3D的共通之处 归纳如何让API对上层代码尽量透明 本文不希望： 讲解函数间的对应关系 如何在OpenGL和D3D之间作选择 贬低一方，抬高另一方 下面先从几个比较基本的方面 ...

上篇文章讲述了几种基于post process的AA方法，有没有可能将post process AA和hardware AA结合起来呢？本篇要讲的正是这样的hybrid AA。 首先补充一下，对于MSAA的计算浪费，可以从下面的对比图看出来： [caption id="attachment_1155" align="aligncenter" width="646" caption="MSAA需要计算的edge"][/caption]   [caption id="attachment_1156" align="aligncenter" width="647" caption="真正需要计算AA的edge"][/caption] 有了这个对比，大家应该有了直观感受，MSAA实际上把很多计算量浪费在了实际上不必要AA的像素上了。如果样本数高，浪费会更严重。 上一篇提到的那些基于post process的方法其实都在做一件事 ...

上一篇文章Anti-alias的前世今生（一）介绍了硬件支持的AA方法，本篇将重点阐述新兴的基于post process的AA。 SSAA、MSAA、CSAA这些方法虽然硬件直接支持，但带来的额外开销不可小视。一方面是它们对存储空间带来的冲击是惊人的。尤其在非桌面平台上，内存本来就不多，如果还需要AA的话就吃不消了。如果同时使用了MRT和AA，显存开销更是天文数字。另一方面，这些方法对“edge”的考量都是primitive的边界，不管这个edge是否真的需要AA，所以会浪费很多计算量。 GPU Gems 2的第九章Deferred Shading in S.T.A.L.K.E.R.在游戏界第一次宣传了Deferred Shading的概念，同时也提到了Deferred框架无法使用硬件MSAA的问题。虽然Deferred Lightin ...