Discussion NASSP OpenOrbiter Compatibility Thread

Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Over the past day or two I've been checking out OpenOrbiter, the open-source fork of Orbiter where development focus seems to be shifting. It has several promising features, such as a branch which integrates the D3D9 graphics client, and several bugfixes that could help solve issues like the click targets in the 3D virtual cockpit not always aligning with the visual position of the switches. Not only that, but its use of XRSound could serve as a replacement for OrbiterSound 5.0, which is the source of at least one known unfixable crash due to its hardcoded hotkey for dumping vessel debug information to a text file.

At the time of writing, using NASSP with OpenOrbiter appears to be mostly functional without any modifications. Vessel logic, switches and systems all work as expected from the very basic testing I've done. However, there are a series of blocking issues that are not present when using the old Orbiter Beta R90, which I will document as follows, in several broad categories:

Rendering Bugs

(Mostly fixed in a recent update of OpenOrbiter after the original posting)The D3D9 graphics client in OpenOrbiter does not function quite the same as it did in Orbiter Beta R90. Namely, when displaying 2D panels on a screen/window that is larger than the size of the panel, the surface is not scaled in OpenOrbiter but the click target positions are, meaning the visual surface is smaller than it should be, and the visual position of the spacecraft's switches and controls do not line up with their clickable spots in the window, as shown in the screenshot below. The mouse is located where the click target for the "SOURCE" switch is, which is visibly offset from the switch itself, because the click target positions are scaled based on screen size while the actual visible surface is not.
Orbiter_2022-05-27_11-56-31.png

This problem is due to an issue in D3D9Client, where any surfaces that use color keying for transparency/overlay effects are not processed for scaling. By modifying the code to perform scaling on these textures, a new issue arises: the bilinear filter used when scaling surfaces is applied BEFORE the color key effect, resulting in visible fringing artifacts on the edges of the color key area, as visible in the following screenshot:
Orbiter_2022-05-27_12-55-03.png

I don't know enough about Orbiter or D3D9 (or graphics in general) to understand how to fix this. If an Orbiter contributor who is familiar with the D3D9 graphics client like jarmonik might be able to offer some advice or explain how to avoid this issue, it would be very appreciated.
I really hope the issue can be solved without disabling the smoothing filter over scaled graphics, because the smoothing filter looks significantly better than the awful nearest-neighbor scaling effect used in Orbiter Beta R90.

