x64 Development

[Face]

So to start this off a little I have a branch that builds the core system and all modules in 64-bit (except of DX7, of course). We would need a 64-bit build of D3D9Client now to test that build further. The system loads up and shows the text interface, and according to the minimal GUI the simulation is running as expected, but visual confirmation would be optimal.

 

[kuddel]

Could you post a ZIP which contains the x64 versions of orbiter.lib & orbitersdk.lib?
I haven't found any time -yet- to build Orbiter myself, but I think with these two 64-Bit libs it should be possible to build D3D9Client as x64 version.

 

[GLS]

Could you post a ZIP which contains the x64 versions of orbiter.lib & orbitersdk.lib?
I haven't found any time -yet- to build Orbiter myself, but I think with these two 64-Bit libs it should be possible to build D3D9Client as x64 version.

Don't you also need a 64b exe to run the result?

 

[jedidia]

Hmmmm... Maybe it wouldn't be a bad idea to have a development fork, with the aim of posting pull requests to the main repo, so code can be shared without Martin having a ton of administrative overhead?
Or have somebody get some priviledges for the main repo so they can create branches.

 

[Face]

Could you post a ZIP which contains the x64 versions of orbiter.lib & orbitersdk.lib?
I haven't found any time -yet- to build Orbiter myself, but I think with these two 64-Bit libs it should be possible to build D3D9Client as x64 version.

I'll put together a ZIP with the full build folder, that way you could extract additional libs if needed (GDIClient comes to mind).

Here you are: https://snoopie.at/face/beta/x64-Debug.zip
Please note that the config file contains a path to my original installation texture folder, so you have to adjust it accordingly before running the client. Also note that apparently the scripts do not bundle the libs neatly in the /orbitersdk/ directory, instead they are all over the place in the /Src/ folders.

 

[Face]

Or have somebody get some priviledges for the main repo so they can create branches.

It is git on GitHub, anyway. Everybody can fork it on the same platform and even see the dependencies in the network insights: https://github.com/mschweiger/orbiter/network

 

[martins]

Fast work!! I am impressed how quick you got a 64 build up and running! One question, from the cmake files it looks like orbiter.exe still links the DX7 libraries, even for the graphics server version. Did I miss something? Or does this actually work? Slightly confused here.

Also note that apparently the scripts do not bundle the libs neatly in the /orbitersdk/ directory, instead they are all over the place in the /Src/ folders.

This doesn't sound right. Did you build Orbiter in the source directory? I never tried that, and I wouldn't recommend it. Usually I create a build directory beside the source directory, and configure it from there with cmake-gui ../Orbiter.
Also, the VS2019 generator has a really annoying way of placing targets into their own Release and Debug folders in each subdirectory, making it impossible to launch orbiter from the build directory. You can still run the INSTALL target to get a working Orbiter directory.
The Ninja generator does a better job of keeping debug and release builds completely separate. This does allow to run orbiter from the build directory.
Note that I have also added a PACKAGE target which builds orbiter ZIP and MSI packages. So this may be the easiest way to share builds.

Edit: although admittedly I haven't populated the sdk folder completely yet. So you are probably right there. For now I was happy that Orbiter itself builds. Getting the SDK directory set up is the next step.

 

[n72.75]

The way we do NASSP dev, is that we each work in a branch in our own form, and then make pull requests back to a branch to upstream (orbiternassp/orbiter2016).

 

[Face]

Fast work!! I am impressed how quick you got a 64 build up and running! One question, from the cmake files it looks like orbiter.exe still links the DX7 libraries, even for the graphics server version. Did I miss something? Or does this actually work? Slightly confused here.

This doesn't sound right. Did you build Orbiter in the source directory? I never tried that, and I wouldn't recommend it. Usually I create a build directory beside the source directory, and configure it from there with cmake-gui ../Orbiter.
Also, the VS2019 generator has a really annoying way of placing targets into their own Release and Debug folders in each subdirectory, making it impossible to launch orbiter from the build directory. You can still run the INSTALL target to get a working Orbiter directory.
The Ninja generator does a better job of keeping debug and release builds completely separate. This does allow to run orbiter from the build directory.
Note that I have also added a PACKAGE target which builds orbiter ZIP and MSI packages. So this may be the easiest way to share builds.

Edit: although admittedly I haven't populated the sdk folder completely yet. So you are probably right there. For now I was happy that Orbiter itself builds. Getting the SDK directory set up is the next step.

Hey, I'm just tinkering around, it can all be BS, as I can't confirm it without a GFX client.

What I did was the following:

