New Release D3D9Client Development

[jarmonik]

Due to the fact that the inline client doesn't have this issue I think these parameters are (a little) different there.

Can the Doctor maybe give us the "magic" values or update the D3D7Client code?

That was discussed in this forum some time ago but I couldn't find it. The inline client do have a problem with the alignment but not as bad as the D3D7Client does. I tried to tweak the values and I was able to get some start aligned properly but not all of them.

double theta = 60.28*RAD;
double phi = 90.08*RAD;
double lambda = 173.7*RAD;

 

[kuddel]

We can use your "better than before" values, but
I think we should still wait a bit whether the Doctor might provide "even better" values.

By the way, when I tried to "guess" better values, I used re-programmed Debug-Control Sliders.
But the 'WASD'-Patch might also be nice to visually approach even closer values.
(Keys for increment,decrement, theta-,lambda-,phi-selection, factor*=10, factor/=10 and one to spit out the values)

 

[Marg]

When using d3d9 I see, "seams" in the sky, if zoomed in (10 degrees)...

 

[jarmonik]

No show-stopper, but I was getting shimmering planetarium labels in both Windowed and full screen modes, couldn't isolate a particular cause. doesn't occur in the in line client, I'm not at my PC to test furthrr at the moment.

Planetarium mode labels are rendering just fine here. Could you be little more specific what you mean by shimmering.

---------- Post added at 16:34 ---------- Previous post was at 16:32 ----------

When using d3d9 I see, "seams" in the sky, if zoomed in (10 degrees)...

I haven't seen any. Could you take a screen shot from the seams. That might help to identify the problem.

 

[Marg]

it is flashing vertical line, above and underneath the rocket...
http://imgur.com/sA98B5h

 

[Weirdo Earthtorch]

Planetarium mode labels are rendering just fine here. Could you be little more specific what you mean by shimmering.

OK, further testing:

Orbiter Beta 151119
D3D9Client Beta13c 25/11/15
Windows 7 Professional
GTX750Ti NVidia 355.6

This only occurs in 'True Full Screen'. It does not occur in 'Full Screen Window', or 'Window With Taskbar'; nor in windowed mode.

It affects both planetarium labels, Orbiter drop-down menus and MFDs in all cockpit modes.

It is a flickering, at (I guess) monitor refresh rate. I tried to capture it with 'Bandicam' but it is not recorded presumably because of the way that program intercepts the graphics output. Instead I have attempted to capture it using a mobile phone camera.

The flickering is stopped when any kind of window is opened eg CTRL+F4, and resumes upon closure of the overlaid window. (note that the video does not show planetarium mode on, because at that point I had discovered the effect on the MFDs too).

The video below does a pretty good job of showing the effect, given the differences in output framerate and capture framerate.

Hope this helps.

​

 

[kuddel]

The video below does a pretty good job of showing the effect, given the differences in output framerate and capture framerate.

Hope this helps.

Yes it does :thumbup:

Interesting. Is there a significant drop in frame rate when the overlay window is open?
Or does this flicker also happen when you run Orbiter with "fixed time steps"?

 

[SolarLiner]

I tried to capture it with 'Bandicam' but it is not recorded presumably because of the way that program intercepts the graphics output.

Try with OBS Multiplatform next time. It's free, and works

/off-topic

So I finally went at it again. Downloaded all the high-res textures for the planets, and loaded up a scenario.

This is even better than I imagined. This is top notch work, guys :thumbup:

 

[Weirdo Earthtorch]

Solved

Yes it does :thumbup:

Interesting. Is there a significant drop in frame rate when the overlay window is open?
Or does this flicker also happen when you run Orbiter with "fixed time steps"?

It still occurs using fixed time steps; with no significant frame rate drop with an overlay window open. However...I think I have found the cause:

I had used NVidia Control Panel to enable antialiasing in True Full Screen (modifying \modules\server\orbiter.exe). I had applied 'Override any application setting' for the Antialiasing mode. It turns out this is the issue in this case.

The fix is to use 'Enhance the application setting' ==> no menu/MFD/planetarium flicker.
:thumbup:

 

[jarmonik]

It still occurs using fixed time steps; with no significant frame rate drop with an overlay window open. However...I think I have found the cause:

We had that kind of flickering with a local light sources in the past due to uninitialized data being fed to a shaders. This is likely due to something different. BTW, What is your "MFD refresh [sec]" setting in Parameters tab ?

---------- Post added at 22:36 ---------- Previous post was at 20:07 ----------

it is flashing vertical line, above and underneath the rocket...

How well the line is visible is likely a hardware dependent issue. When having anti-aliasing turned off I was able to see a few dots from time to time.