Next, switching to the 3D Virtual Cockpit in the CSM causes a D3D9 client crash immediately due to some issue with the EMS scroll texture. The LM VC, meanwhile, works without any issues. I have no idea what the ultimate cause of the crash is, but by debugging I found that there is some issue with the texture DC handle returning NULL when it shouldn't, as shown in the following error info. Deleting this texture from the texture directory allows the CSM VC to load and work properly, but without a texture for the EMS scroll paper, which is not ideal. It is not feasible for me to debug this issue on my machine because Visual Studio does not support native debugging of CMake projects, which OpenOrbiter is. Attaching a debugger to a running instance partially works, but cannot find most the debug symbols, making breakpointing impossible.
(Note, the original crash happened at Line 840 of D3D9Surface.cpp, but after some messing about it changed to Line 884 as seen below. It seems to potentially have something to do with how the surface handle is obtained in the first place via GetSurface(), as that's what occurs on Line 840, which I believe is what should be investigated first.)
Orbiter_2022-05-27_10-48-39.png
notepad++_2022-05-27_10-49-28.png


Finally, the Floodlight objects on the launch pad do not work at all. Here you can see how they are supposed to look (in Orbiter Beta R90):
orbiter_2022-05-27_14-51-07.png

And here is how it looks in OpenOrbiter:
Orbiter_2022-05-27_14-10-09.png

I believe the reason these aren't working may have something to do with the fact that NASSP is built using the version of Orbiter SDK from Orbiter Beta at this time, rather than OpenOrbiter's version. However, building with OpenOrbiter's version of the SDK is a potentially non-trivial process, as described next.

Build failures

NASSP is built using Orbiter's SDK. However, some changes were made at some point to how certain modules are built (from what I can tell, mismatches versus static and dynamic linking for Orbitersdk.lib) which prevents NASSP from compiling for OpenOrbiter natively. Based on my testing, this is likely the reason why certain aspects like the Floodlights do not work correctly, as they expect a different linking type than OpenOrbiter's library uses. Until this is fixed, it will have to be compiled with Orbiter Beta and then manually installed into OpenOrbiter's installation directory. I do not have the proper understanding of C++ linking, OpenOrbiter's codebase, or NASSP's codebase to debug or fix this issue any further, and would need help to solve this issue.

Reliance on OrbiterSound

At this time, NASSP uses OrbiterSound 5.0 for its sound output, since earlier versions of Orbiter did not have a native sound engine, or at least not one which would suit NASSP's needs at the time. While OrbiterSound works acceptably, it has been known to cause crashes because its hard-coded hotkeys are always scanning for inputs in the background, even when Orbiter is not in focus, meaning that it is surprisingly easy to enter a debugging key combination and crash the simulator without even realizing it, which is frankly unacceptable software behavior in my opinion, and it can cost the user hours of sim time if they are not judicious about saving their progress. Now that XRSound is an option, however, it may be a good idea to port NASSP's sound engine over to eliminate this issue. This is probably also not a trivial task, and will require those who are, again, familiar with C++ and NASSP's codebase to accomplish it.

Conclusions

While I am far from experienced in this matter, through mere tinkering I was able to get NASSP into a mostly-functional state in OpenOrbiter, so it is my hope that this thread can serve as a place for discussion and cooperation between OpenOrbiter/NASSP developers and contributors to help make this work. My own skills can only get me so far, and without more information from more knowledgeable people, this is about as far as I can seem to get, but I am hopeful that we may even be able to get an OpenOrbiter build of NASSP working by the time NASSP 8.0 releases (a.k.a. eventually).

Please feel free to share your thoughts on this!
 
Last edited:
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Just a quick update: After a recent commit to the OpenOrbiter repo, the D3D9 client now scales color-keyed content. However, it appears to do so by disabling the bilinear filter, meaning that the scaling looks terrible just like Orbiter Beta. This is unfortunate, but at least it's functional compared to before. However, I very strongly hope that a better solution can be found in the future, since this can make the text on panels borderline-unreadable with this method of scaling.
 
Last edited:
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Alternatively, if it's possible to convert NASSP's textures to a format that natively supports transparency, that would be ideal, since that bypasses the need for color-keying entirely. However, I don't know if that is a possibility or not with Orbiter/D3D9 due to my limited knowledge of how the graphics engine/API works.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,670
Reaction score
799
Points
128
If the color-key stretch is really needed then I try to make it work better with bilinear-filtering.

As for the GetDC error, that problem exists on NASSP side. Previous versions of D3D9Client had an AI layer that tried to correct user errors on it's own. But due to lack of mindreading capabilities it did not always get the fix right and become little confusing and chaotic. So, it's been removed.

You have 13 mipmaps there, so do you want to propagate the drawings you do with GetDC to mip sublevels ?
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
If the color-key stretch is really needed then I try to make it work better with bilinear-filtering.

As for the GetDC error, that problem exists on NASSP side. Previous versions of D3D9Client had an AI layer that tried to correct user errors on it's own. But due to lack of mindreading capabilities it did not always get the fix right and become little confusing and chaotic. So, it's been removed.

You have 13 mipmaps there, so do you want to propagate the drawings you do with GetDC to mip sublevels ?
I'd need to check with the devs who actually know more about any of this stuff to say for sure. I'm actually almost completely in the dark about what most of this does, but I'm slowly learning. I still have no idea what the issue is with that particular texture that causes this error, but I'm considering recreating it from scratch to see if that solves the issue, since it's the only texture that has this problem.

To be clear, I was asked to make this thread by some of the other NASSP devs since I was already poking at the idea of an OpenOrbiter conversion before they were; I myself am a newcomer with little more than an intermediate knowledge of C++. I'm probably in over my head here, but my hope is that this discussion thread can spark insight from those who actually understand how it all works (like yourself), and to learn about it myself and contribute as I learn.

That said, is there a good way to actually run OpenOrbiter from a development environment while being able to breakpoint and debug in Visual Studio? Using the built-in CMake like the build instructions suggest don't allow for actually running the simulator through Visual Studio, as far as I can tell, so that severely limits my ability to understand the problem with NASSP.
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Quick update, after (sort of) porting the sound code from OrbiterSound 5.0 to XRSound (not actually working but just laying the code groundwork, thanks to an old unfinished pull request by user "ethhics"), NASSP now fully builds for OpenOrbiter! Several things like the floodlights and 3D virtual cockpit are still buggy, but with this, the main codebase compiles without incident.
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
After some more work, XRSound seems to be working as expected now! All sounds with the exception of LM Master Alarm and SPS/DPS/APS engines seem to play when they should, and after completely disabling the XRSound default config to eliminate its own sounds, everything sounds about like it did with OrbiterSound!
 
Last edited:

Gondos

Well-known member
Joined
Apr 18, 2022
Messages
235
Reaction score
275
Points
78
Location
On my chair
After some more work, XRSound seems to be working as expected now! All sounds with the exception of LM Master Alarm and SPS/DPS/APS engines seem to play when they should, and after completely disabling the XRSound default config to eliminate its own sounds, everything sounds about like it did with OrbiterSound!
That is quite nice!
Out of curiosity, are you compiling in 32bit or 64bit? On 64bit linux the VC camera shifts backward on tower jettison, I don't know if it's linux, 64bit or OpenOrbiter related. Do you experience the same problem?
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Okay, so after some discussion with more experienced NASSP developers, the engine sounds that aren't working were all handled by OrbiterSound implicitly, so there will need to be adjustments made in order to either have XRSound handle them, or to trigger them explicitly on the NASSP side of things. It's also come to my attention that the changes I made to the codebase don't work quite right for release builds of NASSP, so I'll have to fix that sometime soon. But I'm still quite pleased with things, as leaving behind OrbiterSound was the number-one blocking issue with getting OpenOrbiter support. After these issues are sorted out, it will just be a matter of figuring out if we can make the installation process for OpenOrbiter easier than it was for Beta R90, and NASSP 8.0 will be one step closer to release (maybe)!
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,958
Reaction score
2,979
Points
188
Website
github.com
leaving behind OrbiterSound was the number-one blocking issue with getting OpenOrbiter support
Hmm, I'm pretty sure OS works fine with the "new Orbiter", except for a x64 build, which needs x64 addons, which won't link with the existing x86 OS lib.
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Hmm, I'm pretty sure OS works fine with the "new Orbiter", except for a x64 build, which needs x64 addons, which won't link with the existing x86 OS lib.
You're right, I misspoke (can you tell I'm new to all this? Hahaha). Rather, ditching OrbiterSound has been something in consideration due to the unfixable crashes it sometimes causes due to its hard-coded hotkeys. Not to mention, since XRSound is directly integrated into OpenOrbiter, it's a natural target to switch to, since it can be built from source in both x86 and x64 environments with the proper configuration, and it is more extensible, where OrbiterSound has an apparent limit of only 60 sounds able to be loaded into memory at any given time (which isn't presently an issue of course, but more flexibility is nice. Heck, given the age of the NASSP codebase, those limitations might be from OS 4.0 rather than 5.0)
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Hello again! It's been a while since I last reported on this. So far a lot of small bugs have been squashed with XRSound and major crashes with the 3D VC, and things seem to work better now overall. There's still plenty of bugs here and there, but compatibility has reached the point where I'm almost ready to start testing out full NASSP missions in this version. However, before I start that there is one problem I'm encountering that I'd like to try and solve first.