1. Got VS 2019.
2. Got the newest ATL/STL thingies in it.
3. Got vspkg, installed the atlstl lib there.
4. Disabled help and documentation if the DOC flag is not set (which I've reset because I don't have the tools installed).
5. Configured CMake to use 64 bit.
6. Configured OVP only build.
7. Disabled the OVP DX7 folder.
8. Did those few 64-bit call changes in the code.
9. EDIT: Disabled the DX7 interface code for keyboard/mouse/joystick by means of uncommenting some of the function's body - this certainly needs work going forward.
10. Exchanged the lua and zlib dependencies with equivalent 64-bit libs.
11. Hit "Build all". It seems to run with the Ninja generator.

This builds into the projects root under an /out/build/<Config_Name>/ folder the way you see it in the ZIP I've posted. To my surprise it worked there as soon as I got the tool-chain working.

Great job with this setup, though! It must have been one hell of a time to herd all these things under one tool-chain.

 

[kuddel]

Hey @Face, can you try this quickly build D3D9Client.x64 please.
It is just a quick re-compile of the "2016 branch" as 64-bit build.
To be honest I do not expect it to work
Note, that your terrain-flattening-trampoline has been removed

 

[Face]

Hey @Face, can you try this quickly build D3D9Client.x64 please.
It is just a quick re-compile of the "2016 branch" as 64-bit build.
To be honest I do not expect it to work

Will do, thanks for the quick work!
I also did not expect my naive trials to work out, but here we are.

Note, that your terrain-flattening-trampoline has been removed

Sure thing, would just cause headaches. Now with the source code, I already spotted the appropriate function in the elevation manager, so we can work in an API callback that makes the whole hacking shenanigans obsolete, anyway.

 

[Face]

@kuddel : we are not that far away! I managed to load up the client, it already shows the splash with shader and simulation object loading progress, but as soon as the first clbkUpdate is sent in Orbiter's EndTimeStep() function, a null-ref exception gets thrown. I think I know why: due to my naive approach, I've disabled the DX7 mouse/keyboard/joystick interfaces, which gives their corresponding internal objects null-refs. During the clbkUpdate, D3D9Client certainly will directly or indirectly try to get those input objects, which return null.

Unfortunately, I can't debug the GFX client here, perhaps a quick uncomment of core calls in the clbkUpdate could make it run, even if it won't be responsive to controls at first. I've updated the ZIP with my current workspace content: https://snoopie.at/face/beta/x64-Debug.zip

Note that I've removed the Texture folder redirect in the config file, because for some reason the GFX client seems to ignore it, at least it searches for the necessary textures like e.g. Null.dds in the base folder instead of the redirected one. I've therefore copied those textures into my workspace, so the client boots up initially (until the null-ref exception, that is).

It is already coming together, exciting!

Edit: some picture to tease it a bit:

 

[Face]

Some more news: I've reworked the core DirectInput7 references to DirectInput8, which is close enough to make less troubles, but new enough to have x64 libs in the VS SDKs. The core code now compiles in x64 without the deactivation tricks, mouse/keyboard/joystick should work as before.
Unfortunately, @kuddel 's build still does not boot up completely, but this time it fails at a different point: already past the clbkUpdate() point, we're now stuck at sketchpad->Ellipse. I guess after my refactoring the sketchpad implementation in that build is not valid anymore.

GitHub branch and workspace ZIP is updated.

 

[jedidia]

Did you just take a vacation immediately when the source dropped? ?

 

[Face]

Did you just take a vacation immediately when the source dropped? ?

Luckily, I can shuffle work-loads a little.

 

[asbjos]

Some more news: I've reworked the core DirectInput7 references to DirectInput8, which is close enough to make less troubles, but new enough to have x64 libs in the VS SDKs. The core code now compiles in x64 without the deactivation tricks, mouse/keyboard/joystick should work as before.
Unfortunately, @kuddel 's build still does not boot up completely, but this time it fails at a different point: already past the clbkUpdate() point, we're now stuck at sketchpad->Ellipse. I guess after my refactoring the sketchpad implementation in that build is not valid anymore.

GitHub branch and workspace ZIP is updated.

Could it be related to this problem discovered by @kuddel last year?
The corresponding issue report seems to have been lost in the xenforo migration.

 

[Face]

Could it be related to this problem discovered by @kuddel last year?
The corresponding issue report seems to have been lost in the xenforo migration.

Well, I guess the rebuilding of the Orbiter source after the DirectInput8 refactoring did a similar thing. A rebuild of the D3D9Client should help with this problem, because it did not show up in the first round. Still, there is more to the null-ref in the clbkUpdate() call, which I'm sure @kuddel can debug better on his end.

 

[Face]

Recompiling it for myself, I finally got it to work. It now loads up and renders the simulation, even mouse and keyboard control is working. Unfortunately, there is a bug that only renders cockpit interior and planets, not the other meshes, no clue why. But it is a good first proof of concept for the x64 mode. ZIP archive is updated with the new D3D9Client.

 

[n72.75]

That is astoundingly fast progress!

 

[Face]

That is astoundingly fast progress!

For me as well! All in all I've invested perhaps 3 hours total... fiddling with the compiler settings has become my new coffee break habit lately .