KlayGE游戏引擎

老用户一定记得，在KlayGE 3.9之前，用来表示effect的.fxml都需要通过一个python写成的编译器进行离线编译，生成.kfx格式才能给runtime使用。在3.9里引入了rapidxml，可以直接在runtime读取xml文件，流程变短，开发效率提高了。但随着这两年shader越写越复杂，编译shader所花的时间越来越多，在载入的时候每次都编译shader，一来浪费时间，二来浪费计算。 KlayGE的模型格式.meshml也有过这样的问题，后来通过一个JIT在载入的时候动态把xml的.meshml编译成二进制的.model_bin，之后的载入速度就极大提高了。既不需要离线编译，也不用担心读取效率。因此，引入一个effect JIT也成了理所当然的事情。所以，事隔多年后，kfx格式原地满血复活。 ...

在越来越多的人讨论Cg存留问题的时候，Cg 3.1突然发布了。主要的改进有： Cg语言支持uniform buffer。 增加了OpenGL Unified Buffer Object（UBO）。 增加了翻译成OpenGL GLSL version 110和120的支持。 新的tessellation例子。 新的uniform buffer例子。 各个例子都加上了VC10的工程文件。 不知道NV怎么了，给出来的下载链接居然是错误的。正确的是http://http.developer.nvidia.com/Cg/cg_3_1_0010.html，有兴趣的朋友可以看看。

AMD的OpenGL驱动问题很多，是个众所周知的事情。以前我也写过《OpenGL驱动的陷阱：ATI篇》和《OpenGL驱动的陷阱：ATI篇，后续》来阐述这个问题，当时最新的驱动是Catalyst 10.10。过了一年多的时间，AMD的驱动和KlayGE的代码都有了不少变化，情况又如何呢？ 失败的例子 在去年的驱动上，发现的问题主要有三个（ticket #58）： Deferred Rendering和Global Illumination中，GI的效果只在第一帧出现。没找到原因。 Detailed Surface和JudaTex Viewer中，纹理显示混乱。没找到原因。 GPU Particle System和Particle editor中，粒子没有显示出来。GS编译失败。 更新到Catalyst 12.1后（也可能在11.12或者11.11就更新了，我没测试） ...

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

[zh] 经过长时间的筹划，今天正式宣布开始次世代评测软件KlayMark的开发。 简介 KlayMark将以KlayGE为引擎，定位为一款集各种先进渲染技术于一身的跨平台评测软件。在提供赏心悦目的画面同时，对系统的性能作出综合评价。不论是PC平台还是移动平台，KlayMark将提供统一的计分方式，使得不同平台之间的得分具有可比性。 虽然动用到许多新技术，但KlayMark仍会保持极高的效率、较低的配置、良好的跨平台能力等特点。 发布计划 KlayMark的源代码将迟于二进制版本发布，类似Doom和Quake的方法。 由于平台的差异，KlayMark 1.0的发布将分拨进行。 Wave 1：预计开发周期1年。Windows平台支持D3D10+和OpenGL，Android平台支持Tegra ...

独具特色的KlayGE字体系统现在可以独立使用啦！ 在开发版本中，字体系统KFont成为了一个不依赖于KlayGE主体的子项目。目前包含的功能有.kfont格式的读写。未来可能加入字体转换工具和渲染代码生成。

为迎接即将到来的OpenGL ES 3.0（开发代号Halti），KlayGE的OpenGLES2插件正式更名为OpenGLES，以保持兼容性。同时，还增加了OGLESConditionalRender，通过GL_EXT_occlusion_query_boolean来实现遮挡查询。 另外说说OpenGL ES 3。在2007年的OpenGL ES Overview里面就有提到代号为Halti的OGLES3，是基于OpenGL 3.0来开发，目标发布时间是2010年。但现在显然延期了很久。终于，在前不久的CES2012上，Imagination Technologies宣布了PowerVR6，支持OpenGL ES 3、OpenGL 3、D3D 10和OpenCL。特定型号还可以支持D3D11.1和OpenGL 4。之前ARM也宣布了Mali-6xx支持OpenGLES 3、D3D11和OpenCL 1.1。同样，Qualcomm的Adreno 3xx也会支持OpenGL ES 3 ...

去年4月份我写过《OpenGL ES Emulator横向比较》，比较了4种常见的OpenGL ES模拟器。过了将近一年，让我们再次横向比较一下现在的模拟器。 基本特性 厂商 NVIDIA ARM 名称 x86 Windows OpenGL ES 2.0 Emulator OpenGL ES 2.0 Emulator v1.3 模拟目标 Tegra Mali 版本 OpenGL ES 1.1, 2.0; EGL 1.3 OpenGL ES 1.1，2.0; EGL 1.3 扩展 GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_NV_log_textures GL_OES_compressed_paletted_texture GL_OES_element_index_uint GL_OES_framebuffer_object GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_shader_source GL_OES_stencil8 ...

经过这几天的的开发和调试，KlayGE的所有例子都在NVIDIA的OpenGL ES模拟器上顺利运行了。除了没有GI、distance mapping退化成normal mapping、以及由于缺少float texture而不能实现高精度DoF之外，其他效果都和D3D11和OpenGL一致。 Tegra 2模拟器的问题 NVIDIA的OpenGL ES模拟器的模拟对象是Tegra 2，但支持的扩展不如真的Tegra 2。Tegra 2真机支持的OpenGL ES扩展有（来自Xoom）： GL_ARB_draw_buffers GL_EXT_bgra GL_EXT_Cg_shader GL_EXT_packed_float GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_latc GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_te ...

[zh] 上个星期，经过整个团队半年的努力，KlayGE迈进了4.0这个大版本！紧接着就是开始计划4.1的开发了。该版本大约在2012年6月发布，这里列出目前的新功能计划。 必然出现 这些特性一定会出现在KlayGE 4.1中，都有明确的实现方法，不确定性因素较小。 屏幕空间反射 FFT Bloom filter 基于Postprocess的stereo 通过Importance sampling加速GI（开发中） Collision detection函数库 进一步提升OpenGL ES 2兼容性 可能出现 可能出现的特性要么存在比较大不确定性，是否会出现在KlayGE 4.1取决于时间关系。 大气散射效果（开发中） SSGI 不会出现 这些东西不会在KlayGE 4.1中出现，所以不必再提了。 各种编 ...