New ReleaseD3D9Client Development

Face

Well-known member
Orbiter Contributor
Beta Tester
The 2016++ versions of Orbiter support vertical resolution of smaller than 1 meter. The above mentioned flattening also supports this now. As for the horizontal resolution, the documentation says level 17, but the code says that the maximum tile level loaded is 15. However - according to the code - a loaded elevation tile corresponds to a loaded texture tile level differently, presumably due to a great-grandfather relation. This would mean that level 15 is loaded by level 18+ texture levels, which would contradict the documentation.

Last edited:

dbeachy1

Orbiter Contributor
Donator
Beta Tester
Are there any configuration steps necessary in order to build the D3D9 client using CMake? What I did was:

1. Clone that latest D3D9 repo to a new folder: git clone [email protected]:jarmonik/D3D9Client.git
2. Run "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars32.bat" to initialize the VS 2019 command-line build environment.
3. CD D3D9Client
4. cmake .
Here is the console output:

Code:
D:\GitHub\D3D9Client>cmake .
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The C compiler identification is MSVC 19.29.30040.0
-- The CXX compiler identification is MSVC 19.29.30040.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done

...but then CMake hangs forever, with Task Manager showing CMake using 100% of a single core, so looks like it's stuck in a loop?

I also tried building D3D9 from inside VS 2019 via D3D9Client\Orbitersdk\D3D9Client\D3D9ClientVS2019.sln and then doing a Rebuild All for the win32 target, but the build fails with:

Rebuild started...
1>------ Rebuild All started: Project: D3D9Client, Configuration: Debug Win32 ------
1>D:\GitHub\D3D9Client\Orbitersdk\D3D9Client\D3D9ClientVS2019.vcxproj(39,5): error MSB4019: The imported project "D:\GitHub\D3D9Client\Orbitersdk\VS2015\PropertyPages\orbiter_plugin.props" was not found. Confirm that the expression in the Import declaration "D:\GitHub\D3D9Client\Orbitersdk\D3D9Client\..\VS2015\PropertyPages\orbiter_plugin.props" is correct, and that the file exists on disk.
1>Done building project "D3D9ClientVS2019.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Am I missing some steps?

kuddel

Donator
Donator
Hey you git-experts out there:
As Jarmo moved the D3D9Client repository to git (including history ), is there a way to convert/change the subversion-authors afterwards?
I mean there were some contributors :
Code:
Felix24 => ???
jarmonik => jarmonik @ git
Jarmonik => [email protected] git
Kuddel => [email protected] git
kuddel => [email protected] git
solarliner => ???
xyon => ????
...hehe from the "case-sensitiveness" I can even say from what machine I committed Jarmo, too it seems

Last edited:

Face

Well-known member
Orbiter Contributor
Beta Tester
Yes. You can convert a git repo to another while filtering branches, data, or even remap meta-data. However, it is history rewriting, and will produce commits with different hashes.

EDIT: just found out that it already has a feature especially for this use-case: https://git-scm.com/docs/gitmailmap

Last edited:

kuddel

Donator
Donator
[...]However, it is history rewriting, and will produce commits with different hashes.
Would that be a problem? I mean now in this early state we should do this - as it would become worse later on I assume.
Deleting my fork and forking again from the new repository is not an issue, now. I have not yet done too much locally

Face

Well-known member
Orbiter Contributor
Beta Tester
Would that be a problem? I mean now in this early state we should do this - as it would become worse later on I assume.
Deleting my fork and forking again from the new repository is not an issue, now. I have not yet done too much locally
Indeed, the classic rewrite approach would be a problem later on, but the mail map approach is much less invasive, as it basically uses a checked in file to remap the author names at the user end, not in the repo data itself.

kuddel

