New Release D3D9Client Development

[GLS]

What kind or graphics hardware you have since you also saw those flickers/flashes ?

I have the usual embedded Intel GPU plus an NVIDIA GPU, but I can't remember the details of them now... I'll post them later today.
Honestly, most of the times I don't even know which one is being used, since microsoft decided that having the GPU selection in the context menu was too complex for users and decided to bury it inside 4 menus (or whatever number it was).
I'm probably using the NVIDIA, but I might have not configured the new Orbiter executables to use it, so those might actually be using the Intel GPU.

The original texture remains in a memory since it could still be used by other vessels of the same class, it's shared. It doesn't cause performance issue of any-kind.

Thanks! I'll sleep a bit better tonight.

 

[kuddel]

[...]There is an occasional exception @ intptr_t PlanetarySystem::FindNext (intptr_t fh, _finddata_t *fdata, char *fname) of Orbiter Core[...]

The issue was a (now) wrong type for the 64 bit build. This PR fixes that.

 

[martins]

Thanks for the bug fix! Regarding the 283 branch - I am ready to merge that now, unless you wanted to implement the missing D3D9 client frame axis display in that branch.

 

[kuddel]

No no, please move on with the merge! I'm pretty sure I would mess it up with my git inexperience
That might better go into a seperate PR.

 

[GLS]

As promised: NVIDIA RTX 3050 and Intel UHD Graphics.

 

[kuddel]

Grrr how I hate github/git! Please ignore the PR#292 as it seems it has too many commits in it that are totally unrelated to the issue fixed!
I'll try to undo it and try again.

 

[kuddel]

It gets even worse!
Can someone tell me why this branch (on my orbiter fork at github) is 5 commits ahead and has 10 files changed, although I only changed these 5 files:
Scene.cpp, VObject.cpp, VPlanet.cpp, VVessel.cpp, VObject.h, VPlanet.h & VVessel.h

GitHub - schnepe2/orbiter at d3d9_object_axis_display2

Open-source repository of Orbiter Space Flight Simulator - GitHub - schnepe2/orbiter at d3d9_object_axis_display2

github.com

I fetched & pulled and switched to "main"; then I edited the 5 files; I did a commit into a new branch (called 'd3d9_object_axis_display2') and pushed it to 'origin' (github I assume)...now all those changes from completeley different branches appear in that PR!

 

[GLS]

I didn't checkout you fork, so I might not be seeing the whole picture, but in github it seems you merged orbiter/main into your fork (https://github.com/schnepe2/orbiter/commit/5424cae7363ec96d3fa7d8aac33fbc21dbfc8c89), which might somehow be the issue here... To update my orbiter fork I just open it in github and select the "Sync fork" option, right next to the indication that my fork is behind, and it doesn't need a commit or anything. I do that right before creating a branch for whatever.

 

[GLS]

Went ahead and checked out your fork and I think I found the issue:

It seems your d3d9_object_axis_display2 branch starts at the d3d9_noise_problem branch and not at main, and so even with merging main into it, you will still have those changes in there.
Probably the cleaner solution is to just forget the d3d9_object_axis_display2 branch (it seems like it is only in your fork), go back to main, if needed sync in github in order to have the latest changes from orbiter/main, then branch from there into a d3d9_object_axis_display3 branch, and just copy-past the changes, test, commit, then PR.

 

[jarmonik]

It seems your d3d9_object_axis_display2 branch starts at the d3d9_noise_problem branch and not at main, and so even with merging main into it, you will still have those changes in there.
Probably the cleaner solution is to just forget the d3d9_object_axis_display2 branch (it seems like it is only in your fork), go back to main, if needed sync in github in order to have the latest changes from orbiter/main, then branch from there into a d3d9_object_axis_display3 branch, and just copy-past the changes, test, commit, then PR.

I did read something about "rebase" but have never used it. So, could some expert give an example how to rebase "d3d9_object_axis_display2" to top of "main" ? But anyway it's no problem if "d3d9_noise_problem" gets merged along with "d3d9_object_axis_display2".

Git is so much more complex than SVN. I actually patched "d3d9_atmosphere_remake" branch together with "main" locally on my local hard drive using Winmerge before committing the branch. I didn't even bother to try to merge it from my orbiter fork. It was better to do it manually than risk automation to mess it up and the days it would take to resolve it.

 

[jedidia]

I did read something about "rebase" but have never used it. So, could some expert give an example how to rebase "d3d9_object_axis_display2" to top of "main" ?

I'm far from an expert, but afaik rebasing is something you should only do on local branches, to synch them back up with the remote. Rebasing a remote branch can screw up everybody else, since it rewrites history.

 

[GLS]

Git is so much more complex than SVN. I actually patched "d3d9_atmosphere_remake" branch together with "main" locally on my local hard drive using Winmerge before committing the branch. I didn't even bother to try to merge it from my orbiter fork. It was better to do it manually than risk automation to mess it up and the days it would take to resolve it.

