Linux playground

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Thanks, are they from shadow maps or projected polygons + stencil buffer? The D3D7 client does not use shadow maps.
Shadows of surface base buildings are projected polygons + stencil. The shadow of focus vessel and near by vessels are "Shadow Maps" in D3D9, so, a vessel can cast a proper shadow on a terrain and base objects.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
Shadows of surface base buildings are projected polygons + stencil. The shadow of focus vessel and near by vessels are "Shadow Maps" in D3D9, so, a vessel can cast a proper shadow on a terrain and base objects.
Thanks for the details:) This definitely points to a bug on my side.
I've been unable to work on this recently because of the heatwave but things are cooling off and I'm back to it.
The shift bug is solved and I've integrated another bmp decoder to fix the black squares showing on the NASSP 2D panel. The client rework broke pretty much everything for now so it's not in a state to be pushed to github.
If someone needs the shift fix, as expected it was a stupid bug. In VVessel.cpp / void VVessel::clbkEvent (visevent msg, visevent_data content) add this else clause :
Code:
                if (!meshlist[idx].trans)
                    meshlist[idx].trans = new glm::fmat4(1.0f);
+               else
+                   *meshlist[idx].trans = glm::fmat4(1.0f);
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
Ok, I learned some about Linux because I am doing developments through Unix systems. Do you use Visual Studio Code or Eclipse for coding and building? I prefer Visual Studio Code over Eclipse. It is easier to write programs in IDE editors. It is easier to read in dark theme. It supports Git and Cmake.

Do you have a listing of requirement or document for set up Orbiter for development system?

Thanks,
Tim
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
Ok, I learned some about Linux because I am doing developments through Unix systems. Do you use Visual Studio Code or Eclipse for coding and building? I prefer Visual Studio Code over Eclipse. It is easier to write programs in IDE editors. It is easier to read in dark theme. It supports Git and Cmake.

Do you have a listing of requirement or document for set up Orbiter for development system?

Thanks,
Tim
I'm using vscode to edit/debug but I build from a terminal.
For debugging you need to set the environment up to be able to use breakpoints in the editor.
I'm using these settings (launch.json, you can open it from the menu Run/Open Configurations):
Code:
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Lancer",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/gondos/titi/Orbiter/Orbiter",
            "args": [],
            "stopAtEntry": false,
            "cwd": "/home/gondos/titi/Orbiter/"
         ],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Activer l'impression en mode Pretty pour gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Définir la version désassemblage sur Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}
"program" and "cwd" must agree with the path you used when configuring your cmake build. I used this command from a "build" directory located at the git root:
Code:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=$HOME/titi ..
After compiling you can start a debug session by pressing F5.
In case of a crash, it should get you to the offending line, from then on it's "debug as usual" (This particular crash is caused by timewarping an XR2 with FPU exceptions on, the temperature code is not meant to deal with high deltaT per frame...)
Capture d’écran du 2022-07-24 22-50-02.png
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
Thanks. I got it now.

I tried to build them but it stopped at 45% during NAASP build procedure with error message below.

/home/sword7/Projects/orbiter-linux/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp: In member function ‘void ApolloRTCCMFD::Angle_Display(char*, double, bool)’:
/home/sword7/Projects/orbiter-linux/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp:417:18: error: ordered comparison of pointer with integer zero (‘time_t ()(time_t) noexcept’ {aka ‘long int ()(long int) noexcept’} and ‘int’)
417 | if (time >= 0)
| ~~~~~^~~~

I am using Ubuntu 22.04 and GNU GCC/G++ 11.2 compilers.

Tim
 

Attachments

  • build-log.txt
    277.8 KB · Views: 4

Jordan

Active member
Joined
May 13, 2010
Messages
136
Reaction score
80
Points
43
Location
Germany
Thanks. I got it now.

I tried to build them but it stopped at 45% during NAASP build procedure with error message below.

/home/sword7/Projects/orbiter-linux/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp: In member function ‘void ApolloRTCCMFD::Angle_Display(char*, double, bool)’:
/home/sword7/Projects/orbiter-linux/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp:417:18: error: ordered comparison of pointer with integer zero (‘time_t ()(time_t) noexcept’ {aka ‘long int ()(long int) noexcept’} and ‘int’)
417 | if (time >= 0)
| ~~~~~^~~~

I am using Ubuntu 22.04 and GNU GCC/G++ 11.2 compilers.

Tim
Maybe this can help you for now

 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
Ok, I figured them out. I found a bug and fixed it by changing 'time' to 'angle'. I successfully built at 100% complete. We need to contact NAASP team to update that.

Update: I checked NAASP repository and they already fixed it on May 30th. You need to update your forked repo from NAASP repo that you forked.

