x64 Development

[Face]

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]

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]

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]

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

DLGPROC (winuser.h) - Win32 apps

Application-defined callback function used with the CreateDialog and DialogBox families of functions.

docs.microsoft.com

 

[jarmonik]

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]

And by declaring the DLGPROC with INT_PTR return type makes it work for either x86 and x64 builds!
See https://stackoverflow.com/questions...tr-ulong-ptr-when-how-and-why/1272382#1272382
and https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types

 

[kuddel]

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

 

[Donamy]

Anything but 2020

 

[Face]

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]

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]

I've found the visibility bug: acos() seems to behave differently in x64 builds

Oh, the joys of C++... ?‍

 

[Face]

Is acos really needed? Which line is affected?

This is the patch fixing it:

# 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):

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]

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]

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]

Hmm, the bug was not in acos() but in the argument being > 1 (or < -1).

 

[Face]

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]

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]

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

acos(double) gives different result on x64 and x32 Visual Studio

acos(double) gives different result on x64 and x32 Visual Studio. printf("%.30g\n", double(acosl(0.49990774364240564))); printf("%.30g\n", acos(0.49990774364240564)); on x64: 1.0473040763868076 on...

stackoverflow.com

 

[Face]

Regarding acos() :...

acos(double) gives different result on x64 and x32 Visual Studio

acos(double) gives different result on x64 and x32 Visual Studio. printf("%.30g\n", double(acosl(0.49990774364240564))); printf("%.30g\n", acos(0.49990774364240564)); on x64: 1.0473040763868076 on...

stackoverflow.com

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]

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