KlayGE游戏引擎

上一篇讲了在KlayGE 4.0中，Deferred Rendering的流水线改进。本篇继续讲G-Buffer的变化。 G-Buffer布局 前面提到了G-Buffer改成了MRT，那么现在就来比较一下新老G-Buffer的区别。老G-Buffer的安排如下： 老G-Buffer是4个通道、每个通道都是fp16的RGBA16F格式。其中normal用Spheremap Transform的方式映射到2个通道；depth单独存一个通道；specular和shininess挤在一个通道内，整数部分为specular * 100，小数部分为shininess / 256.0f。 这样的G-Buffer需要占据64-bit，IO开销不小，而且depth精度有限。如果按照新的MRT G-Buffer扩展到2个RT，就需要再增加一个32-bit的RT。对于不支持Independent MRT的D3D9硬件来说，甚至要增加 ...

Deferred Rendering在KlayGE中已经出现比较长时间了，我也写过系列文章来阐述KlayGE中的延迟渲染。在将要推出的KlayGE 4.0中，Deferred Rendering进入了渲染系统的核心，可以作为更通用更方便的一个渲染封装来使用。 在功能上，KlayGE 4.0中的Deferred Rendering也有了长足的进步。本系列将着重于解析这些新改进。 流水线 先来看看Deferred Rendering的流水线。 在流水线方面，第一个比较大的变化是，G-Buffer改成了MRT的，用类似Deferred Shading的fat G-Buffer来避免在shading pass再次渲染一遍物体。新G-Buffer的布局将在下一篇分解。在shading pass阶段，只需要渲染一个全屏quad，在每个pixel上把材质和光照信息结合就可以了 ...

[zh] 本文的目的不是为了完整地把Python 3.2移植到Android，只是希望编译出能用在自己程序里的链接库。 完成boost 1.47的移植之后，下一个目标就是Python 3.2。目前Python只有2.6.2非官方地移植到了Android（见P4A），他们迟迟不开始移植3.x，主要原因是他们认为3.x没用-_-。看来这件事情只能自己做了。由于Python 3.x和之前的版本有着巨大的区别，其难度完全不可预测。 准备工作 需要下载 Python 3.2.0 Crystax's NDK r6 Cygwin P4A configure 按照linux平台的老习惯，很多配置是写在.in文件中，需要用configure来生成出对应的.c或者.h。这里需要特别注意的是，需要让configure用NDK的工具链： ./configure --host=a ...

[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作为顶点颜色输入格式 ...