# New ReleaseD3D9Client Development

#### Xyon

##### Puts the Fun in Dysfunctional
Moderator
Webmaster
GFX Staff
Donator
Beta Tester
All I'd say on that is that SVN handles branches very differently from git, be careful....

#### kuddel

##### Donator
Donator
SVN is kind of home territory to me.... git is foreign

#### n72.75

Tutorial Publisher
Donator
SVN is kind of home territory to me.... git is foreign
Other way around for me

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
What should I say? I'm between the chairs with Mercurial .

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I don't want to disturb the transition from x86 to x64 that's going here, but I think I have discovered a bug with D3D9Client. And that bug is that the sun is visible through the planet! I have attached a screenshot of this. You can see the sun where you shouldn't be able to. Scenario is also attached to recreate the bug, uses nothing but the default Project Alpha ISS. Orbiter 2016 with D3D9Client R4.24.

#### Attachments

• Sun_visible_through_planet.jpg
17.8 KB · Views: 17
• Sun_visible_through_planet.txt
840 bytes · Views: 6

#### fatcat

##### Member
Hi,
For the latest D3D9 releases (4.22-4.24) for Orbiter 2016, I get a black rendering when viewing planets at low angles at certain zooms. Older D3D9Client.dll do not give this.
Horizontal haze disable in the video settings removes the black.

Happy to do any testing of settings if it helps.
Sorry if I'm repeating something that has been identified.

#### Attachments

• Capture.JPG
39.1 KB · Views: 21
Last edited:
GLS

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Regarding Git and Orbiter migration:

When using SVN I have usually just 'Checkout' a copy from the SVN repo on a top of an existing Orbiter installation but it looks like the Git can't do that, it needs to do a 'clone' in an empty folder. So, I studied a bit of the CMake and added a cmake-files to the project. So, you can create VS Solution and Project files from there for your preferred VS version. Running the CMake will automatically copy necessary files to your Orbiter Installation Folder. And, So-far, it appears to work reasonably well.

I have also change the directory structure to match the one used by the Orbiter. So, the source files are located in /Src/D3D9Client/ and the sample projects are in the old place /Orbitersdk/samples/

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
You can create working trees that are at a different place than your repository clone in git with the command "git worktree add <path>".

#### 4throck

##### Enthusiast !
Hi,
For the latest D3D9 releases (4.22-4.24) for Orbiter 2016, I get a black rendering when viewing planets at low angles at certain zooms. Older D3D9Client.dll do not give this.
Horizontal haze disable in the video settings removes the black.

Happy to do any testing of settings if it helps.
Sorry if I'm repeating something that has been identified.
Same here. Zoomming in/out fixes the problem for me.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Same here. Zoomming in/out fixes the problem for me.
There is a fix for this in SVN but it would still need to be merged and published.

#### 4throck

##### Enthusiast !
There is a fix for this in SVN but it would still need to be merged and published.
Great, thanks! No rush, I'm aware that these things are complex and take time

#### kuddel

##### Donator
Donator
@fatcat : Does this build fix the issue?
@jarmonik : If fatcat's answer is "yes", then the merge is done, bumping the version number and distribution "still pending"
( or did the fix need some more changes than r1440 & r1442 ? )​

Info:
Code:
Revision: 1445
Author: Kuddel
Date: 2021-08-05 21:30:30
Message:
Merged revision(s) 1440, 1442 from trunk:
- Attempt to fix the horizon ring issue.
- Planet z-fighting fix
----
Modified : /branches/2016
Modified : /branches/2016/Orbitersdk/D3D9Client/VPlanet.cpp

#### Attachments

• TEST-D3D9ClientR4.24++(r1445)-for2016.zip
533.8 KB · Views: 3

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
@jarmonik : If fatcat's answer is "yes", then the merge is done, bumping the version number and distribution "still pending"
( or did the fix need some more changes than r1440 & r1442 ? )​
Yes, that should be it, Thanks. I have uploaded a new version. Since, it's hard to reproduce the problem I can't confirm if it's fixed or not. So, waiting confirmation...

#### kuddel

##### Donator
Donator
By the way, the "32-bit a.k.a. BETA a.k.a. 2019" D3D9Client also got the fix & a version-number increase:
Code:
Revision : 1447,1448
Author   : Kuddel
Date     : 2021-08-05 22:47:33
Message  : - bumped version to Beta 30.8
Merged revision(s) 1440, 1442 from trunk:
- Attempt to fix the horizon ring issue.
- Planet z-fighting fix
Modified : /branches/2019
/branches/2019/Orbitersdk/D3D9Client/D3D9Client.cpp
/branches/2019/Orbitersdk/D3D9Client/D3D9Client.rc
/branches/2019/Orbitersdk/D3D9Client/VPlanet.cpp
/branches/2019/Orbitersdk/D3D9Client/doc/D3D9Client_API_Reference.chm
/branches/2019/Orbitersdk/D3D9Client/doc/Doxyfile
/branches/2019/Utils/D3D9Client/build_release.bat
I think I'll change the build-scripts to generate the ZIPs with the new "2019" name, shouldn't we? It's not BETA anymore

#### fatcat

##### Member
I am in awe at you developers talents.
I replaced the D3D9Client.dll in the Plugin module with the 4.25 version and the problem is fixed.
The 'DG-S ready for takeoff' is a good scenario to troubleshoot this with. Some zooming and panning produces the issue easily.
I swapped back and forth a number of times between 4.24 and 4.25 D3D9Client.dll, testing different scenarios and can reliably confirm that 4.25 fixes the issue.
Many thanks Jarmonik and team.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I have set the GitHub repo for the x64 project over here:
There are few issues with the CMake:

• Is there a way to add a custom folder under a project in the Solution Explorer. I would like the have shader codes in that folder just like the .cpp and .h files are located in their own folders.
• Is there a way to set the "does not participate in build" flag for these files.

Those can be set manually but CMake have a tendency of resetting them from time to time.

Also after moving to CMake there is a major decrease in build speed, so, any ideas how to recover it.

The old project files are still there just in case if we need them.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
You can create working trees that are at a different place than your repository clone in git with the command "git worktree add <path>".
Thanks, that's good to know.

#### martins

##### Orbiter Founder
Orbiter Founder
There are few issues with the CMake:

• Is there a way to add a custom folder under a project in the Solution Explorer. I would like the have shader codes in that folder just like the .cpp and .h files are located in their own folders.
Maybe this? https://cmake.org/cmake/help/latest/command/source_group.html
• Is there a way to set the "does not participate in build" flag for these files.
I am displaying my ignorance here, but I take it that shader codes are GPU scripts that are compiled at run time? If they are not listed as sources for any target in the CMake files, then they technically don't participate anyway. If they are listed, then they will participate in the build of that target, and the target will be rebuilt whenever one of the source files changes.
Those can be set manually but CMake have a tendency of resetting them from time to time.

Also after moving to CMake there is a major decrease in build speed, so, any ideas how to recover it.
Not sure why that would be. Maybe your CMake scripts define additional dependencies that limit the possible parallelisation of the build process? You could also check the compiler and linker flags that CMake assigns, to see if there is anything likely to affect the time (more expensive optimisation settings?).

#### Face

##### Well-known member
Orbiter Contributor