KlayGE游戏引擎

OSX版本完成之后，下一步就是iOS。 在之前的实现中，OSX的程序框架和别的平台很不一样，给维护和效率带来了一些麻烦。现在钱康来对OSX的进一步改进是，按照SDL2的方法，实现一个自己的消息循环。这么一来，程序主体和其他平台的结构达成了一致。同时，这个方法对iOS也有好处。于是在很短的时间内，KlayGE就已经完成了iOS的移植。目前，一些简单的例子已经可以运行，但诸如Deferred rendering框架这样的复杂情况，还有些问题。在iPad2等老的GLES2设备上，由于无法渲染到纹理的0层之外的mipmap level，建立multi resolution的时候失败了。GLES3设备上出错原因正待查明。 至此，KlayGE已经可以在Windows、Linux、MacOSX、Android、Windows ...

在使用了CMakeMS之后，支持Windows Phone 8+平台就成了理所当然的一件事情了。Boost 1.56已经能支持store和phone，在进一步解决了Phyton和7z在WP下的编译之后，我就开始尝试编译KlayGE本身。 下面讨论的WP，特指VS2013支持的WP8.1。WP8.0还没时间测试。 事实上，因为原先已经可以编译成store版本，切换到WP非常顺利。只有一处需要修改：WP上没有VersionHelpers.h，而且WinRT上也用不到。所以只要#ifndef掉就可以了。除此之外，没有任何别的修改，WP版本就可以顺利编译出来了。 在用模拟器运行的时候，出现了一个异常，WP有声明但没有实现CoreCursor。WP上不需要鼠标指针。同样，这里只需要一个#ifndef跳过那句就可以了。于是，KlayGE的大 ...

几个月前KlayGE的WinRT工程就已经转到CMake的方式进行管理。但因为CMake本身不支持WinRT，当时的做法是修改CMake的代码，打上自己的补丁后才能使用。现今，CMake有了个微软的fork，从我的补丁出发，专攻WinRT等平台上的兼容问题。目前这个分支能很好地生成Windows Store和Windows Phone的工程。 使用方法 对于生成其他平台的工程，这个分支的CMake和原先完全一样。对于WinRT平台，需要通过这样的命令行参数来指定目标系统和版本号： -DCMAKE_SYSTEM_NAME=WindowsPhone（或WindowsStore） -DCMAKE_SYSTEM_VERSION=8.0（或8.1） 实际上这个做法相当于和WinCE一样，在platform generator级别生成WinRT的部分，比我原先用compiler gener ...

上一篇我提到了如何用CMake管理Android工程。KlayGE除了Windows、Linux和Android之外，还支持WinRT平台。是的，WinRT虽然和Windows桌面很接近，但在一些细节上存在一些差异，使得它们应该被考虑为两个不同的平台。就好像Android和Linux应该考虑为不同平台一样。 区别 在KlayGE中，WinRT和Windows桌面的区别除了代码上，还涉及到工程文件和开发流程上。WinRT的工程需要考虑资源、打包、签名等，都是Windows桌面不需要的。从概念上看，WinRT开发更像Android这样的移动平台开发。 Android程序构建，用的是MinGW或Unix的makefile的方法，所以只需要把里面定义的编译器等换掉就八九不离十了。WinRT用的是VS2012+的工程文件，需要对其进行修改 ...

2年前KlayGE的工程文件就已经在王锐的帮助下切换到CMake。上个版本中，第三方库也已经都改用CMake。但是，对于Android版本来说，原先仍然使用的是NDK的那套东西。所以在维护上带来了不小的开销。随着代码量越来越大，如果能把Android也纳入到CMake工程中，开发起来就能更方便。所以前一阵子做了些探索，最终解决了这个问题。 原有的编译方法 我一直都没有使用Eclipse，而是纯用命令行的方式进行编译。需要： 准备好AndroidManifest.xml、Android.mk、 Application.mk等工程文件 android update project -p . -s --target=android-10，生成build.xml等 ndk-build，编译出.so 把所需资源编译和拷贝到assets目录 ant debug，打包 ...

HDR post process几乎存在于所有PC桌面引擎中，也开始在一些高端移动平台上得到了支持。HDR太常见了，以至于这年头如果看到一个不带HDR的真实感实时渲染，就会觉得很突兀。（比如，在SIGGRAPH展会上，看了Qualcomm的展台，再看ARM和Imagination的，就有一种回到dx8时代的感觉。大部分原因就来自于Mali和PowerVR缺乏很好的HDR。）在这方面，KlayGE的目标是在不同平台上，都能尽量多地复用HDR post process里的组件，同时效果也尽量接近。首先让我们看一张只有LDR的图。 啥都支持的平台 代表的平台有D3D11 level 10+，OpenGL 3+。支持包括B10G11R11F在内的各种浮点纹理。在这样的平台上，KlayGE的HDR流程是这样的。注意红字标出来的数据 ...

前一阵子在把KlayGE的OpenGLES插件升级到OpenGL ES 3的过程中，原先还满怀希望地觉得GLES3总该全面支持浮点纹理的读写了，结果发现GLES3的标准支持float16和float32的读取，但不支持渲染到float16/float32的纹理上。只有支持GL_EXT_color_buffer_float或GL_EXT_color_buffer_half_float扩展的硬件，比如Tegra 4和Adreno 3xx才能很好地支持。所以，在其他设备上如果要渲染到浮点纹理，就得另想办法了。 编码和解码 单通道的float是32-bit，RGBA8也是，所以按说把float编码到RGBA8的纹理中应该没啥问题。很可惜的是，不支持浮点纹理的硬件往往也不支持整数指令和位运算操作。所以在这里需要有些限制。在网上搜了一下，最靠谱的应该是大牛Aras ...

网上看到的GPU比较，都是桌面和桌面比，移动和移动比。很多人对此没有概念，总觉得移动的CPU/GPU在性能上也能比肩桌面CPU/GPU。那么就让我们来看看把各家的顶级GPU放在一起比硬指标，是什么样的结果吧。资料来自wikipedia和厂商自家宣传。 计算单元对比 Model Fab (nm) Core Clock rate API Core (MHz) Memory (MHz) NVIDIA GeForce GTX Titan 28 2688 836-993 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 NVIDIA Quadro K6000 28 2880 901.5 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 AMD Fusion APU 8670D 32 384 844-950 1066 D3D 11.0, OpenGL 4.3, OpenCL 1.2 AMD ...

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

在KlayGE的空框架跑起来之后，经过几天艰苦的debug，修正了多个KlayGE的bug，绕开更多Android的bug。现在，Text和Vertex displacement两个例子已经能在Android上顺利执行了。 Text例子。乱码不是bug，只因为系统区域没设置成中文。 Vertex displacement例子。 在移植的过程中，遇到的一个麻烦是NDK的ANativeWindow_getWidth和ANativeWindow_getHeight总是返回1，无法得到正确的窗口大小。结果viewport被错误地设置成1x1，使得渲出的东西都只有1个pixel。在修改了native_app_glue，获取resize的消息后，viewport大小终于得到了正确的设置。那两个例子才因此能正常执行。从这里也可以看出，Android的NDK千疮百孔，开发的时候要异常小 ...