New Release D3D9Client Development

[jarmonik]

I've noticed that you've changed some places where this is called in a way, that you provided two different char buffers for fname and path.
The method however returns false in case the path is not valid (anymore).
I know that the content is changed, but as long as we respect the return value it was O.K. on my tests.
Have you experienced any unexpected results in that case? I can not see why/where.
Anyway I'll take a look in how a "specialized" version of TexturePath might benefit in cleaner and easier to maintain application code...
It needs to be thread-save, right?

I noticed a problem with the search paths when looking at Saturn which had no rings. My investigation about the missing rings revealed that texture search path was messed up like having multiple paths mixed and my quick conclusion was that input and output can't point to the same buffer. Not sure if that's really the case but it solved the problem of missing rings.

Yes, it need to be thread safe since it's called from a tile loader thread too.

---------- Post added at 01:35 ---------- Previous post was at 01:29 ----------

That is that colors during sunrise/sunset really look to yellow. It should be more orange/red, with less yellow/green in it.
Of course I can change settings with Ctrl+F4->Atmosphere controls. Adding a bit more red and lowering the green helps. But it also changes the color of the blue daylight sky. So i think there is a problem with the defaults.

It is imperfect atmospheric model and it simply cant get everything right at the same time. Fixing on thing breaks something else. I am pretty happy that it works as well as it does considering how simple rough approximation it is. There are more important things in a schedule so I am not going to start working on it anytime soon.

---------- Post added at 01:52 ---------- Previous post was at 01:35 ----------

A possible bug report: This is actually something I started noticing a few releases back for 2010-P1, it's that the diffuse particle streams are abnormally dark, almost to the point that they look soot. Is this the intended appearance or as something gotten broken?

It should match pretty closely the in-line engine. It should shift towards dark when viewing against the sun. (i.e. particles between the camera and the sun). If it's 2010-P1 issues then it may take some time until anyone looks into it.

I have been thinking about the VC lighting issues. How well would you guys be doing with just two or four pixel lights per mesh group and in addition to that one irradiance map to help with the ambient light.

- There could be 32 light sources per vessel from which:
- Eight most effective light sources would be selected for each mesh in a per frame basis and from which:
- Two or four most effective light sources would be selected for each mesh group for actual rendering.

---------- Post added at 01:58 ---------- Previous post was at 01:52 ----------

- Two or four most effective light sources would be selected for each mesh group for actual rendering.

The selection would be done by using light-cone / bounding sphere intersection checks and light range and attenuation checks.

 

[DaveS]

It should match pretty closely the in-line engine. It should shift towards dark when viewing against the sun. (i.e. particles between the camera and the sun). If it's 2010-P1 issues then it may take some time until anyone looks into it.

It's actually present in both. I first noticed in a 2010-P1 release and it has hung around the 2016 releases as well. I do think it's too dark if you compare it with real very white streams like the GOX venting from the GOX vent arm:

STS-114 Tanking Test 1, April 14 2005, mid-morning

STS-114 Tanking Test 1, April 14 2005, mid-afternoon, weather system moving in over the Cape

 

[Eduard]

It is imperfect atmospheric model and it simply cant get everything right at the same time. Fixing on thing breaks something else. I am pretty happy that it works as well as it does considering how simple rough approximation it is. There are more important things in a schedule so I am not going to start working on it anytime soon.

Ok, I can understand that, it must be difficult and time-consuming stuff to do.
Above all, many, many thanks for all of the hard work you have done so far.


Then about totally another thing, namely the version for Orbiter 2010-P1:
I am currently still using your new build R16.5 posted here: http://orbiter-forum.com/showthread.php?p=530736&postcount=3691
Is this still the latest build for Orbiter 2010-P1?

And will it also finally become a download on http://d3d9client.codeplex.com/, like version R15?

If it is the case, than I can report the following problem:
When using the Attitude RCS MFD, there are problems, especially when switching between the screens with F8:
> When using the XR2, fonts are changing, from very big texts to very small, and even vertical texts, so something clearly goes wrong.
> When using this MFD with the Deltaglider and switching between screens with F8, a CTD immediately occurs. And I have also seen weird font changes here.

 

[kuddel]

