Linux playground

[Gondos]

Hi everyone,

I am particularly impressed by your replies and screenshots. Despite the artifacts and bugs, It seems promising. I will try on my side later when I will be more available. Just a question about the MFD : I remember when i tried Orbiter with wine and Vulkan, I got huge performance drop with some sophisticated MFDs, especially on XR fleet, and not so on Windows. Do you still have this performance drop with the native version you are testing ?

Warmest regards

Thanks
I can't tell about the MFD, it really depends on which one it is. Maybe it's using GDI instead of sketchpad and wine is having trouble with that, or the D3D emulation is the cause, who can tell... If you're talking about the Map MFD, it's been converted to sketchpad and does not impact performance that much...

 

[Matias Saibene]

I still have no luck getting the + key to apply thrust.
Maybe something in the code?

 

[yitianetie]

Hi,

I have an issue while trying to compile at around 7% : I get the error below :

[  7%] Building CXX object Addons/NASSP/CMakeFiles/Crawler.dir/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp.o
In file included from /home/yitianetie/Jeux/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp:34:
/home/yitianetie/Jeux/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_sys/soundlib.h:28:10: fatal error: XRSound.h: Aucun fichier ou dossier de ce type
   28 | #include "XRSound.h"
      |          ^~~~~~~~~~~
compilation terminated.
make[2]: *** [Addons/NASSP/CMakeFiles/Crawler.dir/build.make:76 : Addons/NASSP/CMakeFiles/Crawler.dir/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp.o] Erreur 1
make[1]: *** [CMakeFiles/Makefile2:3955 : Addons/NASSP/CMakeFiles/Crawler.dir/all] Erreur 2
make[1]: *** Attente des tâches non terminées....
[  7%] Linking CXX executable meshc
[  7%] Built target meshc
[  7%] Built target CopyData
[  7%] Built target XRSound_assets
make: *** [Makefile:156 : all] Erreur 2

real    1m4,098s
user    0m16,083s
sys    0m4,194s

The end of the third line is written in french but it means :
fatalerror: XRSound.h : No file or folder of this type.

It seems that a file is missing but I am wondering if the reason comes from the git repository or a problem in the download process...

 

[Gondos]

Hi,

I have an issue while trying to compile at around 7% : I get the error below :

[  7%] Building CXX object Addons/NASSP/CMakeFiles/Crawler.dir/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp.o
In file included from /home/yitianetie/Jeux/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp:34:
/home/yitianetie/Jeux/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_sys/soundlib.h:28:10: fatal error: XRSound.h: Aucun fichier ou dossier de ce type
   28 | #include "XRSound.h"
      |          ^~~~~~~~~~~
compilation terminated.
make[2]: *** [Addons/NASSP/CMakeFiles/Crawler.dir/build.make:76 : Addons/NASSP/CMakeFiles/Crawler.dir/Orbitersdk/samples/ProjectApollo/src_launch/Crawler.cpp.o] Erreur 1
make[1]: *** [CMakeFiles/Makefile2:3955 : Addons/NASSP/CMakeFiles/Crawler.dir/all] Erreur 2
make[1]: *** Attente des tâches non terminées....
[  7%] Linking CXX executable meshc
[  7%] Built target meshc
[  7%] Built target CopyData
[  7%] Built target XRSound_assets
make: *** [Makefile:156 : all] Erreur 2

real    1m4,098s
user    0m16,083s
sys    0m4,194s

The end of the third line is written in french but it means :
fatalerror: XRSound.h : No file or folder of this type.

It seems that a file is missing but I am wondering if the reason comes from the git repository or a problem in the download process...

Oopsy, it's a dependency issue that happens now that I tried to fix XRVessels compiling everytime. Man, I hate cmake...
I reverted the faulty commit. Note that some dependency issues are still lurking around and for now the solution is just to restart the build and hope it'll fix itself ?
T'inquète pour le français, je gère

 

[Gondos]

I still have no luck getting the + key to apply thrust.
Maybe something in the code?

Can you use ctrl+'+' to work around the issue for now?

 

[Matias Saibene]

Can you use ctrl+'+' to work around the issue for now?

