Linux playground

Hi @Gondos
I have a question for you, let's suppose that I want to install the G42-200 which is free software and can be found in this repository: https://github.com/abdullah-radwan/G42-200
What I have to do?
Excuse my ignorance on this but just starting to get familiar with programming.
 
Matias Saibene said:
Hi @Gondos
I have a question for you, let's suppose that I want to install the G42-200 which is free software and can be found in this repository: https://github.com/abdullah-radwan/G42-200
What I have to do?
Excuse my ignorance on this but just starting to get familiar with programming.
Click to expand...
Hi, you need to sort out different issues :
  • case in filenames
  • "\\" vs "/"
  • embedded bmps needs to be loaded as textures now
  • add a CMakeLists.txt file containing instructions for building
  • add UCSO beforehand since it looks like it's a dependency of G42-200
  • fix everything that does not compile and that'll show up when you do it
I just forked the two projects and I'll see what I can do ; since it's using XRSound and sketchpad instead of OrbiterSound/GDI, it shouldn't be a big deal to make it work?

Edit : got some UCSO stuff working but I don't really know how to test it...
UCSO.png
Edit2 : pushed some stuff on github
G422.pngG422b.png
I have no idea how to fly this bird though?
Note : there are lots of graphical glitches in the VC...
 
Last edited:
Gondos said:
Hi, you need to sort out different issues :
  • case in filenames
  • "\\" vs "/"
  • embedded bmps needs to be loaded as textures now
  • add a CMakeLists.txt file containing instructions for building
  • add UCSO beforehand since it looks like it's a dependency of G42-200
  • fix everything that does not compile and that'll show up when you do it
I just forked the two projects and I'll see what I can do ; since it's using XRSound and sketchpad instead of OrbiterSound/GDI, it shouldn't be a big deal to make it work?

Edit : got some UCSO stuff working but I don't really know how to test it...
View attachment 28807
Edit2 : pushed some stuff on github
View attachment 28809View attachment 28810
I have no idea how to fly this bird though?
Note : there are lots of graphical glitches in the VC...
Click to expand...
I had not seen your edit, I will try it as soon as I have internet that is not metered (I am using mobile internet).
Thank you for doing me the favor of including the G42-200, I love that bird.
 
Matias Saibene said:
Orbiter failed to build. Maybe it's my mistake, but I'm sure I followed all the steps correctly. I'll try again later.
Click to expand...

The problem may be the compiler.
You are using the compiler v12.1.0
I had the same problem with v10.x.x

My solution was to edit the line 417 in the file
/orbiter_test/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp

from

if (time >= 0)

to

if (time >= (void *) NULL)

Recently I have reinstalled my Linux and now I have the old compiler version 9.4.0 with which it works without editing the code.
 
Jordan said:
The problem may be the compiler.
You are using the compiler v12.1.0
I had the same problem with v10.x.x

My solution was to edit the line 417 in the file
/orbiter_test/orbiter/Addons/NASSP/Orbitersdk/samples/ProjectApollo/src_rtccmfd/ApolloRTCCMFD.cpp

from

if (time >= 0)

to

if (time >= (void *) NULL)

