Talking To The Developers Of The Unigine Engine

Michael: What expectations do you have for the future growth of Linux gaming?

Denis: Market share of Linux as a desktop OS is steadily growing, so there will be unavoidable growth of interest in gaming on Linux. Moreover I think that introduction of good cross-platform games with support of Linux or even exclusive titles for Linux only will greatly increase pace of user migration to Linux, because at the moment lack of games for this platform is a stopper for a lot of them.

Michael: In supporting Linux, what have been your biggest challenges to overcome?

Alexander: A couple of years ago buggy video drivers were the most annoying issue, but at the moment everything is great. We especially would like to emphasize improvements of ATI drivers for Linux, that's really amazing work. We have no other problems with development in Linux since it's our native platform, it's more convenient for our team to develop software using GCC tool-chain and other great tools like Vim, SCons, ccache, and distcc.

Michael: Are your editor tools for the Unigine engine cross-platform?

Denis: Yes, they are. All of our tools are cross-platform.

Michael: What scripting language is used for the Unigine engine?

Denis: We have UnigineScript, which is an object-oriented fast language with built-in 3D math support. It's very powerful: for example, our visual editor is written completely by means of scripting.

Michael: Has Unigine been looking at supporting OpenCL or OpenGL 3.1 within this game engine?

Alexander: Unigine already utilizes some of the OpenGL 3.x features, which are useful in terms of performance, for example instancing, geometry shaders, and signed normals compressed into ATI2N format (RGTC, LATC). Unfortunately there are no production-ready drivers with OpenCL support, so we can't say right now how viable the technology is. However, if OpenCL performance will be good, we'll use it for physics simulation and rendering acceleration.

Michael: What is your experience with OpenGL drivers? Do you routinely encounter bugs on either vendor that force you to implement workarounds? Do you use multiple code paths, not only per hardware level (SM2, SM3, SM4), but also per-vendor?

Alexander: We submit driver bugs to hardware vendors and don't use a feature if it's broken in OpenGL. There are also different code paths for hardware from different vendors, because the same feature can be implemented differently in ATI/NVIDIA hardware, plus it provides a performance boost.