I noticed a problem with the search paths when looking at Saturn which had no rings. My investigation about the missing rings revealed that texture search path was messed up like having multiple paths mixed and my quick conclusion was that input and output can't point to the same buffer. Not sure if that's really the case but it solved the problem of missing rings.

Strange pattern here: Almost always this works:

char path[MAX_PATH] = "path\\to\\foo.dds";
if (gc->TexturePath(path, path)) {
  // path is either "Textures2\\path\\to\\foo.dds"
  //             or "Textures\\path\\to\\foo.dds"
} else {
  // path now contains *rubbish*
}

But at one point (at least) this didn't work
Looks like a too short fname can not be handled correct by TexturePath...
As long as it is not clear whether fname and path for TexturePath can be the same memory location, I'll add a wrapper function for this.

Maybe martins can give some insight on this?

 

[martins]

Using the same pointer for fname and path is NOT allowed.

Orbiter first copies its internal HTexDir string to path and cats fname to the end.
If opening that file fails, it copies the internal TexDir string to path and cats fname to the end. If that also fails to open, it returns false.

 

[kuddel]

D3D9Client Texture-Path-issue fix

This may be a Bug or a Feature but, I had a problem with no planet textures showing in the D3D9 Client but it the inline client it was fine.

I had created a folder for the highres textures in the \Textures2 folder with the same structure as the \Textures folder eg. \Textures2\Earth\Archive . But I put the HighRes Textures in \Textures\Earth\Archive in stead and forgot to delete the Tex2 folders but left them empty. I seems that the D3D9 Client does not check to see if a folder has anything in it before defaulting to using the textures in the \Textures2 folder.

Hope it helps.

Hi Evil_Onyx,

could you try this build and check if it fixes your issue?
It's just the DLL (you might backup your local copy, although this one should not be worse ).

 

[kuddel]

@Jarmo: Do you think we have to include the r55 changes of D3D7Client into our code?
To be precise: I am talking about the changes in VPlanet class that add horizon_minrad.
I think that we already have respected these rendering special handling by use of our vPlanet::GetMinElevation() etc., right?

If we would have to also respect the new planet configuration parameter OBJPRM_PLANET_MINELEVATION (new in Orbiter Beta r63),
should we create a "2016" branch (for the "official" 2016 Version) and continue development for new betas on trunk ?
Another solution would be to extend the OapiExtension analog to what we did for GetConfigParam. This would make the same code compile for either 2016 and for "2016++", but would need to add some extra coding.

If you ask me, I would make a branch and merge fixes that work for both versions there.
Just as we did with the 2010 version.

 

[jarmonik]

To be precise: I am talking about the changes in VPlanet class that add horizon_minrad.
I think that we already have respected these rendering special handling by use of our vPlanet::GetMinElevation() etc., right?

Yes, I guess it would be better to include it. vPlanet::GetMinElevation() changes depending on what's in a view where as horizon_minrad would remain constant.

If you ask me, I would make a branch and merge fixes that work for both versions there.
Just as we did with the 2010 version.

Yes, I agree. After thinking about it for a while that was my conclusion too.

---------- Post added at 01:39 ---------- Previous post was at 01:32 ----------

Our current handling of D3D9 specific material properties through the configs in Config/GC/ is a bit chaotic. Should we do the loading of a mesh file on a client side allowing us to read D3D9 specific information from the file. But that, of course, would require some changes to the Orbiter too.

 

[kuddel]

I've created a "2016" branch (only for Orbiter 2016, not for Orbiter Beta r63 and the Betas to come)
and tagged the "2016-R1" Edition.

I've included the changes of OVP r55 (in trunk), but I have no idea how this would have any effect, cause we're almost always using HazeManager2...

 

[T1234]

Ring Textures

Here are ring textures for Uranus and Neptune for use with latest D3D9.

 

[Evil_Onyx]

Hi Evil_Onyx,

could you try this build and check if it fixes your issue?
It's just the DLL (you might backup your local copy, although this one should not be worse ).

Nope, I have attached some screen shots to help show the problem.

 

[kuddel]

Nope, I have attached some screen shots to help show the problem.

Thanks for the screenshots.
That setup is something I did not expect Strange, but let's see if I can reproduce (and fix) something here.

---------- Post added at 19:46 ---------- Previous post was at 18:53 ----------