Recently I have reinstalled my Linux and now I have the old compiler version 9.4.0 with which it works without editing the code.
Click to expand...
Yep, NASSP is riddled with warnings and recent compilers will treat some as errors:confused:
Looking at the code I guess there is a real bug because I don't see the point in comparing against the time function;)
Code: 
void ApolloRTCCMFD::Angle_Display(char *Buff, double angle, bool DispPlus)
{
    double angle2 = abs(round(angle));
    if (time >= 0)
should more likely be
Code: 
void ApolloRTCCMFD::Angle_Display(char *Buff, double angle, bool DispPlus)
{
    double angle2 = abs(round(angle));
    if (angle >= 0)
Maybe the NASSP guys can confirm this...

Currently working on Deepstar since it's a nice FOSS project but it triggered some bugs in my module loading code that I had to fix, and now I still have some NaN issues that may or may not happen also on the official version.
Also it requires GeneralVehicle that does not come under a compatible license so I'm in the process of recoding it?
The Deepstar vessel is quite buggy for now, hopefully it'll help me troubleshoot issues with the OpenGL client...
deepstar.png
Edit: if you don't want the pollution from NASSP compilation, you can comment the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory
 
Last edited:
Gondos said:
Yep, NASSP is riddled with warnings and recent compilers will treat some as errors:confused:
Looking at the code I guess there is a real bug because I don't see the point in comparing against the time function;)
Click to expand...
That would be a question for @indy91. A lot of our RTCC code is patterned after fortran IV and IBM360 assembly routines (or in most cases their flowcharts. Not sure about this one specifically. We do have code from circa 2002 in other parts of the addon so there are probably plenty of things that need a ln update to pass for modern C++ styles.
 
Oh yes, that's a bug. I guess I just copied and pasted the GET_Display function, which is just below Angle_Display, and modified it. But I forgot about the "time" variable which somehow didn't give a build error when I didn't change that to "angle". Thanks for finding that!
 
Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile.

I will detail:
Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs.

Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2.

And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install?

I recently started deleting just the build directory and running the commands:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..
time make -j$(nproc) install

and the results were the same.

And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s).
 

Attachments

Matias Saibene said:
Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile.

I will detail:
Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs.

Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2.

And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install?

I recently started deleting just the build directory and running the commands:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..
time make -j$(nproc) install

and the results were the same.

And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s).It's a bug.
Click to expand...

Code: 
.....
Error creating directory "/home/matias/orbiter_test/Orbiter/orbiter/build/Orbitersdk/include/UCSO".
.....

There is a file with the name "USGO" in this folder and so no folder "USGO" can be created in that directory. This file is a C++ source code. Rename it to "UCGO.cpp" and try again.

Edit: I did everything from scratch and it worked without any errors.
 
Last edited:
Matias Saibene said:
Hi @Gondos, Turns out I've tried Orbiter again and sometimes it compiles and segfaults. And other times it doesn't even compile.

I will detail:
Case 1: If I apply the patch you mentioned but don't comment "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter starts but produces a segfault. View the orbiter-build-log1 and orbiter-run1 logs.

Case 2: I apply the patch you mentioned and comment out the line "add_subdirectory(NASSP)" in the CMakeLists.txt in the Addons directory Orbiter compiles but doesn't start, again produces a segfault. More details in orbiter-build-log2 and orbiter-run2.

And I have a question: is it necessary to download everything from scratch (by running git clone https://github.com/TheGondos/orbiter.git... etc) if I have already run time make -j$(nproc) install?

I recently started deleting just the build directory and running the commands:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..
time make -j$(nproc) install

and the results were the same.

And sorry for the delay in answering, it turns out that I have a very bad internet connection (~200kB/s).
Click to expand...
Damn, my mistake, I added the NASSP modules by default in Orbiter.cfg so it'll assert if you don't compile them ?
You can remove ApolloRTCCMFD and ProjectApolloMFD from the Orbiter/Orbiter.cfg.in to fix it.
To synchronize you don't need to clone everytime, you should do :
Code: 
git pull
to get the latest repository and then
Code: 
git submodule update --recursive --remote
to update the submodules.
Regarding the UCSO directory issue, you're not supposed to have the cpp files deployed during the installation so it's quite strange, most likely a bug in one of the CMakeLists.txt files...
 
@Gondos

1st. I have these wireframed faces. Is there a solution for this?
2nd. Parts in the LUT mesh are missing. Is there a limit number of vertices or faces?

Screenshot2.jpg
 
Jordan said:
@Gondos

1st. I have these wireframed faces. Is there a solution for this?
2nd. Parts in the LUT mesh are missing. Is there a limit number of vertices or faces?

Screenshot2.jpg
Click to expand...
What graphic card are you using? I'm on an old 9800GTX and I don't have this kind of visual artifact.
The OpenGL client uses 16bit indices for index arrays, the same as the D3D7 one
 
@Gondos
NVIDIA GTX 1060 6gb
D3D9 also uses 16bit, which should be enough and Orbiter in Windows has no problems with it.
 
Jordan said:
@Gondos
NVIDIA GTX 1060 6gb
D3D9 also uses 16bit, which should be enough and Orbiter in Windows has no problems with it.
Click to expand...
I found it, I was mixing using 16bit indices and using 16bits for the number of indices in draw calls... I'm so bad at this OGL stuff it's not even funny...
It fixed my deepstar visual issues so it should fix yours too :
deepstar-fixed.png
I'll push the fix soon.
Edit : fix pushed
 
Last edited:
Gondos said:
I'll push the fix soon.
Edit : fix pushed
Click to expand...
Doesn't work. Parts of the LUT are still missing.

By the way, in the file "orbiter_test/Orbiter/Config/ProjectApollo/Earth_VirtualAGC/Base/Canaveral_VirtualAGC.cfg" you can delete the part at the end between BEGIN_SURFTILELIST and END_SURFTILELIST or the whole part, then the black areas at Cape Canaveral are gone.
 
Jordan said:
Doesn't work. Parts of the LUT are still missing.
Click to expand...
That's bad luck :/ What parts are missing exactly? I can't tell clearly from the image...
The seams between faces are strange, the vertices should be identical since we're using index buffers. Maybe it's a UV problem...
Jordan said:
By the way, in the file "orbiter_test/Orbiter/Config/ProjectApollo/Earth_VirtualAGC/Base/Canaveral_VirtualAGC.cfg" you can delete the part at the end between BEGIN_SURFTILELIST and END_SURFTILELIST or the whole part, then the black areas at Cape Canaveral are gone.
Click to expand...
Thanks for the info:)
 
Gondos said:
That's bad luck :/ What parts are missing exactly? I can't tell clearly from the image...
The seams between faces are strange, the vertices should be identical since we're using index buffers. Maybe it's a UV problem...
Click to expand...

Here is a screenshot comparison D3D9 and OpenGL

MissingPartsAnim.gif


Edit: The seams between the faces appear to be transparent.
 
OK, I think I finally got it, there was still a uint16_t remaining somewhere...
I can't push a fix now, if you want to test it, it's in OGLMesh.h in class OGLMesh, struct GROUPREC definition.
There is a :
Code: 
        uint16_t nIdx;           // number of indices
that needs to be changed to :
Code: 
        uint32_t nIdx;           // number of indices
 
You must log in or register to reply here.

Similar threads

t3kkm0tt
Installation When will orbiter run natively on Linux?
Replies
9
Views
1K
Matias Saibene
Matias Saibene
Matias Saibene
Update Multistage2026 - Development thread
5 6 7
Replies
137
Views
21K
gattispilot
gattispilot
ThePuzzlemaker
Discussion PR: SDL3 port for cross-platform support
Replies
19
Views
6K
Gondos
G
LinuxWannabe
Using Orbiter on Linux
Replies
10
Views
4K
LinuxWannabe
LinuxWannabe
Matias Saibene
Discussion Volunteers needed to test XR2 on Linux
Replies
1
Views
2K
Matias Saibene
Matias Saibene
Back
Top