Linux playground

[Col Brubaker]

Whatever you come up with now. It would be nice, if somebody could write a serious manual, for non-coding Orbinauts.
It is not easy for an average Linux-user, to get all the informations from this threat, to install it.

 

[Lucy]

Whatever you come up with now. It would be nice, if somebody could write a serious manual, for non-coding Orbinauts.
It is not easy for an average Linux-user, to get all the informations from this threat, to install it.

The ultimate goal (IMO) would be to ship a .zip package built for linux, in much the same way Orbiter is shipped for Windows for normal users. Being able to compile orbiter yourself is probably always going to require some specific knowledge that would be unreasonable to expect people to have who just want to play.

 

[Col Brubaker]

The ultimate goal (IMO) would be to ship a .zip package built for linux, in much the same way Orbiter is shipped for Windows for normal users. Being able to compile orbiter yourself is probably always going to require some specific knowledge that would be unreasonable to expect people to have who just want to play.

Nothing wrong with people who just want to play! It is a flight-simulator. But give them a proper manual, The specific knowledge I have. I've done it 3x now. With annoying Matias a lot. Cause nobody thought about that. That keeps the community small. Not more coders join, to working on it. And then the project dies. And there are a lot of others, who could do it. With a manual, where somebody thought about them. - Nothing wrong with people who work with a manual, or a check-list! They are called pilots.
And even little idiots can come up with interesting flight-controller-arrays.

PS: Please send me your flight-controller-module in a .json-file, by upload-link, to my pn. I try to build a unified-flight-controller.

 

[Sword7]

The ultimate goal (IMO) would be to ship a .zip package built for linux, in much the same way Orbiter is shipped for Windows for normal users. Being able to compile orbiter yourself is probably always going to require some specific knowledge that would be unreasonable to expect people to have who just want to play.

Yes, I agreed with that. Make sure that we can compile documents into PDF on Linux as well. DLL files are not needed. Just remove DLL files for Linux distro. That needs be all done for zip package.

 

[Gondos]

Please be reminded that this is a proof of concept branch, it's not intended to be a maintained fork in all its glory.
Its goal was to prototype and hopefully learn enough from it so that we can make proper educated decisions regarding having a cross platform OpenOrbiter.

 

[Linguofreak]

The main blockers that I see are :

• WinAPI
• DirectInput
• D3D GC
• HDC usage (and API breakage if we get rid of it)
• Launchpad "architecture"

For the Windows API, we could use SDL or glfw. I used glfw in the past but it looks like it's not being given much love lately, and the new SDL3 version is not ready yet I think. I was hoping things would progress a bit more than they did but that's life. Both options provide a replacement for DirectInput too.
For dialogs, I did some prototyping with ImGui, the dark windows are using it in this video :

However since it's using immediate mode, I'm not sure people are accustomed to it.
For GC, jarmonik hinted that he could do some work with Vulkan but I don't know if it's still on his agenda. The current OpenGL GC would be a big step backward compared to the current D3D9 client.
The way the launchpad is started to then launch a scenario makes it awkward to provide an OS agnostic option because the GC is not yet available.
In the linux branch I hacked around to instanciate the GC client from the get go and replaced the launchpad with an ImGui window.
I'm no artist so the result is not that pretty. You can see what it looks like at the beginning of this clip (along with mouse clickable menus, notifications, node base joystick configuration, external MFDs and a subpar XR5 ascent to orbit) :

How much could Winelib help with the transition?

 

[Gondos]

How much could Winelib help with the transition?

I have no idea, the last time I tried (a while ago) I couldn't get anything to work. There were compilation errors in the wine include files themselves. Maybe a wrong version or the cmake files not compatible, I don't know. I gave up because I don't see much point, you might as well use the windows version with wine.

 

[Linguofreak]

I have no idea, the last time I tried (a while ago) I couldn't get anything to work. There were compilation errors in the wine include files themselves. Maybe a wrong version or the cmake files not compatible, I don't know. I gave up because I don't see much point, you might as well use the windows version with wine.

The potential advantage would be the ability to incrementally replace calls to the Windows API as work on the Linux build progresses. If you have to replace every Windows API call before the thing will even compile, that's a lot of work up front, whereas if you can replace things piecemeal while leaving the things you haven't gotten to yet exactly as they are in the Windows build with full functionality, I'd think that would make things a lot easier.

Of course, if it's too much work to get Winelib working, you don't actually gain anything.

 

