To the delight of video hardcore gamers today +Marco’s Box has the pleasure of interviewing Croteam, the Croatian software house known to most for the Serious Sam. Good reading
First of all a bit of past history, let’s talk about serious sam for linux, it’s require a lot of job for porting on linux? And also, are you satisfied about the performance?
It certainly was an effort when we decided to port the game for linux – mostly with implementing low level platform specific components such as handling input, generating error reports, working with Xorg and making sure it all works well with various window managers and desktop environments.
On the other hand, a lot of necessary building blocks were already supported by the engine – such as OpenGL and OpenAL due to modular design of engine’s sound and graphics modules.
Most graphical issues that we encountered using Linux on Nvidia and AMD cards could also be reproduced on windows when running OpenGL. The only Linux specific issues were with the Intel GPUs since the driver is different to the one developed for windows.
As for the performance, we are happy with the performance using linux but we’re not too happy with performance using OpenGL. The game using OpenGL is usually faster on Linux than it is on Windows but the OpenGL performance offered by the drivers is still worse than DirectX.
We have noticed better OpenGL performance in some cases (on certain lighter workloads with simple shaders) but it gets worse in more complex scenes.
For the talos principle you have used a new release of your engine, would you like to talk about it and give us a sort of “changelog” about this engine? It’s build with focus on a single platform and ported to to other or it’s build from scratch for running everywhere?
The parts of the engine that work with hardware or OS-specific functions are made to be modular to allow for easier parallel development of the game for multiple platforms.
The latest code is continuously built for all supported platforms which allows us to detect problems very quickly – and having the code compiled by various compilers and then tested on various platforms definitely increases the quality of the code.
A lot of things have been added or changed in this iteration of the engine, but most of those are under-the-hood changes that are not directly visible to the end users. They are either performance and compatibility improvements like DirectX11, OpenGL ES, multithreaded renderer, Linux distribution variations coverage…. ; or things that help development like automated navigation mesh building, auto-test bot… ; or specifics that were needed for gameplay like special character physics system, content streaming, etc.
Which differences or problems does a development team, used to work on Windows, encountered during a porting to Linux?
A screenshot from The Talos Principle
By far the biggest problem is working with various window managers – with each having its own quirks and peculiarities. One of the more recent examples is preventing the screen saver from showing while playing the game. This is usually not a problem when playing with the keyboard and mouse since the system detects that as user input and screen saver will not show. But this is not the case when playing with the controller – so the game should prevent the screensaver from starting until it’s no longer running. Of course there is no single way of doing this on linux that would work well for all desktop environments, so in the end we use multiple methods hoping that at least one would work on any given system. This is not the only problem that had to be solved in such a way – things sometimes have to be done in certain way/order on some WMs while others are more robust – so it’s often a lot of trial and error until we find a solution that works best (mostly) everywhere.
We can call The talos Principle “a port” or it’s build from scratch with a special attention for linux?
When the development of The Talos Principle started, Linux support was already added to the engine, so Linux version was built along with Windows and OSX versions. Linux specific support is added and tweaked as the time goes – when bugs are found or if new features get added to the engine, but that’s the same for all platforms that we support.
Do you receive good feedback from linux gamers? Do you plan to make more Linux ports of your games?
The feedback from Linux gamers is great – they seem really happy that we’re supporting the platform and they are a huge help in finding bugs. Often, bugs that are initially reported as Linux specific turn out to be issues in all version of the game, it just sometimes happens that it’s easier to reproduce on some platforms. So, yeah – we’ll definitely keep on supporting Linux in the future.
Do some of yours use Linux on daily basis?
Most of use it on our phones – and some of also have it on computers – home servers, media PCs and also as desktops.
Karlo Jež del Croteam at work
How do you feel about gaming on Linux? Steam hype is still here or it’s fading away?
I’m really glad that there are more and more Linux games available, even from larger publishers and developers. As for the future, it’s mostly in Valve’s hands – we’ll see when the first steam consoles start coming.
Some say “direct X ruin the gaming industry because you can develop just for one platform (windows), using openGL you can develop just once and run everywhere” Can you agree with this?
Having only one graphics API would be easier, but it’s no panacea – since that only solves the problem of rendering. Managing windows, threads, input devices and other platform specific tasks still have to be done for each platform. The greatest problem with the prevalence of DirectX is that GPU vendors don’t have as much incentive for tuning OpenGL performance as they otherwise would. But things are improving and hopefully will improve even faster with the arrival of steam consoles.