@Evil_Onyx : The behavior is intended (see question here and the answer here).
I would recommend to completely remove the (empty anyway) folder "Earth" from "Textures2".

You might also move the HighRes Textures (tree-files) completely under "Textures2".
This however is not recommended, 'cause the D3D9Client (and Orbiter itself) will probably not look into that folder for tree-files in future releases[1].
So either all Planetary HighRes Tree Textures under ./Textures/ or all under ./Textures2/; don't mix 'em!

[1] to behave equal to the inline client and D3D7Client reference.

 

[jarmonik]

Is anyone else having Orbiter launch problems with the D3D9 client when using Windows 10. About 25% of the time render window won't appear when pressing the Launch button from the launchpad. I can quit the orbiter to launchpad by pressing Ctrl+Q so the Orbiter is running.

This problem started to appear few months ago right after installing Windows 10.

 

[dbeachy1]

Hmm, it works for me in Windows 10. However, I do see CTDs sometimes (maybe 5% of the time?) when loading a scenario using the D3D9 client. Then when I reload the scenario it works fine. Maybe it's related??

 

[jarmonik]

Is anyone else having Orbiter launch problems with the D3D9 client when using Windows 10. About 25% of the time render window won't appear when pressing the Launch button from the launchpad. I can quit the orbiter to launchpad by pressing Ctrl+Q so the Orbiter is running.

This problem started to appear few months ago right after installing Windows 10.

In addition to above. There are nothing unusual in the D3D9Client.log, it shows a window handle, creates D3D device, loads textures, resets the D3D device successfully on exit and appears to take "Current State" screen shot properly :lol:

 

[Weirdo Earthtorch]

I've been using Windows 10 roughly since it first appeared. I don't recall any issues with the D3D9 client not displaying a window correctly.

One issue I did have was when using multiple displays (laptop plus external monitor) - sometimes the render window would be positioned off-screen if I had previously used the external monitor then switched to just the laptop display - but that wasn't Windows 10-specific. IIRC I may have posted something about it way back.

 

[Abloheet]

Yeah. Never faced a problem with Orbiter on Windows 10. Is you windows 10 installation fresh one or upgraded one from Windows 7? I upgraded from Windows 7, then fully formatted my pc and reinstalled windows 10 latest build. No problems since then

 

[SolarLiner]

I had the same problems when using Fullscreen Window mode and a selected resolution that differed from the desktop one (I set this up so that I could quickly change between 1080p and 4K using NVIDIA's DSR mode). The result was a 5x5-ish winidow that would display on the top left of the screen. ALT+F4 and restarting the scenario would fix the issue.

 

[Eduard]

Is anyone else having Orbiter launch problems with the D3D9 client when using Windows 10. About 25% of the time render window won't appear when pressing the Launch button from the launchpad. I can quit the orbiter to launchpad by pressing Ctrl+Q so the Orbiter is running.

This problem started to appear few months ago right after installing Windows 10.

Yes, I do. In that case the item in the Taskbar appears, but no screen becomes visible.
Most of the time I use Alt+F4 to exit, but Ctrl+Q also works I believe.
Things like Orbitersound still function in that case, an indication that Orbiter is in fact completely running, but that purely the display function of the client fails.

And there is also a second problem: the "Respawn Orbiter process" setting (which I always use to be more shure of a stable Orbiter-process) from the Orbiter shutdown options does not always work correctly, because the Launch-pad is not always started again.
(I am not shure if this is an Orbiter core problem or a D3D9Client problem.)

 

[jarmonik]

I used this code to check the window status:

RECT rS;
	
GetClientRect(hRenderWnd, &rS);

LogAlw("Splash Window Size = [%u, %u]", rS.right - rS.left, rS.bottom - rS.top);
LogAlw("Splash Window LeftTop = [%d, %d]", rS.left, rS.top);

and this is the output:

(76: 1.1s 02.01ms)(0x1E24) Splash Window Size = [1920, 1080]
(77: 1.1s 00.01ms)(0x1E24) Splash Window LeftTop = [0, 0]

So, everything is as expected but the actual window is about 5x5 pixel square in a top-left corner.

I have other things in my schedule so I'll be out of contact the next few days.

EDIT: Using GetWindowRect() gives the same results.