x64 Development

[martins]

As a side note, is there a way to configure the CMake project to set the debugger's working directory so I can launch the VS debugger from directly inside the IDE while configuring a working directory for it (like you can do with .vcxproj projects)? Currently I'm having to launch Orbiter from the command line (because otherwise the working directory is wrong) and then use 'attach to process' to debug it, but that's proving to be quite clunky. From Googling it, I found references to setting a project property named VS_DEBUGGER_WORKING_DIRECTORY, but I couldn't figure out where to set that.

Good question, I found this: this and this (halfway down the page, "debugging C++ binaries"), but I have a feeling you may have found the same pages. In short, if you are using the CMake version integrated into VS, then the VS_DEBUGGER_WORKING_DIRECTORY method will not work, because it uses a generator (Ninja) which never explicitly generates project files. The standalone CMake version should fare better, although one of the posts seems to suggest that it won't work either. I haven't yet managed to get the launch.vs.json method to work.

One more question -- is there a tool to convert a CMake project to a .vcxproj project? I'm much more familiar with those projects than CMake. If not, no biggie.

This is where the generators come in which translate the CMake code into makefiles, project files or anything else required on a specific platform to build a project. When using standalone CMake to configure a project, you have a choice of generators. The VS2019 generator translates CMake into VS2019 vcxproj and sln files which can then be loaded into VS as usual. The version built into VS uses Ninja, which seems more tightly integrated into the build process. It never creates project files but somehow feeds the CMake information directly to VS. Unfortunately both seem to have weaknesses, so it's up to preference. Maybe you could try the standalone CMake version for comparison?

 

[Face]

Good question, I found this: this and this (halfway down the page, "debugging C++ binaries"), but I have a feeling you may have found the same pages. In short, if you are using the CMake version integrated into VS, then the VS_DEBUGGER_WORKING_DIRECTORY method will not work, because it uses a generator (Ninja) which never explicitly generates project files. The standalone CMake version should fare better, although one of the posts seems to suggest that it won't work either. I haven't yet managed to get the launch.vs.json method to work.

With my VS, I got that working by means of using toolbar element with the green right arrow. There I've selected Modules\Server\Orbiter.exe, then used the "Debug->Debug and Start Settings for 'Orbiter_server'", which opened a launch_schema document where I've entered the working directory like so:

{
  "version": "0.2.1",
  "defaults": {},
  "configurations": [
    {
      "type": "default",
      "project": "CMakeLists.txt",
      "projectTarget": "Orbiter.exe (Modules\\Server\\Orbiter.exe)",
      "name": "Orbiter.exe (Modules\\Server\\Orbiter.exe)",
      "currentDir": "S:\\Development\\orbitersrc\\out\\build\\x64-Debug"
    }
  ]
}

With this I can just press F5 and get the Ninja-compiled Orbiter started and ready to debug.

 

[Notebook]

I've no idea what you are all doing, but I appreciate the hard work you are putting in.
Its encouraged me to re-install Orbiter and get to grips with the new tile system.
Hopefully I can re-build my old bases without the Google images.

 

[jarmonik]

I may be late to the party, but my version has the intriguing detail that it should compile both for x86 (inline graphics + server versions) and x64 (server only). Please give it a try!

I was thinking about this over-night and I find that problematic especially if the "inline" means DX7. Let's imagine that a Vulkan client is made for the Orbiter and a SURFHANDLE would be a pointer to a native Vulkan interface where as the SURFHANDLE would be pointer to native DX7 interface when using inline engine and those two interfaces are not even nearly compatible with each-other. So, we would need plenty of #ifdef / #else statements in the Orbiter code to have a (separate) working graphics routines for both. And the same would apply to every add-on.

Right now the D3D9Client works because it has a build-in wrapper/emulator for DX7, so it's tries (best of it's capabilities) to translate API calls made in a DX7 mindset to D3D9 API. One major problem is that for a programmer it's nearly impossible to properly/reliable operate underlying API through a wrapper layer. In a case of the Vulkan I don't think that the DX7 wrapper is even doable. However, it should be possible to do a Vulkan wrapper for the DX9. So (in other words) even if using native Vulkan surface interface, D3D9Client should be able to run as a backup client with few modifications.

I suppose it would be possible to have Vulkan inline engine and Vulkan client but it just doesn't make any sense.

