Jordan
Well-known member
This change works, "kinda". The click points are not correct and the arrow keys moves the MFD.
Top Hatch looks like this with your new change.
And Fullscreen..
Last edited:
Linux playground
- Thread starter Gondos
- Start date
Top Hatch looks like this with your new change.
And Fullscreen..
Gondos
Well-known member
In the end it looks like an XR limitation
Gondos
Well-known member
Could be because of zbias not being implemented or a mismatch between the moon tiles and the moon base
Gondos
Well-known member
Odd, the panel looks stretched ; maybe there's an aspect ratio issue somewhere. Could explain the click points problem.This change works, "kinda". The click points are not correct and the arrow keys moves the MFD.
I pushed preliminary support for transparent panels (with the filtering issue)
Sword7
Active member
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
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:
Jordan
Well-known member
I could also merge the latest NASSP branch without too much trouble
Panel still stretched.
Sword7
Active member
Color key is not needed for OpenGL but need set up all zeroes in RGBA color for transparent.
Gondos
Well-known member
Bingo
Using GL_NEAREST for now on color keyed textures because I'm fed up with GLSL
Font size is still off and I think the reticule should be goldenish?
Using GL_NEAREST for now on color keyed textures because I'm fed up with GLSL
Font size is still off and I think the reticule should be goldenish?
Gondos
Well-known member
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 :
I receive this:
I'm using Xubuntu 22.04.1
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
I forgot to push a submodule (now fixed), maybe that's the cause.
Did you initialize the submodules? (git submodule update --init --recursive)
master_something
New member
- Joined
- Aug 28, 2018
- Messages
- 2
- Reaction score
- 1
- Points
- 1
It's working smoothly now, thank you!
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:
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:
And my GL info:
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 *) 0x0I'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
Hum, just to be sure, did you unzip the default Orbiter.zip inside your DESTDIR before doing make install?
Gondos
Well-known member
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) :
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?
).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) :
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?
I was not aware of this requirement
I'll try that, thanksSword7
Active member
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
Good to know, if you have a github account, can you do a pull request to get proper credit ?
Sword7
Active member
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.
Similar threads
