Skip to content

Multiplatform

djewsbury edited this page Feb 26, 2015 · 1 revision

Multi-platform strategy

XLE is designed to be inherently multi-platform. But what does that really mean?

Personally, every engine I've ever used or written has been multi-platform. Most of my experience has involved working with low-level console technology, while also supporting higher level PC ports.

So while XLE is mostly focused on PC (and DirectX) now, it is designed to expandable to support many platforms (both platforms that exist now, and platforms that might come in the future).

What does it mean to be multi-platform?

Any engine can be made to run on more than one platform. But how do we do it right?

In part, designing for multi-platform means targeting goals such as:

  1. reduce the time it would take to port to a new platform
  2. reduce the amount of platform-specific work
  3. maximize the possibilities of using each platform's unique hardware capabilities
  4. avoid common cases of conflicts between platforms (eg, changes for one platform breaking another platform)
  5. support variations in data between various platforms

All of these goals are important. But some are in conflict with others. For example, engines that are really good for goal 1) actually tend to do poorly with goal 3).

So, sometimes we need a bit of a balancing act to between these goals.

Current status of Android support

There is some Android support built into the library currently. Once, this worked really well! But this hasn't been compiling for awhile (unfortunately). Also, the shaders are HLSL-only (and won't support GLSL for Android immediately). A game made with XLE for Android or IOS is likely to require different shader behaviour than the PC version (probably something a little simplier). However, the structure of the shader system means that it should be possible to write the core GLSL shaders very quickly.

If you are interested in up-to-date Android support, please send a message to the development team!

Underlying graphics layer on Win32

On Windows, there are many options for underlying graphics API:

  • DX11
  • DX9
  • OpenGL
  • Mantle
  • (eventually, DX12, DX13, etc...)

DX11 supports all modern graphics cards (even DX9 graphics cards), and works on all versions of windows from Vista onwards. The only thing it doesn't support is Windows XP.

This means that some games support DX9 just for Windows XP. However, there is another way to support Windows XP -- and that is with OpenGL. OpenGL is also really flexible: it has variants for Linux, MacOS, Android, IOS.

It seems redundant and wasteful to support DX9, when OpenGL has many more options. For that reason, development on XLE will focus on 2 underlying APIs:

  • DX11 (/12/etc) -- for Windows-based platforms
  • OpenGL variants -- for Linux, MacOS, Android, IOS, other future platforms

Internally, the architecture of the RenderCore library was built around DX11. This was a carefully considered decision.

The core principles of the DX11 API are generally well suited to the hardware, and the engine behaviour we want. In comparison, the architecture of DX9 was relatively poorly suited. And OpenGL is actually quite low level, so doesn't provide much structure at all.

Designing around DX11 means that code for Windows will work in a simple and native-feeling way. We can also use OpenGL in a DX11-like way (because OpenGL is naturally flexible for using in different ways). It also means that we're more likely to be able to support future versions of DirectX.

Windows based tools

Tools in XLE being developed natively for Windows. This may be inconvenient for teams targeting Linux or MacOS as their primary platform. This is mostly to reduce the surface area / testing requirements for the tools. Also Windows-only tools has many advantages:

  • Visual Studio and .Net is a great platform for building GUI things
  • XLE tools need to rely on open-source GUI elements (and there are a lot for .net)
  • C++/CLI integration with C++ is just really handy, and so powerful

It's difficult to get those same advantages if the tools need to be multi-platform.