New Release D3D9Client Development

Xyon

Puts the Fun in Dysfunctional
Administrator
Moderator
Orbiter Contributor
Addon Developer
Webmaster
GFX Staff
Beta Tester
Joined
Aug 9, 2009
Messages
6,922
Reaction score
789
Points
203
Location
10.0.0.1
Website
www.orbiter-radio.co.uk
Preferred Pronouns
she/her
All I'd say on that is that SVN handles branches very differently from git, be careful....
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
SVN is kind of home territory to me.... git is foreign ;)
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
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
    Sun_visible_through_planet.jpg
    17.8 KB · Views: 18
  • Sun_visible_through_planet.txt
    840 bytes · Views: 6

fatcat

Member
Joined
May 21, 2008
Messages
110
Reaction score
7
Points
18
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
    Capture.JPG
    39.1 KB · Views: 21
Last edited:
  • Like
Reactions: GLS

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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 !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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. :unsure:
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
@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: 5

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
@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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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
Joined
May 21, 2008
Messages
110
Reaction score
7
Points
18
I am in awe at you developers talents. :salute:
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Top