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 ...

[zh]三年前，我就曾经计划过一个KlayGE的长期研发子项目，D3D11 HLSL字节码到GLSL的编译器。两年前，在d3d1x for linux代码的帮助下，基本的字节码解析和反汇编工具已经实现。如今，这个子项目被正式命名为DXBC2GLSL，在库和工具两个层面上提供HLSL字节码（DXBC）到GLSL的转换。2013年底，DXBC2GLSL支持VS和PS初始版本已经由团队新成员林胜华完成，并提交到开发版本中。GS的支持也已经在上个月加入。当前所有KlayGE中的shader已经全部通过测试。[/zh] [en]Three years ago, I've planned a long-term R&D sub-project of KlayGE, D3D11 HLSL bytecode to GLSL complier. Two years ago, derived from d3d1x for linux, a simple bytec ...

从KlayGE 4.0开始，不但有为了下一版本开发的短期任务，还有一些中长期研发的任务。其中之一就是HLSL bytecode to GLSL编译器。现在KlayGE里的shader主要由HLSL写成，通过#ifdef的土办法兼容Cg。对D3D11来说可以直接使用，但对于OpenGL和OpenGL ES 2就得大费周折了。那种情况下，shader需要经过Cg编译器编译成传统的GLSL，在经过我自己的token级别的编译器转换成现代的GLSL，然后才能使用。 为什么不直接用Cg？看看Cg runtime在ATI卡上的表现吧。 为什么不用传统的GLSL？NV的驱动有一套attribute和index之间的绑定规则，比如gl_Position一定是0，gl_Normal一定是6（或者某个数，但是个常量），而且无法通过API来获取预定义attribute的i ...

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

上一个帖子提到了在Catalyst 11.4上，KlayGE的OpenGL插件黑屏的情况，现已查明是因为AMD和NVIDIA的GLSL不兼容的原因。NV的驱动上fragment shader可以定义varying out vec4 v_gl_FragData[8]这样的输出数组，但AMD的驱动上不支持。所以我再次修改GLSL生成器，把数组拆成独立变量，解决了问题。但实际上AMD的GLSL预定义了out vec4 gl_FragData[]，所以变成预定义可以，自定义不行的情况。估计得等以后他们自行解决吧，目前只能先绕开了。