[Gondos]

The work as already been done, now it's a matter of putting the pieces together. I'm working on a PR to integrate ImGui here.
Even if we get it to compile with winelib, how can we be sure when we make changes that it'll compile without it in the end? The main advantage I see is if someone who does not work on Windows wants to contribute.

 

[Sword7]

I tried to run orbiter with orbiter 2024 data pack but, it crashed with segmentation fault. It only worked with orbiter 2016 data pack.

Use orbiter 2016 data pack to run Orbiter for Linux at this time.

Tim

 

[Sword7]

I re-installed Ubuntu 25.04 on my new SSD drive with faster USB 3,2 gen 2x2 enclosure.

Required libraries for Ubuntu:

sudo apt install doxygen libfontconfig-dev libglfw3-dev libsndfile1-dev libglm-dev libopenal-dev

But I tried to compile orbiter but got some linking errors.

make[2]: *** No rule to make target '/usr/lib64/libfontconfig.so', needed by 'OVP/OGLClient/libOGLClient.so'. Stop.
make[1]: *** [CMakeFiles/Makefile2:5530: OVP/OGLClient/CMakeFiles/OGLClient.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

I quickly resolved working-around solution.

sudo ln -s ../lib/x86_64-linux-gnu/libfontconfig.so /usr/lib64/libfontconfig.so
sudo ln -s ../lib/x86_64-linux-gnu/libopenal.so /usr/lib64/libopenal.so
sudo ln -s ../lib/x86_64-linux-gnu/libsndfile.so /usr/lib64/libsndfile.so

I tried that again and successfully compiled orbiter completely. Then I installed them. I was able play orbiter.

Tim

 

[JDat]

I re-installed Ubuntu 25.04 on my new SSD drive with faster USB 3,2 gen 2x2 enclosure.

Required libraries for Ubuntu:

sudo apt install doxygen libfontconfig-dev libglfw3-dev libsndfile1-dev libglm-dev libopenal-dev

But I tried to compile orbiter but got some linking errors.

make[2]: *** No rule to make target '/usr/lib64/libfontconfig.so', needed by 'OVP/OGLClient/libOGLClient.so'. Stop.
make[1]: *** [CMakeFiles/Makefile2:5530: OVP/OGLClient/CMakeFiles/OGLClient.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

I quickly resolved working-around solution.

sudo ln -s ../lib/x86_64-linux-gnu/libfontconfig.so /usr/lib64/libfontconfig.so
sudo ln -s ../lib/x86_64-linux-gnu/libopenal.so /usr/lib64/libopenal.so
sudo ln -s ../lib/x86_64-linux-gnu/libsndfile.so /usr/lib64/libsndfile.so

I tried that again and successfully compiled orbiter completely. Then I installed them. I was able play orbiter.

Tim

So... It works on Linux now? Linux thinkerers like me can compile, test and and fly? Interesting... I'll git clone and try it myself.

 

[Matias Saibene]

Hi @Gondos,
I mustered up some courage and decided to explore the source code for the Orbiter Linux graphical client to see if I could apply what I learned in LearnOpenGL. The thing is, I changed the values for nearplane = 0.0f; and farplane = 1e11f; to nearplane = 0.1f; and farplane = 5e9f; respectively, in addition to changing LogDepth.inc to match, and performance on my machine improved. It's now a bit smoother.

I'm attaching the output of the glxinfo command so you know what my machine's specifications are, in case it's helpful. My machine isn't great, but it works!

 

[Gondos]

Maybe the nearplane at 0 triggers a slow path in the polygon culling, I don't really know. Make sure you don't have artifacts because the dynamic range required to draw planets can be high...

 

[jarmonik]

Nearplane 0.0f will causes a fault. Must be higher than zero and as large as possible. Orbiter uses 0.1f or 1.0f for VC and exterior values varies by camera-vessel, camera-ground distance from 0.1 to 1e3. Farplane is non-critical.

 

[Sword7]

I tried to run orbiter on Ubuntu 26.04. OGL client crashed after launching from menu. There are no log files. Ubuntu 26.04 replaced old X11 code with new Wayland for HDR support.

 

[Matias Saibene]

I tried to run orbiter on Ubuntu 26.04. OGL client crashed after launching from menu. There are no log files. Ubuntu 26.04 replaced old X11 code with new Wayland for HDR support.

I use Manjaro with Wayland (KDE) and the OpenGL client works fine. Have you tried looking for the Orbiter log (Orbiter.log) in /tmp?

 

[Sword7]

I use Manjaro with Wayland (KDE) and the OpenGL client works fine. Have you tried looking for the Orbiter log (Orbiter.log) in /tmp?

When OpenGL client starts, it just displayed blue screen but, immediately crashed. Here is log file did not say anything wrong

000000.000: Finished setting up render state
000000.000:
000000.000: **** Creating simulation session
000000.000: VSOP87(E) Sun: Precision 1.0e-06, Terms 554/6634
000000.000: VSOP87(B) Mercury: Precision 1.0e-05, Terms 167/7123
000000.000: VSOP87(B) Venus: Precision 1.0e-05, Terms 79/1710
000000.000: VSOP87(B) Earth: Precision 1.0e-08, Terms 2564/2564
000000.000: ELP82: Precision 1.0e-05, Terms 116/829
000000.000: VSOP87(B) Mars: Precision 1.0e-05, Terms 405/6400
000000.000: VSOP87(B) Jupiter: Precision 1.0e-06, Terms 1624/3625
000000.000: VSOP87(B) Saturn: Precision 1.0e-06, Terms 2904/6365
000000.000: SATSAT Mimas: Terms 113
000000.000: SATSAT Enceladus: Terms 33
000000.000: SATSAT Tethys: Terms 101
000000.000: SATSAT Dione: Terms 59
000000.000: SATSAT Rhea: Terms 68
000000.000: SATSAT Titan: Terms 100
000000.000: SATSAT Iapetus: Terms 605
000000.000: VSOP87(B) Uranus: Precision 1.0e-06, Terms 1827/5269
000000.000: VSOP87(B) Neptune: Precision 1.0e-06, Terms 391/2024
000000.000: Finished initialising world
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: CreateVariableDragElement
000000.000: At least one active module is accessing an obsolete interface functi
on.
000000.000: Addons which rely on obsolete functions may not be compatible with
000000.000: future versions of Orbiter.
000000.000: ---------------------------------------------------------------
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: Finished initialising panels

I decided to run gdb and it crashed in CloudTile::Render();

Thread 1 "Orbiter" received signal SIGSEGV, Segmentation fault.
0x00007ffff75001dd in CloudTile::Render() ()
from Modules/Plugin/libOGLClient.so
(gdb) bt
#0 0x00007ffff75001dd in CloudTile::Render() ()
at Modules/Plugin/libOGLClient.so
#1 0x00007ffff7501f0b in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#2 0x00007ffff7501fe0 in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#3 0x00007ffff7501fe0 in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#4 0x00007ffff7501fe0 in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#5 0x00007ffff7501fe0 in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#6 0x00007ffff7501fe0 in void TileManager2Base::RenderNode<CloudTile>(QuadTreeNode<CloudTile>*) () at Modules/Plugin/libOGLClient.so
#7 0x00007ffff7500ab5 in TileManager2<CloudTile>::Render(MATRIX4&, vPlanet::RenderPrm const&) () at Modules/Plugin/libOGLClient.so
#8 0x00007ffff74da6cb in vPlanet::RenderCloudLayer(unsigned int, vPlanet::RenderPrm const&) () at Modules/Plugin/libOGLClient.so
#9 0x00007ffff74d98cd in vPlanet::Render() ()
at Modules/Plugin/libOGLClient.so
#10 0x00007ffff74bf071 in Scene::Render() () at Modules/Plugin/libOGLClient.so
#11 0x00007ffff7503ce4 in OGLClient::clbkRenderScene() ()
at Modules/Plugin/libOGLClient.so
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x000055555570a13d in Orbiter::Render3DEnvironment() ()
#13 0x000055555570a480 in Orbiter::Run() ()
#14 0x0000555555706ab9 in main ()
(gdb)

 

[Gondos]

When OpenGL client starts, it just displayed blue screen but, immediately crashed. Here is log file did not say anything wrong



I decided to run gdb and it crashed in CloudTile::Render();

The main launch window is rendered via the OGLClient so it's not an OpenGL initialization issue. Are you using a 'vanilla' install?

 

[Sword7]

The main launch window is rendered via the OGLClient so it's not an OpenGL initialization issue. Are you using a 'vanilla' install?

Yeah. I am using vanilla install (fresh install). Should I install Nvidia drivers or so?