Linux playground

Jordan

Active member
Joined
May 13, 2010
Messages
136
Reaction score
80
Points
43
Location
Germany
Edit: now it does
This change works, "kinda". The click points are not correct and the arrow keys moves the MFD.

Bildschirmfoto%20vom%202022-08-25%2019-55-43.png


Top Hatch looks like this with your new change.

Bildschirmfoto%20vom%202022-08-25%2020-05-19.png


And Fullscreen..

Bildschirmfoto%20vom%202022-08-25%2020-05-31.png
 
Last edited:

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
No, Panel get stretched with Delta Glider that came with Orbiter. I tried XR1 but panel was not stretched. Same as XR5. Only Delta-Glider got stretched panel.

Update: I checked XRVessels repo and there are XR*InstrumentalPanel.cpp/h files so that you can update codes to fit 4K resolution or beyond.

View attachment 30145
In the end it looks like an XR limitation
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
This change works, "kinda". The click points are not correct and the arrow keys moves the MFD.

Bildschirmfoto%20vom%202022-08-25%2019-55-43.png
Odd, the panel looks stretched ; maybe there's an aspect ratio issue somewhere. Could explain the click points problem.
I pushed preliminary support for transparent panels (with the filtering issue)
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
In the end it looks like an XR limitation

I replied to XR limitation topics and explained about tiny panels.

For match egdes, you might take a look on D3D9 client code. I saw match edge routines in D3D9 client code. Did you write OGLClient from scratch or where did you get from? Be aware about jittery issues when round-off errors occurs in large values. There is a book called "3D Engine Design for Virtual Globes" that explains about jittery issues.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
I replied to XR limitation topics and explained about tiny panels.

For match egdes, you might take a look on D3D9 client code. I saw match edge routines in D3D9 client code. Did you write OGLClient from scratch or where did you get from? Be aware about jittery issues when round-off errors occurs in large values. There is a book called "3D Engine Design for Virtual Globes" that explains about jittery issues.
The OGLClient code is based on a copy/paste of the D3D7Client.
Edit : man , I can't get transparency working consistently across NASSP and XRVessels😫. Tried to do explicit bilinear filtering in a shader to fix the violet outlines but the result is fugly...
NASSP is specifying a color key in oapiBlt but it is discarded in the Orbiter core ; I still need to figure out how everything fits together because I tried different approaches but everything is failing so far...
On the plus side, I figured out why the XR secondary HUDs were a mess : font rendering was using the alpha channel for subpixel precision and it interferes with transparency. After a switch to freetype and a quick patch to use monochrome rendering, it looks better (although now the fonts look aliased).
I could also merge the latest NASSP branch without too much trouble:)
 
Last edited:

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
Color key is not needed for OpenGL but need set up all zeroes in RGBA color for transparent.
I'm using discard in the fragment shader because there are some intermediate renders to textures before final framebuffer display and I failed in my attempt to use the alpha channel properly this way. Also the color key is not known when the texture is loaded and it's a bit of a mess to patch a texture buffer. Granted it should be possible but I'll leave well enough alone.
 

master_something

New member
Joined
Aug 28, 2018
Messages
2
Reaction score
1
Points
1
I can't compile it.
When I try execute :
Code:
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..

I receive this:

Code:
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)

-- Could NOT find LATEX (missing: LATEX_COMPILER)

-- Could NOT find Fontconfig (missing: Fontconfig_LIBRARY Fontconfig_INCLUDE_DIR)

-- Configuring done

CMake Error at OVP/OGLClient/CMakeLists.txt:13 (add_library):

  Cannot find source file:

    nanovg/src/nanovg.c


  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h

  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc


CMake Error at OVP/OGLClient/CMakeLists.txt:13 (add_library):

  No SOURCES given to target: OGLClient

CMake Generate step failed.  Build files cannot be regenerated correctly.


I'm using Xubuntu 22.04.1
 
Last edited:

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
I can't compile it.
When I try execute :
Code:
cmake -DCMAKE_INSTALL_PREFIX=$HOME/orbiter_test ..

I receive this:

Code:
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)

-- Could NOT find LATEX (missing: LATEX_COMPILER)

