CaptainSwag101
Member
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.
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:
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.)
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):
And here is how it looks in OpenOrbiter:
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!
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)
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:
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.
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.)
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):
And here is how it looks in OpenOrbiter:
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
Reliance on OrbiterSound
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: