Back in November, we were covering the progress on the port of S.T.A.L.K.E.R. to OpenGL (and eventually Linux) following the leak of the original games’ source code (the Xray engine). Since then, a number of things have happened, and it’s definitely a good time to give you an update. And some new screenshots of recent builds.

First, while most of the DirectX to OpenGL effort involved Jules so far, the team is now composed of three main developers, with Pavel and Alexandr. Pavel was the one who started it all, in a way:

Pavel: I’m a student at BMSTU, 22 years old, will graduate next year. In terms of coding I got into Stalker in 2010 when I was developing tools for game server administrators. Before the source leak happened, I was exploring disassembled game binaries trying to fix some multiplayer bugs. That was the time I realized that things would go much faster with the sources. […] In August 2014 I accidentally stumbled upon the thread on gameru.net with the X-Ray sources leak discussion. The fact that the leak happened about 4 months ago while no one had created repository on GitHub surprised me a lot, and so I did. And a couple of months back, I discovered Jules was working on the OpenGL port - a thing I couldn’t even imagine: despite the clearly described issues and numerous forks, nobody seemed to keep on.[…] That’s too much work. Jules was the right man in the right place at the right time.

Alexandr is a more recent member. He so happened to join the team after reading about the port on BoilingSteam:

Alexandr: I’m 25 years old. I started to use Linux at 2005 and since 2008 I don’t use Windows anymore. At 2012 I graduated as IT Engineer and now I have five years’ experience of commercial C++/Qt development. In my spare time I work on different open source projects, such as Qt, KDE and Telepathy.[…] I read the article “S.T.A.L.K.E.R.: How The OpenGL Port is Shaping Up” and realised that this would be my chance to take a part in big game development. I joined the IRC channel #openxray and started to read the game sources and recent commits. I found that the game is not ported for any bit and even OpenGL backend is still windows-only thing. I was going to left the channel, but Jules said “Hello” and here we go :) […] I developed few “gaming” projects to learn something, but OpenXRay is the first game project, which is the purpose itself :).

Three members, in different locations with multiple, complementary backgrounds. They are now splitting the tasks around the port as follows:

• Pavel works on AI and scripting.
• Alexandr takes care of making most of the code portable.
• Jules, as per our previous article, handles the rendering part, converting DirectX calls to OpenGL.

Here’s more details as to what each of their work involves.

Pavel: Currently I’m refactoring AI and scripting subsystems in order to eliminate superfluous complexity and lots of copy-pasted code. Because we want to preserve compatibility with all canonical game resources and mods, there are a number of restrictions: we have to keep original script API, which in its turn requires to save original class hierarchies, which depend on each other. The process is pretty complicated: you begin to tweak one thing, understand that it requires a bunch of other tweaks, and so on. An illustrative example would be my recent architecture refinements which, as it turned out, require to update customized script binding library, which is based on severely deprecated ~10 years old version, that’s barely could be found on the internet. New versions, on the other hand, are not backwards compatible, and moreover, introduce new bugs.

AI and scripting involves numerous dependencies and callbacks, so Pavel needs to go through all the code to map and simplify connections to make things readable again.

Pavel: Usually I write out the entities with their dependencies to text file so that I could observe the whole structure. In some cases, when lots of nested macros are mixed with templates, one could use preprocessor output to figure out what’s going on. For example, that’s how script callback class looked like:

• script_callback_ex.h
• script_callback_ex_inline.h
• script_callback_ex_generators.h
• script_callback_ex_nonvoid.h
• script_callback_ex_void.h

And now it’s a single readable header:

• script_callback_ex.h

But sometimes you just go trial and error.

Alexandr is working on making the original source code more portable (beyond the original Win32 API), and obviously working specifically on the Linux port:

Alexandr: I make game core to be portable by introducing and fixing various platform abstractions. I’m sure that the right way is to have a single codebase for all platforms, thus one half of my work already goes into the main code repository. The other half goes into my “linux” branch for testing. I want to push “additional-only” commits into the main repo after code stabilization. Core library consist of various small (relative to the engine) parts, such as Memory manager, Strings with utils, Filesystem (real and virtual), Debug utils, CPU detection, Cryptographic API, Math API, Threads API and so on. I would say that this module is ported for 40%. After “core”, I would work on “engine” module (which doesn’t include sound, render, AI or physics). This means SDL backend for Window and Input. The question is if we want to make an abstractions here, which would be implemented either via Win32 and DirectInput or via SDL, or we would introduce SDL as a mandatory dependency for all platforms (which is not a bad thing at all).[…] We have agreed to use SDL2 for all platforms, when the SDL backend would be polished.

