Compiling Orbiter and addons directly on Linux

yitianetie

Member
Joined
Mar 24, 2020
Messages
50
Reaction score
18
Points
23
Location
Brittany
Hi,

I know that some people have tried to compile Orbiter on Linux with a lot of issues. On my side, I begin to seriously think of a manner to compile Orbiter on Linux but it is not an easy task.

I think also about the rendering engine which use DirectX. To be compatible as cross-platform software, we should switch to Vulkan.
And I wonder whether we could compile Orbiter and addons without visual studio and windows specific librairies...
 
Last edited:

supersonic71

Member
Joined
Sep 20, 2021
Messages
59
Reaction score
86
Points
18
Location
Asia Pac
Website
github.com
From reddit user CodeYeti :
Just so you know, it runs perfectly fine with Wine+DXVK. I've been on Linux for about a decade, and Orbiter has never been an issue.

I was just saying that with just regular old wine and DXVK, it's been working for me, which may help some others while we wait for more native options. Personally, I've been using winebuild (winegcc / wineg++) to build some wrappers for plusins I built on Linux as well
https://www.reddit.com/r/Orbiter/comments/oslsn8
 

mkwt

New member
Joined
Dec 15, 2022
Messages
2
Reaction score
4
Points
3
Location
Earth
There's another thread on this forum where someone has started work on exactly this. You can find the code at https://github.com/TheGondos/orbiter. And also check out the thread here.

The main issues identified so far:
  • Graphics backend. D3D9 client is right out. An OpenGL client is in.
  • XRSound addon is up and working, using the OpenAL library as the backend. I don't know if this is also the case on main Orbiter or original XRSound or not.
  • The launcher is using a different widgets / UI library. Or it may have been rewritten entirely.

Now here are some of the more nitty and gritty portability hurdles. A key part of this the "Orbiter SDK". This is the interface that allows addons like vessels and MFDs to run within the main Orbiter executable. If you want Orbiter to work as a multi-platform application, this Orbiter SDK cannot depend on any single operating system.
  • Windows filenames are case insensitive: README.txt and readme.TXT are the same file. But Linux treats those as two separate files. The Orbiter code base (written for Windows) has "#include <OrbiterSDK.h>" mixed in with "#include <orbitersdk.h>" and other capitalization variants. In order to compile on Linux, you have to agree on one spelling.
  • Orbiter SDK header files use some data types from a header file called Windows.h, which is provided by Microsoft for development on Microsoft Windows. The most prominent of these is DWORD, which can usually be replaced by int, but doing that in all of core Orbiter and all of the addons is a lot of churn.
  • It seems like Orbiter on Windows is / was built on the Microsoft Visual C++ compiler with the default settings. These settings are more relaxed than the default settings on the default Linux compilers (GCC or clang). The most prominent example here is that a string appearing in the source has to have the type "const char*" not "char*". This has long been required by the ISO C and C++ standards, but Microsoft Visual C++ allows you to get away with it unless you change one of the settings.
  • The Orbiter SDK includes some components from Microsoft Windows related to graphics, particularly in how MFDs get drawn. This means that all of those addons are talking to main Orbiter in a language (things like "draw this circle here") that depends on Windows. (If interested in the details, this is the Windows "Graphics Device Interface", stuff like HPEN, HBRUSH, and HDC).
  • Some popular addons go behind the Orbiter SDK's back and talk to Windows directly to draw graphics outside of the SDK sketchpad functions, to play sounds, or to do other stuff (networking, perhaps).
 
Top