I have rotated the sky-dome so that the "seam" locations are as far from the vessel as possible. Now that the "seams" are no-longer aligned with the vessel and the camera they are likely not showing up as bad as before. If it's still a problem in the next release then we have to find a better solutions.

 

[Weirdo Earthtorch]

We had that kind of flickering with a local light sources in the past due to uninitialized data being fed to a shaders. This is likely due to something different. BTW, What is your "MFD refresh [sec]" setting in Parameters tab ?

It was initially the default 0.10. I changed it to my 'usual' setting of 0.05 when I was testing, I don't believe it made any difference.

The flickering was definitely brightness - changing between dim and bright; and it was more random than I first thought in terms of timing.

Just re-tested with various different settings - VSync enabled/disabled; fixed time steps; various MFD refresh rates; local light sources enabled/disabled. None seem to affect the flicker in any way in TFS - it's only a window overlay, or the NVidia control panel setting change, that stop it.

 

[kuddel]

D3D9Client SVN repository change

Hello everybody,

due to the many problems we had with CodePlex hosting the D3D9Client repository, we left them and moved the repository to another host.
With many thanks to Xyon I can announce that the repository will from now on be here:

svn://mirror.orbiter-radio.co.uk/D3D9client

I've had to re-create the complete repository, so it will "look" a little bit different than it looked at CodePlex.
Most noticeably will of cause be the much lower revision number(s).

If you have a local working copy of the 'old' CodePlex repository you cannot "relocate" it, sorry.
The easiest would be to completely checkout a new working copy.
Another approach is to just delete the ".svn" folder and check out (from the new URL) into that folder. TortoiseSVN will warn about checking out into a 'non-empty' folder, but that's O.K. It should not overwrite any local changes you might have done to any version'd files. Although I would recommend to backup first - better save than sorry -

Again, we have to thank Xyon for setting up the repository server!

/Kuddel

Now a (brief) list of changes I did with regards to the CodePlex repo:

• Author names changed from CodePlex account names to OrbiterForum account names
  'SND\Kuddel_cp' => 'Kuddel'
  'SND\jnikkanen_cp' => 'Jarmonik'.
  'SND\felix24_cp' => 'Felix24'.
• Filled empty log messages, whenever I could guess what happened.
• Fixed 'move' operations. These operations were not recorded correctly at CodePlex, where they were just one 'delete' and another 'add' operation.
• I skipped some erroneous tag creations to be what they were supposed to be. (was added branch, deleted branch, added tag).
• Removed "rude" comments about CodePlex SVN-wrapper and did not re-create the affected branches. They were not much of use in the first place.
• Some 'split' commits (consisting of several individual commits) into single commits.
• Added missing merge information that was not stored in the CodePlex repository.
• Comments referring to CodePlex revision numbers corrected.
• Completely skipped branches that were never to be there ("branches/R13.1" e.g. was always intended to be "branches/2010-P1").
• Created tags for each "released" version, as close as I could gather the information. Some tags (Beta 5 -7) might not be a 100% accurate representation of released versions. But very close

 

[Matias Saibene]

Excuse my ignorance, but from there we can get the D3D9beta client for Orbiter Beta?

 

[jarmonik]

Thanks for re-creating the repository for the project. There is still one question remaining. How do we handle the distribution of the binaries ? Anyone willing to maintain a download site ?

---------- Post added at 04:55 ---------- Previous post was at 04:54 ----------

Excuse my ignorance, but from there we can get the D3D9beta client for Orbiter Beta?

Here: http://www.orbiter-forum.com/showthread.php?p=520444&postcount=3273

 

[kuddel]

Thanks for re-creating the repository for the project. There is still one question remaining. How do we handle the distribution of the binaries ? Anyone willing to maintain a download site ?

That's currently the only downside of the switch. If we really would like to leave CodePlex we need replacements for the following services (in order of importance):
- Binary distribution page (posting them in this thread does kind of work, though).
- "Home page" containing the (online-)documentation. (the distribution binary contains the documentation anyway, so this might be even less important).
- Bug tracking feature (this might well work with the forums bug section).

Being unfair, we could still just use the CodePlex service for these so far.

But I kind of dislike it, 'cause if we say "goodbye" to CodePlex we should be fair -even to them-.

/Kuddel

 

[Face]

If we really would like to leave CodePlex we need replacements for the following services (in order of importance):
- Binary distribution page (posting them in this thread does kind of work, though).
- "Home page" containing the (online-)documentation. (the distribution binary contains the documentation anyway, so this might be even less important).
- Bug tracking feature (this might well work with the forums bug section).