C++:
void ApolloRTCCMFD::Angle_Display(char *Buff, double angle, bool DispPlus)
{
    double angle2 = abs(round(angle));
    if (angle >= 0)
    {
        if (DispPlus)
        {
            sprintf_s(Buff, 32, "+%03.0f:%02.0f:%02.0f", floor(angle2 / 3600.0), floor(fmod(angle2, 3600.0) / 60.0), fmod(angle2, 60.0));
        }
        else
        {
            sprintf_s(Buff, 32, "%03.0f:%02.0f:%02.0f", floor(angle2 / 3600.0), floor(fmod(angle2, 3600.0) / 60.0), fmod(angle2, 60.0));
        }
    }
    else
    {
        sprintf_s(Buff, 32, "-%03.0f:%02.0f:%02.0f", floor(angle2 / 3600.0), floor(fmod(angle2, 3600.0) / 60.0), fmod(angle2, 60.0));
    }
}
 
Last edited:

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
I successfully installed Orbiter on $HOME/bin myself and executed it. It displayed so tiny screen but my monitor is 4K.

Does it have scale setting to make it bigger?
 

Jordan

Active member
Joined
May 13, 2010
Messages
136
Reaction score
80
Points
43
Location
Germany
I successfully installed Orbiter on $HOME/bin myself and executed it. It displayed so tiny screen but my monitor is 4K.

Does it have scale setting to make it bigger?
At the moment you have two options.

First, you can maximize the Orbiter window while playing, but you cannot hit easy the buttons that are accessed with F4 in Orbiter.

Second, you can maximize the orbiter window before starting a scenery, then the buttons are small but you can hit them.

This all works in 3D view. The 2D view is still displayed small.
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
Ok, I got it now. I tried to resize 2D window but text size do not change. Only 3D window works when I tried to resize.

I extracted everything from orbiter2016 package and executed 'make install' to overwrite them.

I was able select tiny text menu and displayed DeltaGlider cocpkit on KSC runway. My mouse works when I turn camera around. Some keyboard works.
I tried to press ctrl-+ but it did not work. I have gamepad elsewhere and I will try later.

I tried earth view selection in 2016 edition but it did not display planet earth.

I tried G42-200 and liked that cockpit!

I re-installed everything on my Linux server running Ryzen 8 (Vega 8 GPU). That went so smooth animations on internal Vega 8 GPU.

I commented NASSP out because of a lot of compiler warnings and uncommented XRVessels. I will extracted everything from XRVessels package.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
At the moment you have two options.

First, you can maximize the Orbiter window while playing, but you cannot hit easy the buttons that are accessed with F4 in Orbiter.

Second, you can maximize the orbiter window before starting a scenery, then the buttons are small but you can hit them.

This all works in 3D view. The 2D view is still displayed small.
Third option : change the hardcoded resolution in clbkCreateRenderWindow :
Code:
    /* Create a windowed mode window and its OpenGL context */
    hRenderWnd = glfwCreateWindow(1280, 800, "xorbiter", NULL, NULL);
    m_width = 1280;
    m_height = 800;
Fourth option : implement a video tab to choose the resolution from:p
ImGui has known issues with high DPI so the launch window will probably be too small for your taste.
Update: I checked NAASP repository and they already fixed it on May 30th. You need to update your forked repo from NAASP repo that you forked.
Yep, they fixed it based on this very thread. I'm not rebasing because I had to do some extensive modifications to make it compile on linux and I'm not sure it will apply cleanly or not break anything. I may do some cherry picking if it can help others with more recent compilers.
My plan is to get hold of a Windows box and propose some PRs to have some OS agnostic changes merged (porting to sketchpad, compilation errors, ...) to help reduce the gap between branches. But for now I'm stuck with linux so I can't do that...
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
Seeing the recent release of Universal Astronaut and Cargo System for Orbiter I think it would be nice to have it on Linux Orbiter.
https://www.orbiter-forum.com/threads/universal-astronaut-and-cargo-system-uacs.40591/
That's in the pipe but I still have some unfinished business graphics-wise.
Progress report :
  • switched sketchpad implementation to nanovg but text position is still a bit off and sometimes the font size is too big (particularly in XR2 MFDs). Had a struggle with fontconfig not honoring the monospaced attribute that ended up with a dirty work around...
nanovg.png
  • new bmp decoder supporting more NASSP bitmaps (stb_image was not supporting RLE)
NASSP2D.png
Blockers :
  • Issues with planet rendering (it was using some DX9 code for the rings and the rework based on DX7 broke it badly)
saturnbug.png
venusbug.png
  • Top panel is blank
panelbug.png
  • Blank MFDs and some missing text in 2D cockpit