For people inside the project, you can just branch from orbiter/main and you don't even need a fork.

 

[kuddel]

[...]To update my orbiter fork I just open it in github and select the "Sync fork" option, right next to the indication that my fork is behind, and it doesn't need a commit or anything. I do that right before creating a branch for whatever.

That's something I do every time. My "main" is "in sync". Because I had similar strange behaviours all the time I sync every time orbitersim/orbiter has anything changed.

 

[kuddel]

[...]Probably the cleaner solution is to just forget the d3d9_object_axis_display2 branch (it seems like it is only in your fork), go back to main, if needed sync in github in order to have the latest changes from orbiter/main, then branch from there into a d3d9_object_axis_display3 branch, and just copy-past the changes, test, commit, then PR.

That is exactly what I've done! - At least I think I did.
On my local machine I have fetched all branches from "origin" (my github I assume);
then I switched my local working copy to "main" (with I assumed to be "the same" as the sync'd github)...
I even checked, that no changes from "d3d9_noise_problem" were in the source code! Therefore I assumed that my local copy is perfectly sane.

I am always amazed how complicated one simple commit can get with git + github! A 15 minute coding session is followed by 2 days of frustration and uncertainty
I know that it's my fault, 'cause Linus can't be wrong, right?

For people inside the project, you can just branch from orbiter/main and you don't even need a fork.

I am not "inside the project". I use a fork and have to create pull requests from that fork, right?

And regarding "rebase": I will not even try to do something like that, as I have no real idea about what that means
And cherry-picking is much to much hassle here. The changes are very simple - that's why I made the 2nd attempt (d3d9_object_axis_display2), but that looked the same afterwards...
I think I will (again)

• delete the whole development directory,
• go to my github web page and sync everything (every cync button I can click on ... )
• then check-out "origin/main" into a fresh new directory
• and see whether I can commit into a 3rd newly named branch.

 

[kuddel]

While I am not at the machine where I can do the development/git-things: This PR from "computerex" seems to be exactly what I had in mind
so if the doctor (or Jarmo) would like to merge that I am happy with that

 

[GLS]

I am not "inside the project". I use a fork and have to create pull requests from that fork, right?

Yes. So to avoid issues merging PRs, you should keep your fork synced, and then just branch as you please in your fork but, to keep things simple, do it from your main and not from another branch (which I think is what happened). Imagine your fork is the repo and don't worry about the orbiter/main. When you are ready to merge, go to github and there should be an option to create a PR and choose you branch.

I am always amazed how complicated one simple commit can get with git + github! A 15 minute coding session is followed by 2 days of frustration and uncertainty

Coming from svn, git is a step in the "complex" direction but the basics are pretty much the same. Github adds another layer of complexity, but IMO the basics weren't too hard to grasp. You just have to be sure what branch you have checked out and which repo it calls origin.

 

[martins]

While I am not at the machine where I can do the development/git-things: This PR from "computerex" seems to be exactly what I had in mind
so if the doctor (or Jarmo) would like to merge that I am happy with that

Thanks - I have now merged the computerex PR. Sorry to hear that git causes problems. I guess the more repositories there are, the easier it is for things to go out of sync. In that respect, my life is probably slightly easier, since my only remote is orbitersim/orbiter. I don't have the additional headache of pulling from one repository and pushing to another ...

 

[N_Molson]

I'd like to learn Git one day but what I see here scares me a little bit

 

[kuddel]

Thank you all for the tips.
Still my local copy behaves very very strange
I' go the long way and start from scratch, as I suspect the .git folder to be somehow broken.
Let's hope I have fewer problems next time

 

[martins]

A request for help with implementing a new feature in the D3D9 client:

PR 294 contains a nice new feature to render the bright stars of the Hipparcos and Tycho datasets as a texture map, in addition to the current pixel rendering. I found some very nice high resolution maps here: https://svs.gsfc.nasa.gov/4851. To support this, I have extended the celestial sphere manager (CSphereMgr.{h,cpp}) to render (up to) two background texture sets:

• the starfield textures for the bright stars
• and, as before, the background textures for milky way background or special all-sky surveys at particular wavelenghts

If both texture sets are present, they use additive blending.
I have implemented this for the inline and D3D7 clients, but I have too little knowledge about DX9 to do it for the D3D9 client. Any takers? The relevant code for setting up the two texture sets in the D3D7 client is in CSphereManager::Render. I have already added the code for loading the texture sets in D3D9Client, all that's left is the rendering.

In addition, this PR adds a new feature for hot-changing the celestial sphere rendering options in a running simulation via a new Options dialog (F6). This is much cooler than having to set fixed options in the Launchpad dialog before the simulation run. This should work for all graphics clients, with the exception of the "Background stars: show as image" setting in the D3D9 client (see above). I am planning to extend this new Options dialog in the future to include more parameters currently set in the Launchpad dialog. Give it a go!