A very hard-working contributor, "Jordan-64", has been hard at work developing a higher-fidelity mesh and textures for the CM and LM 3D Virtual Cockpit, but while the original textures work fine in OpenOrbiter, these new ones seem to have some very strange issues where overlapping textures and surfaces blend with each other, which doesn't occur in the Beta R90 branch of Orbiter, as seen here (note the odd-looking black rectangle and how it changes opacity depending on the viewing angle, as well as how faded the DSKY display looks, and the completely-invisible Saturn V engine lights and EMS scroll paper):

Orbiter_2023-05-23_17-46-57.jpg

Orbiter_2023-05-23_17-46-51.jpg


Depending on the viewing angle and/or how close the camera is to the panel , the textures change in how they blend together. I'm not sure what's going on here, but it means that when using these HD textures, the DSKY, mission timer, lights and gauges all are hard to read or completely invisible unless you zoom very close up, at which point they become fully-visible like they should be. I don't know the exact details about what was changed to make this new HD cockpit work, but I have tried testing only the new textures while using the original mesh file, and this issue is still present, so I presume the problem lies with the textures themselves.

Sorry to be a bother once more, jarmonik, but since this seems to be graphics and rendering-related, I'm curious to know if you have any insight into why this happens, and if there's something we can do on our end to correct it? I've been trying to troubleshoot with the creator of the HD mesh/textures but we've had no luck so far.
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
Just a quick update, I was able to fix the blending problem by setting the Texture Mipmap setting to "Load as defined" instead of the default "Autogen missing". However, the strange black rectangle near the middle of the panel seems to still remain, I'm working on trying to determine if that's a problem with the mesh or texture mapping perhaps:
Orbiter_2023-05-24_16-46-58.jpg
 
