KlayGE游戏引擎

上周末实现了打算在KlayGE 4.0中使用的render to texture array功能。于是自然而然想到在ShadowCubeMap这个例子中使用，用来在1个pass内直接生成cubemap。结果，不比不知道，一比吓一跳。在不同GPU上FPS如下： NV 9800GT NV 480GTX AMD 5870 6 pass Cubemap 158.63 312.82 241.10 Dual Paraboloid 5.77 375.32 211.91 1 pass Cubemap 66.08 288.77 228.44 1 pass Cubemap with instance 105.37 281.34 224.10 1 pass Cubemap with instance GS NA 287.80 211.01 9800GT所在机器的CPU比后两套系统差得多，没法横向比较，只能纵向比较。后两套系统只有GPU不同，可以横向和纵向比较 ...

上周五，Linux 3.0核心终于正式发布了！ Linux 3.0带来的新功能主要有 Btrfs数据检查和自动碎片整理 支持XEN Dom0 无需权限的ICMP_ECHO WLAN唤醒 Berkeley封包过滤器的即时过滤 类似于memcached的页面缓冲系统 新的系统调用sendmmsg()，可以合并多个sendmsg()和setns() 用于更好地处理轻量级虚拟化系统的新系统调用 增加的新硬件主要有 Microsoft Kinect AMD Llano Fusion APU Intel iwlwifi 105和135 Intel C600 serial-attached-scsi控制器 Ralink RT5370 USB 多种Realtek RTL81xx设备 Apple iSight摄像头 增加了其他很多驱动和小更新 详细更新可以在这里找到。 看得出来，新的Linux核心 ...

上篇文章讨论了两个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和新的资源格式 ...

[zh] KlayGE经历了3.12的合作开发的成功之后，正式向着下一个大版本4.0迈进！4.0不追求有多少新功能，主要目标是对现有的东西进行整合和优化，成为更有效更简单实用的开发框架。该版本大约在2011年12月份发布，这里列出目前的新功能计划。 系统要求变化 支持Shader model 4.0的显卡 必然出现 这些特性一定会出现在KlayGE 4.0中，都有明确的实现方法，不确定性因素较小。 Deferred Rendering层 资源载入框架 优化GI 支持render-to-texture-array Phong Tessellation Dual Quaternions蒙皮 可能出现 可能出现的特性要么存在比较大不确定性，要么优先级较低，是否会出现在KlayGE 4.0取决于时间关系。 移植到A ...

今天在Android的开发网站看到了google已经发布Android 3.2 SDK，目前API level已经升到13。和之前的传闻一样，Android 3.2主要目标是更好地支持7寸平板。 新的用户功能 针对更多平板设备的优化 让固定分辨率的应用也可以兼容式缩放显示 SD卡媒体同步 新的开发功能 增加了用于控制屏幕的API NDK也升级到了r6。最显著的更新是支持了x86 ABI，看来android将要大举进驻x86已经毫无疑问了。 另一个好消息是，Android的开发网站不再被墙，国内可以直接访问。

上一篇提出了跨越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之间作选择 贬低一方，抬高另一方 下面先从几个比较基本的方面 ...

[zh]在网友cin的帮助下，KlayGE的国际论坛上线了！目前包含英文论坛和俄文论坛。中文论坛仍是由opengpu提供的。[/zh] [en]With cin's help, the international forum of KlayGE goes online! At present, it contains English forum and Russian forum. The Chinese forum is still provided by opengpu.[/en]

昨晚写了我的第一个WebGL程序，主要是用来测试浏览器对WebGL的支持程度，有兴趣的朋友可以看看。 WebGL test