What about one of the other social coding sites like Github or Bitbucket? Even if you don't use their repository service, you could use the other services there. Of course that wouldn't differ too much from just staying with Codeplex for that.

 

[jarmonik]

- Binary distribution page (posting them in this thread does kind of work, though).

That is only available for registered users.

- "Home page" containing the (online-)documentation. (the distribution binary contains the documentation anyway, so this might be even less important).

No need for online documentation since it is distributed with the client.

- Bug tracking feature (this might well work with the forums bug section).

That would be good to have. It's a little difficult to track bugs, I usually tend to forget them. But we have made-it this far without it.

I have been trying to get the reflections back online, it's probably not a good idea to commit the changes into a trunk until they are properly tested. So, should I create a new branch for this revision and then merge it to trunk when ready ? Or how things like that are supposed to be handled ?

Tag/branch....
To Path: /branches/refl/
Create copy in repository from: Working copy
Create intermediate folders: Checked

 

[kuddel]

That is only available for registered users.

Oh! That's not so nice. I did not think about that.

No need for online documentation since it is distributed with the client.

Exactly. I think this is one of our minor issues.

That would be good to have. It's a little difficult to track bugs, I usually tend to forget them. But we have made-it this far without it.

Yeah, it's better to have a bugtracker. But a 'directory' under http://www.orbiter-forum.com/project.php e.g. might be enough.
To file a bug, one has to register anyway.

I have been trying to get the reflections back online, it's probably not a good idea to commit the changes into a trunk until they are properly tested. So, should I create a new branch for this revision and then merge it to trunk when ready ? Or how things like that are supposed to be handled ?

Exactly like that! :thumbup: A perfect example of a 'feature-branch'.
Merging that branch back to trunk later whenever you think it's worth it.

Tag/branch....

To Path: /branches/refl/
Create copy in repository from: Working copy
Create intermediate folders: Checked

The "Create intermediate folders" options is not important. I never checked that (...not even sure what it does )

The "Create copy in repository from" selection should be selected depending on your situation:

• If you have local changes in your (currently still "trunk" based) working-copy that you would like to have committed immediately as first revisions in the (new) branch: select "Working copy".
• Usually you branch from a working-copy with no local changes and select "HEAD revision from repository" here.
  After that you start to make changes in the working-copy (now "branches/refl" based).

But either way is O.K.

 

[Ripley]

Just to understand: do we now get the D3D9 client the same way we get Orbiter 2015 Beta?

I've set up a D3D9 folder, performed a "SVN checkout", and it downloaded a whole lot of stuff, where I found a "Orbiter2010-P1" folder.
Is that the one I'd need, or did I get it wrong?

 

[kuddel]

Just to understand: do we now get the D3D9 client the same way we get Orbiter 2015 Beta?

Yes and No

The repository just contains the sources to build D3D9Client. No compiled binaries (in contrast to the Orbiter repository).

I've set up a D3D9 folder, performed a "SVN checkout", and it downloaded a whole lot of stuff, where I found a "Orbiter2010-P1" folder.
Is that the one I'd need, or did I get it wrong?

The D3D9Client repository is organized as "standard" subversion repositories:
/trunk : contains the latest development sources (for Orbiter BETA)
/branches/xxx : contain different branches for different purposes.
/branches/2010-P1 : ...for example contains the sources to build the Version for Orbiter 2010-P1
/branches/Reflect : ...is a so called 'feature branch', that is used during development to implement a specific feature, which contents will eventually be merged back to trunk (or another version-branch, or both).
/tags/xxx : Contain the sources for a released version.

So if you are only interested in the BETA builds, you should checkout only the "/trunk" path.
But as said above: It only contains the sources, no binaries.
In case you like to build from the sources, you need some external libraries (DirectX that is) and a Visual Studio (2008, 2010 or 2012).
If that preparations are met, you should easily roll your own by running the
batch job "Utils\D3D9Client\build_release.bat" in your working copy.

For debugging and/or developing the folder "Orbitersdk\D3D9Client\" contains the necessary Solution files (D3D9ClientVS2008.sln,
D3D9ClientVS2010.sln and D3D9ClientVS2012.sln) for your version of Visual Studio (Express editions work fine)

---------- Post added at 21:50 ---------- Previous post was at 21:37 ----------

-------------------------
But it is recommended to use (binary) builds posted here
Setting up your system to build D3D9Client from the sources is not that complicated, but the "devil is in the details" - as usual.
The explanations in Orbitersdk\D3D9Client\README.txt might be a good first step, although it is a bit outdated (getting Orbiter BETA is easier now).