Sorry for the delay. [CTRL][+] works wonders! Thanks.

Taking off a open source bird in a open source simulator in a open source operating system.

 

[doseijin]

Thank you for making this! I can second that the (void *) NULL was necessary to compile on gcc 12.1.0, but apart from that I didn't encounter many other issues, although I had to make a syslink to /usr/share/fonts/liberation from /usr/share/fonts/truetype because my distro doesn't have that structure. The sketchpad window dragging seem to behave weirdly in my awesomewm install however, tomorrow I'll try investigating what's causing that, might be a window hint issue but it's too late to check right now. I'll try to contribute in whatever way I can.

 

[Gondos]

Thank you for making this! I can second that the (void *) NULL was necessary to compile on gcc 12.1.0, but apart from that I didn't encounter many other issues, although I had to make a syslink to /usr/share/fonts/liberation from /usr/share/fonts/truetype because my distro doesn't have that structure. The sketchpad window dragging seem to behave weirdly in my awesomewm install however, tomorrow I'll try investigating what's causing that, might be a window hint issue but it's too late to check right now. I'll try to contribute in whatever way I can.

Welcome aboard
Maybe I can add the font in the repo but fonts can be big...
You mean this issue? I'm plagued by it too even though it's marked as closed, but it can be that my glfw is too old.
I'm pondering about switching to SDL because I also have keyboard issues sometimes that look like this one, but occur randomly (I'm on an AZERTY keyboard here but I don't switch locales). IIRC, sometimes killing firefox fixes the issue, go figure...

 

[doseijin]

Welcome aboard
Maybe I can add the font in the repo but fonts can be big...
You mean this issue? I'm plagued by it too even though it's marked as closed, but it can be that my glfw is too old.
I'm pondering about switching to SDL because I also have keyboard issues sometimes that look like this one, but occur randomly (I'm on an AZERTY keyboard here but I don't switch locales). IIRC, sometimes killing firefox fixes the issue, go figure...

That might be the issue, but it could also be something on my window manager, it's not too bad anyway
The ideal solution for the font issue would be using fontconfig I think, so it automatically detects the font location and fallbacks when necessary, I think I'll try implementing that now that I have time, seems simple enough
I was investigating earlier the module loading system because it seems what's causing problems when trying to exit the game, the GC module is being unloaded before the others, which is causing issues when Project Apollo tries releasing fonts, which makes me wonder why that isn't an issue on the native Windows version, but maybe we could separate modules on stages separated by folders, or have some more flexible module loader system rather than just DLL/so's inside a folder, but that would require quite a lot of restructuring, so maybe just separating it by them being GCs or not is good for now

 

[Gondos]

That might be the issue, but it could also be something on my window manager, it's not too bad anyway
The ideal solution for the font issue would be using fontconfig I think, so it automatically detects the font location and fallbacks when necessary, I think I'll try implementing that now that I have time, seems simple enough
I was investigating earlier the module loading system because it seems what's causing problems when trying to exit the game, the GC module is being unloaded before the others, which is causing issues when Project Apollo tries releasing fonts, which makes me wonder why that isn't an issue on the native Windows version, but maybe we could separate modules on stages separated by folders, or have some more flexible module loader system rather than just DLL/so's inside a folder, but that would require quite a lot of restructuring, so maybe just separating it by them being GCs or not is good for now

Thanks for the PR, I just merged it
Regarding the modules, IIRC on windows, they declare a type in their resource section so the core knows when one is a GC and can act accordingly. We could do the same with a static string or a "GetModuleInfo" function I guess. I'm postponing this till I work something out for the module configuration tab where this information is currently used to create the treeview in the windows version.
Still on my quest for a fix for the offset issue after staging on NASSP but so far I'm stuck. I'm rewriting some parts where I diverged from the D3D client to follow it more closely and see if that'll help, but so far, no good? Must be something so obvious I can't see it
At least it resulted in some small improvements graphics-wise:

Some base buildings lack shadows, can anyone confirm it's not the case with the D3D client?

 

[Jordan]

Some base buildings lack shadows, can anyone confirm it's not the case with the D3D client?
View attachment 29240

All buildings have shadows in D3D9

 