-- Could NOT find Fontconfig (missing: Fontconfig_LIBRARY Fontconfig_INCLUDE_DIR)

-- Configuring done

CMake Error at OVP/OGLClient/CMakeLists.txt:13 (add_library):

  Cannot find source file:

    nanovg/src/nanovg.c


  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h

  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc


CMake Error at OVP/OGLClient/CMakeLists.txt:13 (add_library):

  No SOURCES given to target: OGLClient

CMake Generate step failed.  Build files cannot be regenerated correctly.


I'm using Xubuntu 22.04.1
I forgot to push a submodule (now fixed), maybe that's the cause.
Did you initialize the submodules? (git submodule update --init --recursive)
 

KaibutsuX

New member
Joined
Dec 3, 2013
Messages
2
Reaction score
0
Points
1
Gondos, thanks for the commits, I've been looking forward to this for a while.

I currently can't get anything to run on my system without a core dump. It looks like the OGLTexture pointer tex is alway NULL in my case, here's a coredump trace:

Code:
(gdb) bt
#0  SurfTile::Render (this=0x55aec0a645c0) at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/surfmgr2.cpp:574
#1  0x00007f69004fad45 in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a64470)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:183
#2  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a63520)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#3  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0ddaf70)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#4  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0dda250)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#5  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0dd9df0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#6  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a70710)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#7  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aebeafe480)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#8  0x00007f69004f9dc8 in TileManager2<SurfTile>::Render (this=0x55aebeafe080, dwmat=..., use_zbuf=true, rprm=...)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/surfmgr2.cpp:1088
#9  0x00007f69004db773 in vPlanet::RenderSphere (this=0x55aebfa9bba0, prm=..., using_zbuf=@0x7ffd37645918: false)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/VPlanet.cpp:540
#10 0x00007f69004db3be in vPlanet::Render (this=0x55aebfa9bba0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/VPlanet.cpp:446
#11 0x00007f69004c399f in Scene::Render (this=0x55aebd08c6d0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/Scene.cpp:505
#12 0x00007f69005057cc in OGLClient::clbkRenderScene (this=0x55aebccc7c10)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/OGLClient.cpp:696
#13 0x000055aebb3d9ba3 in Orbiter::Render3DEnvironment (this=0x55aebcc3ff40)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:811
#14 0x000055aebb3da7a4 in Orbiter::Run (this=0x55aebcc3ff40)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:1108
#15 0x000055aebb3d6779 in main (argc=1, argv=0x7ffd37645cc8)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:178
(gdb) p tex
$1 = (OGLTexture *) 0x0

I've tried gdb'ing through the running of it, but so far (I haven't looked very hard yet) but I can't find where tex is supposed to be initialized.

I have all the required libs installed, also running arch. Here's my vga:

Code:
lspci | grep -i vga
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)

And my GL info:

Code:
glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 22.1.7
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.1.7
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.1.7
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
Gondos, thanks for the commits, I've been looking forward to this for a while.

I currently can't get anything to run on my system without a core dump. It looks like the OGLTexture pointer tex is alway NULL in my case, here's a coredump trace:

Code:
(gdb) bt
#0  SurfTile::Render (this=0x55aec0a645c0) at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/surfmgr2.cpp:574
#1  0x00007f69004fad45 in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a64470)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:183
#2  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a63520)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#3  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0ddaf70)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#4  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0dda250)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#5  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0dd9df0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#6  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aec0a70710)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#7  0x00007f69004fae1a in TileManager2Base::RenderNode<SurfTile> (this=0x55aebeafe080, node=0x55aebeafe480)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/tilemgr2_imp.hpp:188
#8  0x00007f69004f9dc8 in TileManager2<SurfTile>::Render (this=0x55aebeafe080, dwmat=..., use_zbuf=true, rprm=...)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/surfmgr2.cpp:1088
#9  0x00007f69004db773 in vPlanet::RenderSphere (this=0x55aebfa9bba0, prm=..., using_zbuf=@0x7ffd37645918: false)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/VPlanet.cpp:540
#10 0x00007f69004db3be in vPlanet::Render (this=0x55aebfa9bba0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/VPlanet.cpp:446
#11 0x00007f69004c399f in Scene::Render (this=0x55aebd08c6d0)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/Scene.cpp:505
#12 0x00007f69005057cc in OGLClient::clbkRenderScene (this=0x55aebccc7c10)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/OVP/OGLClient/OGLClient.cpp:696
#13 0x000055aebb3d9ba3 in Orbiter::Render3DEnvironment (this=0x55aebcc3ff40)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:811
#14 0x000055aebb3da7a4 in Orbiter::Run (this=0x55aebcc3ff40)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:1108
#15 0x000055aebb3d6779 in main (argc=1, argv=0x7ffd37645cc8)
    at /home/kaibutsux/prj/src/orbiter/orbiter_linux/Src/Orbiter/Orbiter.cpp:178
