New Release D3D9Client Development

[Xyon]

All I'd say on that is that SVN handles branches very differently from git, be careful....

 

[kuddel]

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

 

[n72.75]

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

Other way around for me

 

[Face]

What should I say? I'm between the chairs with Mercurial .

 

[DaveS]

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.

 

[fatcat]

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.

 

[jarmonik]

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]

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]

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]

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]

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]

@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:

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

 

[jarmonik]

@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]

By the way, the "32-bit a.k.a. BETA a.k.a. 2019" D3D9Client also got the fix & a version-number increase:

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]

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]

I have set the GitHub repo for the x64 project over here:

GitHub - jarmonik/D3D9Client

Contribute to jarmonik/D3D9Client development by creating an account on GitHub.

github.com

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]

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]

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]

I have set the GitHub repo for the x64 project over here:

GitHub - jarmonik/D3D9Client

Contribute to jarmonik/D3D9Client development by creating an account on GitHub.

github.com

I've ported the flattening code and refactored it for API usage. The following pull request is rebased (and tested) on the recent main: https://github.com/jarmonik/D3D9Client/pull/1 .

 

[n72.75]

Was this https://www.orbiter-forum.com/threa...-sceneries-for-orbiter-2016.38022/post-571024 issue/vertical horizontal resolution issue ever resolved?