[Gondos]

All buildings have shadows in D3D9

Thanks, are they from shadow maps or projected polygons + stencil buffer? The D3D7 client does not use shadow maps.

 

[Jordan]

Thanks, are they from shadow maps or projected polygons + stencil buffer? The D3D7 client does not use shadow maps.

I have no idea, maybe @jarmonik can give you a better answer.

 

[doseijin]

Thanks for the PR, I just merged it
Regarding the modules, IIRC on windows, they declare a type in their resource section so the core knows when one is a GC and can act accordingly. We could do the same with a static string or a "GetModuleInfo" function I guess. I'm postponing this till I work something out for the module configuration tab where this information is currently used to create the treeview in the windows version.

I'll try looking into it soon, temporarily I'm just loading it with a separate string on the cfg file that sets the GC module. I'm trying to get the program to properly exit when pressing the menu info bar button, and while doing so I would guess we would have to move at least the window creation part of OGLClient over to the Orbiter part, and then letting the GC set or not set the OpenGL context, if we're staying with GLFW anyway. I don't have much DirectX experience, but it seems like it's possible for the DirectX client to work on GLFW, along with Vulkan and most other graphics APIs, so staying on GLFW seems reasonable for a cross platform port of Orbiter but SDL seems like a sensible choice as well, and might be easier to deal with other renderer backends. What do you think? I'm just now starting to familiarize myself with the codebase though, and I guess should put off changing too much stuff around until you push the new client code
After this making the d3d client work with the current code should be more viable, along with any other clients like Skybolt etc. I've seen some really great screenshots of Skybolt and can't wait to run that natively on Linux too.

 

[Gondos]

I'll try looking into it soon, temporarily I'm just loading it with a separate string on the cfg file that sets the GC module. I'm trying to get the program to properly exit when pressing the menu info bar button, and while doing so I would guess we would have to move at least the window creation part of OGLClient over to the Orbiter part, and then letting the GC set or not set the OpenGL context, if we're staying with GLFW anyway. I don't have much DirectX experience, but it seems like it's possible for the DirectX client to work on GLFW, along with Vulkan and most other graphics APIs, so staying on GLFW seems reasonable for a cross platform port of Orbiter but SDL seems like a sensible choice as well, and might be easier to deal with other renderer backends. What do you think? I'm just now starting to familiarize myself with the codebase though, and I guess should put off changing too much stuff around until you push the new client code
After this making the d3d client work with the current code should be more viable, along with any other clients like Skybolt etc. I've seen some really great screenshots of Skybolt and can't wait to run that natively on Linux too.

Oh boy, are you right about Skybolt, that's why I don't intend to go further than D3D7 quality with the current OpenGL code, there would be no point in trying to do something even remotely similar (way beyond my skills too). But right now I'm stuck with OpenGL3.3 hardware so I'll keep working on it. Anyway, I think it's a good compromise to have a low requirement GC available, I don't know what kind of hardware is needed to have Skybolt run decently
This guy could get DX11+GLFW+ImGui to work on Windows so yeah it should be possible (well, that is the point of using GLFW in the first place^^). There is a chicken and egg problem in any case because once you get rid of the Windows API, you need a GC to show the launchpad, and you configure the GC via the launchpad...
So we need a fallback GC that works everywhere.
Hum, maybe use a minimal backend for the launchpad and fork/CreateProcess a new full-featured instance when starting a scenario? (not a fan...)
Or, use something like Qt but I'm not a fan of these frameworks, the "bloat-free" argument of ImGui really appeals to me, you add 3 files in your project and you're done, no need to install gigabytes of dependencies because you want to show a button.
I see you've fixed the crash on ExitModule in your branch, next you'll be stuck on joining the tile loading threads that are currently quite messed up. I hope I'll be able to fix them with the GC rework. If you want a quick and dirty workaround, you can "exec" the main program?

 

[Urwumpe]

When setting up a new project, is there anything to be considered for future compatibility with Linux? As I see, CMake runs fine as always,

 

[Gondos]

When setting up a new project, is there anything to be considered for future compatibility with Linux? As I see, CMake runs fine as always,

