Discussion NASSP OpenOrbiter Compatibility Thread

Joined
Feb 6, 2022
Messages
15
Reaction score
39
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
15
Reaction score
39
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
15
Reaction score
39
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,390
Reaction score
461
Points
83
Website
users.kymp.net
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
15
Reaction score
39
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
15
Reaction score
39
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
15
Reaction score
39
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

Member
Joined
Apr 18, 2022
Messages
84
Reaction score
73
Points
18
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
15
Reaction score
39
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,001
Reaction score
1,633
Points
188
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
15
Reaction score
39
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)
 
Top