x64 Development

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
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

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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.
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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 ;)
 

Attachments

  • D3D9Client.x64.zip
    793 KB · Views: 12

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
@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:
1627542720212.png
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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.
 
Last edited:

asbjos

tuanibrO
Addon Developer
Joined
Jun 22, 2011
Messages
696
Reaction score
259
Points
78
Location
This place called "home".
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
That is astoundingly fast progress!
 
Top