Making the game code more portable is done partially by wrappers:

Alexandr: We have our own wrappers for some library functions, such as string lowering, which is seems to be an integral part of win32 API, but is not a standard function on other platforms. I replace direct function calls by wrapper [1], so there would be a single place for platform-dependent code [2]. Another example would be a getter of command line arguments. We have Params member in the instance of Core object, but the project uses win32 GetCommandLine() function everywhere. There is no a big fixup commits, but a growing number of small commits, which fix some small bit here and there. The good thing of such small commits is that they can be tested, reviewed and accepted into the main repository right now.

The biggest news since the last article is that Jules decided to drop the previous engine he was working on (Clear Sky from the original S.T.A.L.K.E.R.) and moved instead to the latest version of the engine (the one from Call of Pripyat). This bumps up the requirements from DX9 to DX10-11 code, but there is no expected impact in terms of OpenGL requirements (3.3 should be the standard in the final version).

Jules: When I was working on Clear Sky I was only focusing on the DX9 backend, while ignoring the DX10 backend that is also present. Now that I’m making a new version for Call of Pripyat I will port the DX10 backend from the start. However, while the DX10 and DX11 backends are very similar I will postpone DX11-level features to reduce complexity somewhat.

There is a new layer of complexity coming from how DX10-11 treats the shaders.

Jules: On the shaders side, DX10 HLSL shaders are not that different from DX9 shaders, except for one crucial part which is texture sampling. To show a texture in the game you need to have a texture image with the image data and a sampler object that describes how the image should be displayed. In DX9 and OpenGL the engine code has to combine the texture image and the sampler object and send it to the shader as one sampler object. DX10 on the other hand sends the texture image and the sampler object to the shader separately and the shader is free to combine them in any way it sees fit.

This is a major problem, since we don’t know beforehand which combination the shader will make. So to port DX10 shaders I have to look up which combinations the shader makes and provide the appropriate combinations to the GLSL version of the shader. It is one of the few differences between DirectX and OpenGL that hasn’t been solved by an extension yet. Luckily most of the DX10 shaders are actually based on the DX9 versions of those shaders, so most of the time I can just provide the same combination of textures and sampler objects that I would provide to the DX9 version of the shader.

So now, progressively all these pieces are getting together. You might be wondering how long it will actually take to reach a first port for Linux.

Pavel: There are huge amounts of work to be done. Engine SDK is one of the most significant parts of this work, and since we’re not planning to include it into port, things are getting much better. I’m looking forward working on multiplayer server redesign: aside from portability, there are a lot of things to simplify and optimize there.

Alexandr: My plan is to complete Linux port of xrCore this winter (February) and to have initial port of window, input and render systems at the end of the Spring (May).

Since all of them are working on refactoring the code, there is also the clear opportunity to improve the on existing parts of the engine, but that’s not for now - and they want to stay as faithful as possible to the original game.

Jules: We’ll work on providing more polish, but ultimately we’d like to keep the game as close as possible to the vanilla game. Instead of adding more gameplay features, we want to provide a good, well-maintained codebase for other modders to fork and base their mods upon.

Alexandr: I think we would improve the technical side of the game, but keep the original gameplay. I would like to see improved multiplayer and AI.

As usual, if you are interested to give a hand to the team, please consider joining the #openxray channel on Freenode (IRC).

Since some folks on r/linux_gaming were discussing the legal aspects of this port, it is appropriate to clarify the following:

• This port is not sanctioned by GSC in any way at this stage - and they remain the copyright holders of all the original source code.
• The current team on this port would like to get their official permission to work on this as they move forward with development.
• The team has actively tried to contact GSC on that matter, but so far there was no answer from their side.
• Despite their silence, development continues, and GSC has had a track record of actively supporting the modding community, so it seems they would be less likely, than say, folks like Blizzard, to issue to “cease and desist” notice. Especially since there were several mods already using the leaked source code.

This being said, if GSC does issue such a request, the team would basically stop their work and drop the port and comply. So, while the risk still remains out there, Alexandr, Jules and Pavel are very much on their way to release something within 2016. Let’s hope that their effort does not go to waste, as there’s many of us in the Linux gaming community who would really like this project to see the light of day.

And to end this article, here’s a recent video of the latest OpenGL build (not running on Linux yet / The video password requirement should be waived off soon):

https://vimeo.com/145925044