Linux playground

[Col Brubaker]

I have no idea why you have a python script called cmake in your PATH,

- lt is a Kali own reason for matter of security. Most likely something "evil" would be written for to take the standard-cmake.

a.) I press stanard-cmake in. - Which is not suggsted - but idkY - And It don't work either, since kernel 6...
Iv'e tied several ways to make cmake.
b.) Somebody tells me what to enter, cause I am not good with /home/me/Orbiter/Orbiter_test/orbiter/Orbiter...
My cmake is in: /home/alf/local/bin/cmake and local is a hidden folder.
Otherwise I have done everything like Gondos first post.
What do I have to enter?
============================================================

/usr/bin/cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..

did work. I needed a bit to understand.

Orbiter is also working now. - I am back in space

 

[jedidia]

You mean adding another straw on the camel's back?

I mean, that's what software development boils down to in the end, isn't it? We just keep adding straws of abstraction until the camel breaks

 

[Matias Saibene]

Speaking of new Orbiter releases...
Will we have an Orbiter Linux 2024?

And by the way @Gondos, I have ported some Windows add-ons to Linux with some effort but generally with positive results. Can I try on my personal copy of Orbiter Linux to implement the new commits that are in Orbiter 2024 for Windows? I mean, is there any special knowledge needed to do so?

Maybe (although I make no promises) I can help you, although I am not a good programmer but maybe I can help you port Orbiter Windows features to Linux. Just my 2 cents.

 

[Gondos]

Speaking of new Orbiter releases...
Will we have an Orbiter Linux 2024?

And by the way @Gondos, I have ported some Windows add-ons to Linux with some effort but generally with positive results. Can I try on my personal copy of Orbiter Linux to implement the new commits that are in Orbiter 2024 for Windows? I mean, is there any special knowledge needed to do so?

Maybe (although I make no promises) I can help you, although I am not a good programmer but maybe I can help you port Orbiter Windows features to Linux. Just my 2 cents.

I will probably update the Lua part to be aligned with the new release (except for some GC stuff that is not supported by the OGL client).
I doubt rebasing is an option given the amount of work that has been done in the main branch since I did the fork.

 

[Matias Saibene]

I will probably update the Lua part to be aligned with the new release (except for some GC stuff that is not supported by the OGL client).
I doubt rebasing is an option given the amount of work that has been done in the main branch since I did the fork.

Magnificent!
All in the small community of Orbiter for Linux, we thank you for your work for Orbiter.
And I personally wish you an excellent new year 2025!

 

[Gondos]

Magnificent!
All in the small community of Orbiter for Linux, we thank you for your work for Orbiter.
And I personally wish you an excellent new year 2025!

Thanks, you too!
Don't hesitate to do pull requests if you want me to have a look at what you did.
Happy new year

 

[Matias Saibene]

Thanks, you too!
Don't hesitate to do pull requests if you want me to have a look at what you did.
Happy new year

Thank you very much for the invitation! It would be an honor for me.

Anyway (I know I have a bad reputation for making absurd programming mistakes) I'm not going to send pull requests until I'm absolutely sure something works. I think I'll have a separate Orbiter installation from the main one to do some... Frankensteinian experiments.

First, though, I'm going to focus on UniversalCarsForOrbiter, I have to fix some memory leaks and the touchdownpoints.

Dan Shiffman Coding GIF - Dan Shiffman Coding Code - Discover & Share GIFs

Click to view the GIF

tenor.com

 

[Lucy]

I will probably update the Lua part to be aligned with the new release (except for some GC stuff that is not supported by the OGL client).
I doubt rebasing is an option given the amount of work that has been done in the main branch since I did the fork.

I would love to merge your efforts into the mainline so we can get native linux support going, honestly. I'm not sure how much pain that would be?

 

[n72.75]

I would love to merge your efforts into the mainline so we can get native linux support going, honestly. I'm not sure how much pain that would be?

Orbiter is the one application preventing me from going full-time Debian.

 

[Lucy]

Orbiter is the one application preventing me from going full-time Debian.

I live in nixos permanently, and while I can run orbiter reasonably well using wine, I can't develop for it without a windows install, which is... disappointing.

 

[Matias Saibene]

I live in nixos permanently, and while I can run orbiter reasonably well using wine, I can't develop for it without a windows install, which is... disappointing.

Gondos' implementation of Orbiter on Linux is good enough to develop something. In fact, I use Linux every day and use Windows only when I need to port my code to Windows or when I want to test some feature not yet implemented in Orbiter Linux.

VS Code + CMake is the dream team for me.

 

[Gondos]

I would love to merge your efforts into the mainline so we can get native linux support going, honestly. I'm not sure how much pain that would be?

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) :

 

[Matias Saibene]

The main blockers that I see are :

• Launchpad "architecture"

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.

Maybe a Launcher written in Qt would help? I think Qt is cross-platform and very complete.

Or maybe I'm mixing things up.

 

[Gondos]

Maybe a Launcher written in Qt would help? I think Qt is cross-platform and very complete.

Or maybe I'm mixing things up.

yes that is another option but I have no direct experience with it so I can't comment on that. Someone would have to investigate the impact it would have on the current code base.

 

[Kubala95]

Maybe a Launcher written in Qt would help? I think Qt is cross-platform and very complete.

Qt is a heavy library, I find the better option is WxWidgets. Instead of providing own drawing engine, Wx uses native GUI libraries to render windows (WinAPI on Windows and GTK on Linux) so it is possible to reconstruct an original launcher's appearence on Windows.

 

[Gondos]

Qt is a heavy library, I find the better option is WxWidgets. Instead of providing own drawing engine, Wx uses native GUI libraries to render windows (WinAPI on Windows and GTK on Linux) so it is possible to reconstruct an original launcher's appearence on Windows.

If it were up to me, I'd stick with 100% ImGui, it just requires a few files and once you get used to it, it can be really simpler for small UIs

 

[Matias Saibene]

If it were up to me, I'd stick with 100% ImGui, it just requires a few files and once you get used to it, it can be really simpler for small UIs

That's right, ImGui works very well, it looks great. And I know of a project that also uses it on Windows and Linux (SDR++).
Unifying both versions under ImGui would be nice, also because on Linux at least it looks more modern.

 

[Sword7]

Salut Laserpithium,
MFDs use system fonts so that things can look different on different operating systems. Also there may be some issues with high DPI displays.
Modules must be ported/compiled for linux, that's the biggest PITA with the current state of affairs. That's why I've been working on the Lua front in the main branch, with the hope that more content can be made available on different platforms without the need for that.

Check GLFW documents about physical parameters from display. I found some function calls to get DPI rate and physical screen size for adjusting font size for high DPI displays.

Tim

 

[Gondos]

I've backported the OO2024 Lua interpreter/scriptvessel to the linux branch but I have now some asserts in the OpenGL GC with the Lua DG.
I'll try to merge some GC rework I did when toying with the Raspberry Pi version, it should fix the issue.
I'll push everything when it's working properly.

 

[Lucy]

I've backported the OO2024 Lua interpreter/scriptvessel to the linux branch but I have now some asserts in the OpenGL GC with the Lua DG.
I'll try to merge some GC rework I did when toying with the Raspberry Pi version, it should fix the issue.
I'll push everything when it's working properly.

There's a separate branch we've got held open for checking out pulling lua from vcpkg (at version 5.4 instead of 5.1) - the theory is this will make it easier to build on linux, though I haven't had much success getting a working toolchain set up for it.