FAQ

Q: What is KlayGE?

A: KlayGE is an open source, cross-platform game engine. It’s written in C++, and use Python as scripting language. KlayGE is released under GPL license.

Q: You are the only developer of KlayGE?

A: Yes and no. Almost all of the development is completed by myself. However, during this process, some 3rd-party libraries are used, for example 7zip encoding/decoding. Many friends also provide their indispensable advices in the development. From 3.12, many features are done by team members. Atyuwen provides GI. Ray, Xiaoyang, honyeung Lau provide Maya exporter. Windameister provides DPSM. Shunbin, Peng provide FXAA and Temporal AA. Ray provides cmake script.

Q: Where can I find KlayGE’s documents?

A: The only documents are files in the Documentation page. The main reason of lacking documentation is I do not have enough time to write them down. Also, I hope the code can achieve self-explanatory.

Q: Why GPL?

A: Before 2.7, KlayGE is released under LGPL. But, in order to prevent KlayGE from annexation by some proprietary projects, it’s replaced by GPL since 2.7.

Q: Why not using LUA instead of Python?

A: Before 2.0 (named Clay! Engine at that time), LUA is the primary scripting language. The advantage of LUA is fast. However, calling it in C++ is extremely complex. And LUA’s ability is weaker than Python. Although Python is not as fast as LUA, it’s a much more powerful language, and easier for calling. In KlayGE, runtime efficiency of scripting is not a concern, so Python is more desirable.

Q: Why requires Shader Model 2.0 and above?

A: KlayGE is a high-end game engine, so it requires to be run on some powerful machine to meet the need of advanced techniques. On the other hand, Shader Model 2.0 is not a very high demand. Nearly all graphics cards now support Shader Model 3.0. For a game developer, using a card that doesn’t support Shader Model 2.0 is behind the times too much.

Q: How’s the network system in KlayGE?

A: The network part is a weak point of KlayGE, or even impossible be used. Therefore it needs to be developed, or using 3rd-party network library.

Q: When compiling samples, there are some link errors such as: “libcmtd.lib(dbgheap.obj) : error LNK2005: __CrtSetDbgFlag already defined in MSVCRTD.lib(MSVCR80D.dll)”. How to solve this problem?

A: KlayGE in VC is compiled with multi-threaded DLL runtime library. So it requires ALL lib that link to an exe uses multi-threaded DLL (Project- >Properties->Configuration Properties->C/C++->Code Generation->Runtime Library, choose Multi-threaded Debug DLL/Multi-threaded DLL).

Q: What’s the parameters when compiling Boost?

A: Boost 1.36+’s parameters are set though bjam’s command line. They can be written in a batch:

   SET BZIP2_SOURCE="D:/bzip2-1.0.5"
   SET ZLIB_SOURCE="D:/zlib-1.2.3"
   SET ICU_PATH="D:/icu4c-3_6"
   bjam --toolset=msvc-9.0 --stagedir=./lib_vc9_x86 --builddir=./ address-model=32 link=shared runtime-link=shared threading=multi cxxflags=-wd4819 cxxflags=-wd4910 define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE define=_SECURE_SCL=0 stage debug release
   bjam --toolset=msvc-9.0 --stagedir=./lib_vc9_x64 --builddir=./ address-model=64 link=shared runtime-link=shared threading=multi cxxflags=-wd4819 cxxflags=-wd4910 define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE define=_SECURE_SCL=0 stage debug release

Run this batch under boost’s directory compiles boost into the dll form.

Q: Why running any sample inside Visual Studio cause assert failed in ResLoader::Load?

A: Project’s working directory should be set to $(OutDir). This problem no longer exists since KlayGE 3.10.

Q: How to solve compling error “‘yasm’ is not recognized as an internal or external command, operable program or batch file.”?

A: According to the project settings, Visual Studio must call yasm to compile .asm files. One solution is that rename the downloaded yasm-X.X.X-winYY.exe (X is the version, YY is 32 or 64) to yasm.exe. Then copy it to VC’s bin folder, for example, C:\Program Files\Microsoft Visual Studio 9.0\VC\bin. This problem will be by-passed in KlayGE 3.11.

Q: Why KlayGE don't support D3D9?

A: From KlayGE 3.11, the D3D9 plug-in is removed. Actually, the only reason for the exists of D3D9 is the Win XP users. But most of them have D3D10 GPUs, so the limitation is from XP itself. The OpenGL driver under XP is up-to-dated, it can provide XP the latest D3D10/11 GPU features. Compare to D3D9, OpenGL in XP has more funtions and higher performance. As a result, the D3D9 plugin is removed uncompromisingly. D3D9's mission in XP is taken by OpenGL.

Q: Why KlayGE don't support D3D10?

A: From KlayGE 3.11, the D3D10 plug-in is replaced by D3D11 plug-in. D3D11 runtime doesn't requires a D3D11 GPU. On D3D10 GPU, D3D11's features equal to D3D10's, plus compute shader 4.0, and may plus multi-threading. Its performance depends on hardware vendor. Nowadays the performance is identical with D3D10's. There's only benifits with D3D11 on early hardware. D3D10 plug-in is useless any more.