Do we need to keen hanging on GDI or would it be time to let it go ? (I believe MFDs could still continue to work with it, since it's a special case)

 

[martins]

I am not suggesting to string along the DX7 engine or to keep the graphics API DX7-centric for any compatibility reasons. Making the code compile for x86 and x64 was really more a proof of concept. I now just want to finalise a few outstanding issues with the code, get it into a stable state, and then branch off the x86 build and retire it there. The master branch will then be x64 only, which means getting rid of the remnants of the DX7 references in the code.

I think your point is whether the built-in DX7 engine should be replaced with something else, or just dropped without replacement, relying exclusively on external graphics implementations. I don't have any problems with the latter, but what I'd say is this: If there is no built-in graphics capability, then the developments of the orbiter core and graphics client must be connected directly, i.e. they must be guaranteed to stay in sync, and a user downloading Orbiter must always seamlessly get a graphics-enabled system. They shouldn't even have to be aware that the graphics is served from an external client. What I absolutely want to avoid is that users have to download an Orbiter executable without graphics, and then look for the graphics package and hope that it is compatible.

I don't know if that tight integration is possible with the the core and graphics developments in separate projects. Maybe github can be set up link two repositories so that a push to one of them triggers pulling the sources to the other and doing a rebuild. Even if that is possible, I think it would be easier to just merge the development.

Would you be ok with merging the core and client development into a single repository? What I would suggest is this: consider moving the D3D9 client code into the Orbiter github repository. I would then give you developer rights to the repository. The tasks would still be fairly well-separated: I work on one side of the graphics API, and you on the other. But the boundaries would be more fluent, i.e. you would have the ability to modify the interface without having to wait for me. This would mean that core and graphics will stay in sync and all packages will come with a graphics option.

 

[Face]

As little as my opinion may count in this discussion, I throw it in, anyway: as I wrote before, I think it is now pretty clear that D3D9Client is the de-facto standard graphics client of Orbiter. Ditching the DX7 inline and OVP client makes sense, and I would very welcome seeing Orbiter and D3D9Client combined in one repository, practically having the later as prime example for OVP development.

However, I'd suggest to keep x86 compatibility (or regular cross-porting) a part of the project, because at least for some years to come, legacy addon support would make a difference for many users. Let's learn from the... erm... "problematic" terrain introduction in the past and keep old addons in mind as good as possible.

 

[JDat]

Looks like Martins is asking about github submodule? I saw this approach for PropellerIDE.
Maybe D3D9 can be submodule for Orbiter?

Working with submodules

Eventually, any interesting software project will come to depend on another project, library, or framework. Git provides submodules to help with this. Submodules allow you to include or embed one…

github.blog

https://github.blog/2016-02-01-working-with-submodules/

 

[Face]

Looks like Martins is asking about github submodule? I saw this approach for PropellerIDE.
Maybe D3D9 can be submodule for Orbiter?

Working with submodules

Eventually, any interesting software project will come to depend on another project, library, or framework. Git provides submodules to help with this. Submodules allow you to include or embed one…

github.blog

https://github.blog/2016-02-01-working-with-submodules/

Please, for the love of god, do not use submodules. It is a major PITA to work with in git.

 

[JDat]

Sorry for offtopic.

Wow! Can you tell more about git submodule PITA? What and why makes things complicated?
I have no experience from git code maintainer perspective.
I remember that from user perspective just needed to execute few more commands in terminal after git clone and it worked for me.

PS: No need to "decrypt" PITA acronym.

 

[GLS]

There are easier and less painful ways to commit suicide than using submodules.

 

[Face]

Wow! Can you tell more about git submodule PITA? What and why makes things complicated?
I have no experience from git code maintainer perspective.
I remember that from user perspective just needed to execute few more commands in terminal after git clone and it worked for me.

Just read the referenced article to the end. Let me quote from there:

Advice on using submodules (or not)​

• Before you add a repository as a submodule, first check to see if you have a better alternative available. Git submodules work well enough for simple cases, but these days there are often better tools available for managing dependencies than what Git submodules can offer. Modern languages like Go have friendly, Git-aware dependency management systems built-in from the start. Others, like Ruby’s rubygems, Node.js’ npm, or Cocoa’s CocoaPods and Carthage, have been added by the programming community. Even front-end developers have tools like Bower to manage libraries and frameworks for client-side JavaScript and CSS.
• Remember that Git doesn’t download submodule contents by default. If you’re adding a submodule to an existing project, make sure anyone that works on the project knows they need to run commands like git submodule update and git clone --recursive to ensure they get everything—this includes any automated deployment or testing service that might be involved in the project! We recommend you use something like our “Scripts to Rule Them All” to ensure that all collaborators and services have access to the same repository content everywhere.
• Submodules require you to carefully balance consistency and convenience. The setup used here strongly prefers consistency, at the cost of a little convenience. It’s generally best to have a project’s submodules locked to a specific SHA, so all collaborators receive the same content. But this setup also makes it difficult for developers in the “parent” repository to contribute changes back to the submodule repository.
• Remember that collaborators won’t automatically see updates to submodules—if you update a submodule, you may need to remind your colleagues to run git submodule update or they will likely see odd behavior.
• Managing dynamic, rapidly evolving or heavily co-dependent repositories with submodules can quickly become frustrating. This post was focused on simple, relatively static parent-child repository relationships. A future follow-up post will detail some strategies to help manage more complex submodule workflows.

I know from experience that submodules break certain git workflows badly, especially those involving history editing.

 

[kalral]

Please, for the love of god, do not use submodules. It is a major PITA to work with in git.

There is also an option to clone the git repo using CMAKE as an external project. So in this case, D3D9 client will be another completely different git repo and the Orbiter cmake will clone the D3D9 client while building.

ExternalProject — CMake 4.3.20260513-g3d1f9d3 Documentation

cmake.org

 

[dbeachy1]

What is the downside to simply pulling the D3D9 client code tree as-is into a new folder inside the existing Orbiter repository? D3D9 could still be built via a separate Visual Studio project, or even a separate VS solution. The end result would still be a single binary package of Orbiter with the D3D9 graphics client already activated in the Launchpad, which would be a major win for users (as also for developers, since we won't have to constantly work to keep the latest Orbiter core build and corresponding D3D9 build in sync by downloading and installing them separately). Or am I missing something??

 

[n72.75]

What is the downside to simply pulling the D3D9 client code tree as-is into a new folder inside the existing Orbiter repository? D3D9 could still be built via a separate Visual Studio project, or even a separate VS solution. The end result would still be a single binary package of Orbiter with the D3D9 graphics client already activated in the Launchpad, which would be a major win for users (as also for developers, since we won't have to constantly work to keep the latest Orbiter core build and corresponding D3D9 build in sync by downloading and installing them separately). Or am I missing something??

That seems like the safest way to do it.

 

[jedidia]

Is there really nothing slightly comparable to Maven in the C++ world? Seems to me that and a repository server would kinda solve the issue...

Wow! Can you tell more about git submodule PITA? What and why makes things complicated?

I had to work on a larger project using submodules some years ago. My traumatised mind has since suppressed the details, but I remember the pain...

 

[jarmonik]

Would you be ok with merging the core and client development into a single repository?

Yes, that would be fine by me. And I do agree with your points regarding having a complete and compatible build for users and developers available. There's been plenty of problems due to version mismatch. The latest x64 revision of the client in the SVN should be reasonably stable. I have detected a problem with TileFormat=1 planets which will render at very low sphere patch level, I'll have to debug that. But you can take a copy when ever you want.

To make the client better and more reliable removing that DX7 surface emulator would be an important step, it's the most awkward piece of code there. How big of a problem it would be for an add-on developers to remove dependencies to GDI (except MFDs) (i.e. GDI in MFD should be fine) ? NASSP would likely be mostly impacted, so, what do developers think ?

 

[Max-Q]

Removing GDI would break a lot of things, beyond the point of simply recompiling for x64, would it not?

 

[jarmonik]

Would you be ok with merging the core and client development into a single repository?

The x64 build is in a SVN repository right over here: svn://mirror.orbiter-radio.co.uk/D3D9client/trunk

 

[jarmonik]

Removing GDI would break a lot of things, beyond the point of simply recompiling for x64, would it not?

Unfortunately Yes, a progress is a double edged sword, new things come and old things gets obsolete. Orbiter development could have stayed in SVN but it was moved to a Git and now I have to start learning it. GDI it self (in a bad place) breaks a modern graphics pipelines and Vulkan API doesn't support it at all which will be a problem if we ever decide to go multi platform.

 

[n72.75]

...NASSP would likely be mostly impacted...

The plan eventually is to remove the 2d, performance-murdering, panels. And replace them with the virtual cockpits. Not everything is finished for this yet but it's probably 80% of the way there. One of the biggest thing we need in the 3d cockpits is optics.

That said, our next release (8.0) will almost certianly target the final stable x86 release (Orbiter 2019 or 2016p1 or whatever it ends up getting called), when that hits the shelves. After that's all settled we will probably move toward a 9.0 alpha and fully embrace all the benefits that the x64 versions will bring.

Disclamer: I don't speak for everyone in the project, or the project as an organization, this is just my personal perspective. As always plans are subject to change.