Donator
Donator
Ah! I remember I have read that some time ago (that's why I have a authors.map file laying around on my disk )
That includes e-mail addresses (of jarmo an me)...I guess we have to get permission from each one of them to include that data, right?

Face

Well-known member
Orbiter Contributor
Beta Tester
An example to fix up the various Jarmo entries, you can create a ".mailmap" file in the repo root like so:
Code:
jarmonik <[email protected]> <[email protected]>
jarmonik <[email protected]> <[email protected]>

"git shortlog -sne" will then return:
Code:
   471  Kuddel <[email protected]>
461  jarmonik <[email protected]>
44  kuddel <[email protected]>
2  face <[email protected]>
2  xyon <[email protected]>
1  Felix24 <[email protected]>

EDIT: obfuscated real emails a bit, the SVN thingies are BS, anyway.

kuddel

Donator
Donator
Hmm I have to let that sink in a little bit ....

What makes me wonder is github again, should I add the "github noreply email", too?
...And is that the one I can find at "Account settings" -> "Emails" -> "Keep my email addresses private"?
...And do I have to check that checkbox there?

On github my name should be displayed as 'schnepe2' I guess, as 'kuddel' is someone else on github.

We might skip this to a time when we have nothing else to do
Thanks again for the insights!

kuddel

Donator
Donator
@jarmonik : To give me a break from fighting git(hub), I stepped back a bit and took a look at the D3D9Client sample add-ons.
GenericCamera MFD & DX9ExtMFD made heavy use of gcAPI, which has been removed from the git repository.
What is the plan with that API? Is the plan to add those to Orbiter API?
Orbiter (git) has not yet received changes for those, right?

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Thanks, That did the trick. So-far, I have found no reason for the speed issues. Before it compiled multiple files at the same time and now one by one.

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
@jarmonik : To give me a break from fighting git(hub), I stepped back a bit and took a look at the D3D9Client sample add-ons.
GenericCamera MFD & DX9ExtMFD made heavy use of gcAPI, which has been removed from the git repository.
What is the plan with that API? Is the plan to add those to Orbiter API?
Orbiter (git) has not yet received changes for those, right?
The old and obsolete gcAPI has been removed but the newer gcCore API remains. And those projects are already converted to use the gcCore.

It's likely that the Sketchpad2 &3 would need to be integrated to the Orbiter's Sketchpad interface. But is's too early to say much about the gcCore integration, probably not.

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Are there any configuration steps necessary in order to build the D3D9 client using CMake? What I did was:
I have used the cmake-gui (graphical interface) which seems to work fine. I tried that "cmake ." from command line and it jammed just like you said. From where does it get the platform options, source and binary directories ? If the source and binary directories are the same then "copy folder" might end-up in a loop but that's just a wild guess.

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
Hey you git-experts out there:
As Jarmo moved the D3D9Client repository to git (including history ), is there a way to convert/change the subversion-authors afterwards?
Yeah, it would be nice to get that sorted out. Some of those user names might be from the CodePlex times.

martins

Orbiter Founder
Orbiter Founder
I am trying to build the D3D9Client (64-bit) from the github repo (jarmonik/D3D9Client), but I am running into a problem

undeclared identifier 'gCameraPos' (in Common.hlsl)
Cannot open include file: 'gcAPI.h': No such file or directory (in MFDWindow.h and MFD.h)

gcAPI has been mentioned above, so I guess this is a known issue? Should I wait before trying to compile D3D9Client myself?

jarmonik

Well-known member
Orbiter Contributor
Beta Tester
I am trying to build the D3D9Client (64-bit) from the github repo (jarmonik/D3D9Client), but I am running into a problem

I have committed a fix that removes the dependency to gcAPI.h (something that I didn't notice earlier). For the other problem I have simply selected "does not participate in build" as shown in the screen shot. Those files are compiled during D3D9Client startup.

Attachments

• build.png
124.7 KB · Views: 11

kuddel

Donator
Donator
Is this declaration/definition in CMakeLists.txt O.K. this way?
Makefile:
set(DXSDK_DIR "C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)")

I mean: The Visual-Studio-Projects 'till now assumed the environment variable DXSDK_DIR to be set to the correct location on a build machine.
I for example have one machine where the path differs:
Rich (BB code):
c:\>set
ALLUSERSPROFILE=C:\ProgramData
...
DXSDK_DIR=C:\Program Files (x86)\Microsoft SDKs\DirectX (June 2010)\
...
That's why I only referenced $(DXSDK_DIR) in the project files. Is there something like (Note: NOT actual CMake syntax I believe ): Makefile: if not set environment(DXSDK_DIR) set(DXSDK_DIR "C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)") # default if not proper set in environment # or set(DXSDK_DIR extractFromEnvironmentOrDefault("%DXSDK_DIR%" "C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)")) Last edited: kuddel Donator Donator From searching the net I would guess something like this can do the job (although I have no idea what that CACHE INTERNAL thing is Makefile: if (NOT "$ENV{DXSDK_DIR}" STREQUAL "")
set(DXSDK_DIR)"\$ENV{DXSDK_DIR}" CACHE INTERNAL "Copied from environment variable")
else()
set(DXSDK_DIR "C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)")
endif()

dbeachy1

Orbiter Contributor
Donator
Beta Tester
I have used the cmake-gui (graphical interface) which seems to work fine. I tried that "cmake ." from command line and it jammed just like you said. From where does it get the platform options, source and binary directories ? If the source and binary directories are the same then "copy folder" might end-up in a loop but that's just a wild guess.

So you were right -- CMake from the command line did end up in a copy loop of some sort: I wanted to delete my D3D9Client folder today, and got an error from the path being too deep. It turns out CMake from the command line created a (very very long) path like this:

Code:
D3D9Client\Orbitersdk\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\doc\...

I couldn't delete the tree with Windows, but I was able to finally delete it via rm -rf from Cygwin. I'll try building it with cmake-gui instead of the command line.

jarmonik

Well-known member
Orbiter Contributor