mfdbug.png
Most are probably related to unexpected OpenGL states being propagated between functions.
I don't feel comfortable pushing before fixing these last issues...
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
@Gondos, when you've built NASSP against your Linux build, how did you deal with the TCP sockets and winsock stuff?
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
There are more MFD apps for Orbiter like BurnTimeCalc MFD package comes with source codes. They needs to be ported to Linux as well.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
@Gondos, when you've built NASSP against your Linux build, how did you deal with the TCP sockets and winsock stuff?
I added some API to the core but it could as well be done with #ifdefs in NASSP I suppose:
Code:
/* network related fonctions */
typedef void *SOCKETHANDLE;
#define OAPI_INVALID_SOCKET ((SOCKETHANDLE)-1)
#define OAPI_SOCKET_ERROR ((ssize_t)-1)
#define OAPI_SOCKET_ERROR_RETRY ((ssize_t)-2)
OAPIFUNC SOCKETHANDLE oapiSocketCreate();
OAPIFUNC void oapiSocketClose (SOCKETHANDLE);
OAPIFUNC bool oapiSocketConnect (SOCKETHANDLE, const char *addr, int port);
OAPIFUNC bool oapiSocketBind (SOCKETHANDLE, const char *addr, int port);
OAPIFUNC bool oapiSocketListen (SOCKETHANDLE, int);
OAPIFUNC SOCKETHANDLE oapiSocketAccept (SOCKETHANDLE);
OAPIFUNC ssize_t oapiSocketSend (SOCKETHANDLE, const void *buf, size_t len);
OAPIFUNC ssize_t oapiSocketRecv (SOCKETHANDLE, void *buf, size_t len);
Note that I don't know where the socket stuff comes into play in NASSP so I have no idea how to test it...
If your next question is about shared memory used to interact with IMFD, sadly I had to comment that out since IMFD's source code is not available.
There are more MFD apps for Orbiter like BurnTimeCalc MFD package comes with source codes. They needs to be ported to Linux as well.
I agree, but the best way to "port" them is to make the Orbiter API OS agnostic so that a simple recompile is all that's needed.

Getting closer :) :
xr2.png
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
I added some API to the core but it could as well be done with #ifdefs in NASSP I suppose:
Code:
/* network related fonctions */
typedef void *SOCKETHANDLE;
#define OAPI_INVALID_SOCKET ((SOCKETHANDLE)-1)
#define OAPI_SOCKET_ERROR ((ssize_t)-1)
#define OAPI_SOCKET_ERROR_RETRY ((ssize_t)-2)
OAPIFUNC SOCKETHANDLE oapiSocketCreate();
OAPIFUNC void oapiSocketClose (SOCKETHANDLE);
OAPIFUNC bool oapiSocketConnect (SOCKETHANDLE, const char *addr, int port);
OAPIFUNC bool oapiSocketBind (SOCKETHANDLE, const char *addr, int port);
OAPIFUNC bool oapiSocketListen (SOCKETHANDLE, int);
OAPIFUNC SOCKETHANDLE oapiSocketAccept (SOCKETHANDLE);
OAPIFUNC ssize_t oapiSocketSend (SOCKETHANDLE, const void *buf, size_t len);
OAPIFUNC ssize_t oapiSocketRecv (SOCKETHANDLE, void *buf, size_t len);
Note that I don't know where the socket stuff comes into play in NASSP so I have no idea how to test it...
If your next question is about shared memory used to interact with IMFD, sadly I had to comment that out since IMFD's source code is not available.

The IMFD stuff is obsolete. We could probably remove it at this point.


We have telemetry clients that use the TCP sockets:
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
If your next question is about shared memory used to interact with IMFD, sadly I had to comment that out since IMFD's source code is not available.

I agree, but the best way to "port" them is to make the Orbiter API OS agnostic so that a simple recompile is all that's needed.

Yeah. I agree with that. Sadly some addons' source codes are not available. All addons needs to be open source for Linux and other platforms because dll are not compatible with other platforms. .so files are standard for Linux, macOS and Unix-like platforms.

I found CCCP fleet package for Soyuz, etc on SourceForge. All source codes are available but they are in CVS repository. I was able rsync them into my drive.

I had not seen any Orbiter macOS development yet.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
The IMFD stuff is obsolete. We could probably remove it at this point.


We have telemetry clients that use the TCP sockets:
Man, that's gonna be harder to port than Orbiter itself :ROFLMAO:
What are the requirements for these things? To be able to work over a LAN? If not, then a simpler ImGui dialog might be a solution.
 
Last edited:

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
258
Points
78
Location
On my chair
Yeah. I agree with that. Sadly some addons' source codes are not available. All addons needs to be open source for Linux and other platforms because dll are not compatible with other platforms. .so files are standard for Linux, macOS and Unix-like platforms.

I found CCCP fleet package for Soyuz, etc on SourceForge. All source codes are available but they are in CVS repository. I was able rsync them into my drive.

I had not seen any Orbiter macOS development yet.
Most stuff I could find on sourceforge has no proper license statement so it's pretty much useless. And then come on, sourceforge, it's a pain to navigate and find the source code for a project even if you have a link to the packages...
macOS has the same issue as linux : no windows compatibility. If we can bring a linux port to life, maybe a metal client would be a possibility. I would give it a shot if I had the hardware since it may be an interesting project.
 
Top