(gdb) p tex
$1 = (OGLTexture *) 0x0

I've tried gdb'ing through the running of it, but so far (I haven't looked very hard yet) but I can't find where tex is supposed to be initialized.

I have all the required libs installed, also running arch. Here's my vga:

Code:
lspci | grep -i vga
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)

And my GL info:

Code:
glxinfo | grep -i version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 22.1.7
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.1.7
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.1.7
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
Hum, just to be sure, did you unzip the default Orbiter.zip inside your DESTDIR before doing make install?
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
Dusted an old joystick and had some thoughts about how I could integrate it inside Orbiter without hard-coding the mappings and decided to try something new (for me at least 😅 ).
I did a mock-up with imnodes and it turns out like this (the inputs are drived by the joysticks but the outputs are not hooked to the core, some massive rework would be necessary) :
graph.png
It would be nice to have different mappings for different modes (lift off, docking, reentry...) but I have not yet found a way to model it gracefully...
Do you think it's something that could be usable or will it be too complex to interact with?
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
C++:
static void __attribute__ ((constructor)) setup(void) {
    static bool need_init = true;
    if(!need_init) {
        return;
    }
    need_init = false;
    Dl_info info;
    int ret = dladdr((void *)setup, &info);
    if(ret == 0) {
        printf("dladdr failed\n");
        assert(false);
    }

    myModule = oapiModuleLoad(info.dli_fname);

    void (*InitModule)(MODULEHANDLE) = (void(*)(MODULEHANDLE))oapiModuleGetProcAddress(myModule, "InitModule");
    if(InitModule)
        InitModule(myModule);

    myExit = (void(*)(MODULEHANDLE))oapiModuleGetProcAddress(myModule, "ExitModule");

    oapiModuleUnload(myModule);
}

I now find info.dli_fbase uses same address as MODULEHANDLE. So that oapiModuleLoad/oapiModuleUnload is not needed for that.

Simply code to:
C++:
myModule = info.dli_fbase;

InitModule(myModule);  or InitLibrary(myModule);

I did tried that and it worked so well.
 

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
222
Reaction score
257
Points
78
Location
On my chair
C++:
static void __attribute__ ((constructor)) setup(void) {
    static bool need_init = true;
    if(!need_init) {
        return;
    }
    need_init = false;
    Dl_info info;
    int ret = dladdr((void *)setup, &info);
    if(ret == 0) {
        printf("dladdr failed\n");
        assert(false);
    }

    myModule = oapiModuleLoad(info.dli_fname);

    void (*InitModule)(MODULEHANDLE) = (void(*)(MODULEHANDLE))oapiModuleGetProcAddress(myModule, "InitModule");
    if(InitModule)
        InitModule(myModule);

    myExit = (void(*)(MODULEHANDLE))oapiModuleGetProcAddress(myModule, "ExitModule");

    oapiModuleUnload(myModule);
}

I now find info.dli_fbase uses same address as MODULEHANDLE. So that oapiModuleLoad/oapiModuleUnload is not needed for that.

Simply code to:
C++:
myModule = info.dli_fbase;

InitModule(myModule);  or InitLibrary(myModule);

I did tried that and it worked so well.
Good to know, if you have a github account, can you do a pull request to get proper credit ?
 

Sword7

Member
Joined
Mar 23, 2008
Messages
140
Reaction score
16
Points
18
Location
Gaithersburg, MD
OK, hold on. I tried it on Linux but it did not work. I did try shared module as test program on MinGW and it only worked on MinGW under Windows. I will investiagate it later.
 
Top