Skip to content

Platform porting work

Jump to bottom
Jan Krassnigg edited this page Feb 17, 2021 · 6 revisions

This page lists some of the work that would need to be done to port ez to other platforms.

Gathering Information

It would be helpful if someone tracks down missing pieces. E.g. exactly which code paths need to be implemented, and what other work may be necessary. It's probably easiest to follow the platform defines (see below).

Low Level

Low level OS specific functionality is found in Foundation and Core.

Platform specific code paths are always guarded with

#if EZ_ENABLED(EZ_PLATFORM_XYZ)

Available platform defines are

  • EZ_PLATFORM_WINDOWS
  • EZ_PLATFORM_WINDOWS_UWP
  • EZ_PLATFORM_WINDOWS_DESKTOP
  • EZ_PLATFORM_LINUX
  • EZ_PLATFORM_OSX
  • EZ_PLATFORM_IOS
  • EZ_PLATFORM_ANDROID

All code paths are implemented for Windows Desktop. Many code paths are not implemented for other platforms. Many such implementations should be straight forward, so starting here to fill the gaps would be a great contribution.

There are unit tests for nearly all these features, which are simply deactivated for most platforms. Look for a test (in the FoundationTest project) and enable it, to get a test case.

Renderer

There is currently only a DX11 implementation of the renderer. Long term, having a Vulkan implementation would be great. See the Vulkan roadmap.

Shaders

Shaders are written in HLSL and directly compiled to DXIL for D3D11. Support for the DXC backend has been implemented. This allows to compile our HLSL shaders to SPIR-V. This has not been tested though.

Old OpenGL code

In git commit 4162de4dd8eb2bdb0e654d5eb36b05b187cba3e1 we removed an OpenGL implementation of RendererFoundation. It had not been maintained in a long time and was outdated and probably didn't even compile anymore even at that point. However, IF anyone wants to look into doing an OpenGL (4) implementation, this would at least be a starting point.

Window + Input

There is a very old SFML binding to create a window and get input from the OS. See the Core > System > Implementation. This had been done on Windows many years ago. A good start would be to

  1. Start on Windows (switch the used impl from native to SFML) and get the SFML implementation running again. It is unclear whether the current implementation still compiles.
  2. Upgrade to the latest SFML version.
  3. With these changes, sample projects such as Asteroids, or the Texture Sample should work fine.
  4. Build a very simple app with it that doesn't use the renderer at all (only create a window and log some input).
  5. Switch to a different platform and make it work there, as well.

Editor

The editor is Qt based and we tried not to use platform specific code unless absolutely necessary. However, porting the editor is not realistic, before a renderer is fully working. If this is ever the case in the future, here are potential problems:

  • The editor sends messages between its processes using Windows pipes. This can easily be replaced with a different scheme, e.g. we originally used a shared memory based approach, unless you care for low lag. For best performance a similar approach would be needed.
  • The editor launches various external processes, such as the EngineProcess, TexConv and the Player. All of these are launched as '.exe' files.

Tools

An interesting project may also be to start with porting the smaller tools to OSX or Linux:

  • ArchiveTool and TexConv are command line tools. There are probably only small things to implement, such as the file system iterator. These are probably a great way to start.
  • Inspector is a Qt based application. Except for the UI, it should be fairly straight forward, the only other dependency (Enet for networking) should already work on all platforms.
Clone this wiki locally