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
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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:
1627590043076.png

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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Oct 16, 2007
Messages
6,904
Reaction score
196
Points
138
Location
Cape
Anything but 2020
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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>
       <RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
-      <EnableEnhancedInstructionSet>StreamingSIMDExtensions2</EnableEnhancedInstructionSet>
+      <EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>
       <PrecompiledHeaderOutputFile>
       </PrecompiledHeaderOutputFile>
       <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 brad = oapiGetSize(gc->GetScene()->GetCameraProxyBody());
-        double crad = cdist;
+        double crad = cdist;
+        if (crad < brad) return true;
         double alfa = acos(brad/crad);
         double trad = length(pos+cpos);
         double beta = acos(dotp(pos+cpos, cpos)/(crad*trad));

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

    bool bVis = gc->GetScene()->IsVisibleInCamera(&D3DXVEC(pos), rad);

    if (bVis) {
        double brad = oapiGetSize(gc->GetScene()->GetCameraProxyBody());
        double crad = cdist;
        if (crad < brad) return true;
        double alfa = acos(brad/crad);
        double trad = length(pos+cpos);
        double beta = acos(dotp(pos+cpos, cpos)/(crad*trad));

        if (beta<alfa) return true;

        double resl = brad - trad * cos(beta-alfa);

        if (resl>rad) return false;
    }

    return bVis;
}
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
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. (y)
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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. (y)
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
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Hmm, the bug was not in acos() but in the argument being > 1 (or < -1).
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Regarding acos() ...The x86 version of D3D9Client used SSE2 extensions, which might also contribute...
 

Face

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

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Just tried acos(1.7) in VS2017 x86 and got "-1.#IND00", and Orbiter didn't CTD and no exceptions where thrown from acos().
 
Top