Joined
Feb 6, 2022
Messages
20
Reaction score
61
Points
13
Location
Earth
It's been a while, but I'm back with another update post: NASSP is now working pretty much flawlessly in OpenOrbiter! Not only that, but I've been able to make the add-on build properly for 64-bit architectures (possibly for the first time ever?). This is still highly experimental by its very nature, though I must say that I am extremely pleased with how it worked almost effortlessly once I'd configured all the linking and compilation options. Considering the complexity of the codebase, I was expecting all kinds of horrific bugs and errors, but things seem to have held up just fine to the transition, with one sole exception:

This came at the cost of needing to remove all traces of VESIM and its DirectInput8 joystick handling code, meaning that this branch of NASSP will not work with joysticks any more. Removing functionality is not what I'd hoped would be required, but the relevant code was absolutely ancient and was the only part of the existing NASSP code that simply would not work for 64-bit compilation, due to the proprietary DirectInput8 library being strictly 32-bit as far as I can tell. After discussing things with the other NASSP developers, this may be a sacrifice we're willing to make for the time being (the less reliance on super old proprietary Microsoft code, the better!). Our intention is that by the time we might consider making the OpenOrbiter code branch our main development target instead of this big experimental side-project of mine, that a suitable replacement might be found and implemented. And to be clear; while so far things seem to be working quite well, we don't currently have any plans to switch our builds away from Orbiter Beta R90.

Also, on the topic of the mysterious rectangle graphical bug I mentioned in previous posts, our current working theory is that that this is potentially caused by a driver issue for certain graphics cards. However, just a few weeks ago, I noticed that the bug mysteriously vanished for me! I can't explain why it isn't happening any more (I don't believe I'd updated my GPU drivers at the time), but if it's gone, then good riddance to another pesky bug!

At this point I've actually moved to using OpenOrbiter x64 as my primary way to fly NASSP missions, just for the sake of getting plenty of testing done as I go, and a couple other developers have been testing things out as well. Aside from a few bugs we've had to iron out along the way, it seems incredibly stable and reliable so far! Hopefully more good news continues to follow in the future.
 
Top