# x64 Development

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Oh, almost forgot: my branch now has the inline client compiling for x64 as well. It does not work, because the Direct3D7 devices are not enumerated, but at least the build chain doesn't throw an error if you configure it to build both clients.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
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.

Nice work there. It's great to hear it's working that far already. What ever is causing the meshes not to appear is likely a small thing.

I just made my first attempt to compile Orbiter_ng in x64 and I got about 150 errors of which about 95% are related to GetWindowLong and DLGPROC

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I just made my first attempt to compile Orbiter_ng in x64 and I got about 150 errors of which about 95% are related to GetWindowLong and DLGPROC
Yeah, that is practically all I had to fix for the first try. The only other thing was switching the DirectInput code from 7 to 8 to make it use the x64 libs. I'm a bit flubbergasted that this is all there is to it.

#### kuddel

##### Donator
Donator
I just made my first attempt to compile Orbiter_ng in x64 and I got about 150 errors of which about 95% are related to GetWindowLong and DLGPROC
Yeah all those functions/methods return type have to change from BOOL to INT_PTR I think (does INT_PTR also work for x86 builds I wonder?)
At least that's what I did for my "quick-x64-build".
For example:

And according to Microsofts documentation those functions should still return TRUE rsp. FALSE ....with looks odd I think

Last edited:

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
And according to Microsofts documentation those functions should still return TRUE rsp. FALSE ....with looks odd I think

Yes, I stopped to think about that my self too but didn't spot anything in the documentation about the return value. Luckily you had a better eyes. So, returning TRUE/FALSE is alright.

#### kuddel

##### Donator
Donator
In case you have not noticed this post in the D3D9Client thread...
Regarding "branching for r90" and make 'trunk' the main x64 development branch: It's fine with me. Should we name the branch "2016-P1"[*] "2019"[**] ?

[*] calling it "something BETA" seems odd now
[**] "2019" would be appropriate as r90 was from September 14th 2019

Last edited:

#### Donamy

Donator
Beta Tester
Anything but 2020

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I've found the visibility bug: acos() seems to behave differently in x64 builds, so the visibility code returned false negative on all objects. After adding a sanity check, all elements are now rendered correctly. ZIP archive has been updated.

#### Urwumpe

##### Not funny anymore
Donator
I've found the visibility bug: acos() seems to behave differently in x64 builds, so the visibility code returned false negative on all objects. After adding a sanity check, all elements are now rendered correctly. ZIP archive has been updated.

Is acos really needed? Which line is affected?

#### jedidia

##### shoemaker without legs
I've found the visibility bug: acos() seems to behave differently in x64 builds
Oh, the joys of C++... ?‍

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Is acos really needed? Which line is affected?
This is the patch fixing it:
C++:
# HG changeset patch
# User face <[email protected]>
# Date 1627658532 -7200
#      Fri Jul 30 17:22:12 2021 +0200
# Node ID 40ccc1bc6c0a424c1595b3c852d86691c66ca7e5
# Parent  ca577888294601ce076d0d31650c772564e4be62
VObject: fixed visibility bug

diff --git a/Orbitersdk/D3D9Client/D3D9ClientVS2019.vcxproj b/Orbitersdk/D3D9Client/D3D9ClientVS2019.vcxproj
--- a/Orbitersdk/D3D9Client/D3D9ClientVS2019.vcxproj
+++ b/Orbitersdk/D3D9Client/D3D9ClientVS2019.vcxproj
@@ -178,7 +178,7 @@
<PreprocessorDefinitions>WIN32;_WIN32_WINNT=0x0502;_DEBUG;_WINDOWS;_USRDLL;D3D9CLIENT_EXPORTS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
-      <EnableEnhancedInstructionSet>StreamingSIMDExtensions2</EnableEnhancedInstructionSet>
+      <EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>
<WarningLevel>Level3</WarningLevel>
diff --git a/Orbitersdk/D3D9Client/VObject.cpp b/Orbitersdk/D3D9Client/VObject.cpp
--- a/Orbitersdk/D3D9Client/VObject.cpp
+++ b/Orbitersdk/D3D9Client/VObject.cpp
@@ -258,7 +258,8 @@

if (bVis) {
double beta = acos(dotp(pos+cpos, cpos)/(crad*trad));

The full function is this (after patch):
C++:
bool vObject::IsVisible()
{
VECTOR3 pos  = GetBoundingSpherePos();

if (bVis) {

if (beta<alfa) return true;

}

return bVis;
}

#### dbeachy1

Orbiter Contributor
Donator
Beta Tester
Anyone have a (mostly) working set of x64 Orbiter and x64 D3D9 binaries I could download? I have an x64 version of XRSound built, and I'd like to test it.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Anyone have a (mostly) working set of x64 Orbiter and x64 D3D9 binaries I could download? I have an x64 version of XRSound built, and I'd like to test it.
https://snoopie.at/face/beta/x64-Debug.zip

That's the ZIP I'm always updating once there is something new.
Note that there is no texture tree in the Textures folder, so you have to "mklink" Earth/Moon/Mars into it. Don't link a full Textures folder from a released installation, because some stock vessel textures are missing/different there.

#### GLS

##### Well-known member
Orbiter Contributor
Hmm, the bug was not in acos() but in the argument being > 1 (or < -1).

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Hmm, the bug was not in acos() but in the argument being > 1 (or < -1).
Sure, but why did it work in the x86 versions? I checked the logs, it seems to be in since a long time now.

#### GLS

##### Well-known member
Orbiter Contributor
Sure, but why did it work in the x86 versions? I checked the logs, it seems to be in since a long time now.
Maybe the acos() implementation in the x86 lib ignored/limited/whatever the argument or ignored the range...?

#### kuddel

##### Donator
Donator
Regarding acos() ...The x86 version of D3D9Client used SSE2 extensions, which might also contribute...

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Regarding acos() :...
Yes, have seen that, too, thus my suspicion. Anyway, I think it is fair to say that the sanity check is not wrong in that constellation. At least it made it fly .

#### GLS

##### Well-known member
Orbiter Contributor
Just tried acos(1.7) in VS2017 x86 and got "-1.#IND00", and Orbiter didn't CTD and no exceptions where thrown from acos().

Replies
102
Views
8K
Replies
74
Views
6K
Replies
3
Views
169
Replies
1
Views
209
Replies
19
Views
3K