Off the top of my head :

• be careful with your filenames since most linux filesystems are case sensitive (Orbitersdk.h vs orbitersdk.h vs OrbiterSDK.h) and use "/" in your paths (windows supports both / and \, linux doesn't)
• use XRSound if you need sound
• don't put resources in your DLL (mostly used for bmp files)
• use sketchpad instead of GDI
• try to minimize usage of Windows types (DWORD, FLOAT and the like). You cannot avoid it completely since some oapi functions use them but it'll minimize future work
• don't use closed source dependencies (spacecraft3 and the like), that's a show stopper (except if you are the maintainer of said closed stuff of course)
• if you author textures, don't use bleeding edge compression formats that won't have good support on linux
• unrelated to linux but in case you want to open source your work, consider using a GPLv3 compatible license to make redistribution easier (CC-BY-NC is not BTW, it's not even made for source code). A good compromise if you want to prevent people from making profit with your work, is to use a FOSS license for the code and CC-BY-NC for art assets. Of course if your project is code only, that doesn't work ?
  
• the best for last : DO NOT USE MS "SECURED" STRING FUNCTIONS. sprintf_s, sscanf_s and the like are MSVC only. I could not find an alternative that implements every aspects of them and had to remove them completely from NASSP for example (if someone can prove me wrong, I would be delighted). If you want to parse stuff coming from a socket over the internet, you will want to do it securely but we'll cross that bridge when we come to it^^.

 

[doseijin]

Hi everyone,

I am particularly impressed by your replies and screenshots. Despite the artifacts and bugs, It seems promising. I will try on my side later when I will be more available. Just a question about the MFD : I remember when i tried Orbiter with wine and Vulkan, I got huge performance drop with some sophisticated MFDs, especially on XR fleet, and not so on Windows. Do you still have this performance drop with the native version you are testing ?

Warmest regards

I have discovered the reason for this after running Orbiter with DXVK, it's because for whatever reason the XR Fleet modules on the D3D9 client end up querying an IDirect3DTexture9 on D3D9DeviceEx::QueryInterface, for some reason. Which causes it to spam the terminal specially when in virtual cockpit mode, the fix I used was just to suppress DXVK warns with the environment variable DXVK_LOG_LEVEL=error, which makes it run much better (that is, at any acceptable rate, it literally froze when I tried to go to virtual cockpit mode on the DG-XR1).

 

[Linguofreak]

• unrelated to linux but in case you want to open source your work, consider using a GPLv3 compatible license to make redistribution easier (CC-BY-NC is not BTW, it's not even made for source code). A good compromise if you want to prevent people from making profit with your work, is to use a FOSS license for the code and CC-BY-NC for art assets. Of course if your project is code only, that doesn't work ?

Given that we're working in the addon environment for a FOSS project (orbiter), I'd recommend working with the same license as the main project (MIT) to minimize licensing hassle. If you want something copyleft, don't use straight GPL, in particular if you're writing anything that will be called as a library by other addons, as using GPL with anything that might be linked to by other software opens up a whole can of worms (by intent), it's probably best to use LGPL instead.

 

[Gondos]

Given that we're working in the addon environment for a FOSS project (orbiter), I'd recommend working with the same license as the main project (MIT) to minimize licensing hassle. If you want something copyleft, don't use straight GPL, in particular if you're writing anything that will be called as a library by other addons, as using GPL with anything that might be linked to by other software opens up a whole can of worms (by intent), it's probably best to use LGPL instead.

I didn't talk about using GPL, but to be GPL compatible.
Some major players (D3D9Client, XR fleet, NASSP...) are all under GPL so the can of worm may already be opened if someone wants to bundle some kind of orbiter distro.
You may frown upon redistribution/bundling of addons by third parties, but if one day we have a linux compatible orbiter, I don't expect addon devs to support every possible target/distro combination by themselves ; even the orbiter addons page would be a mess to work with. It's already troublesome sometimes to find the correct version with only 2006/2010/2016 to choose from, imagine if there'd be orbiter 2006, 2010, 2016 32bit, 2016 64bit, and Windows/linux (with all its distro flavors) on top of that, it would be a user nightmare...