New Release D3D9Client Development

[fort]

Hi Fort et al,

..."...et al "



I think that i'm actually the last one or one of two to use XP with Orbiter on this forum.

here's a build for Orbiter 2016 (...that should be "XP-ready"(TM) )
This is a D3D9Client build that is NOT the most recent version!
It is a build from the 2016 branch of D3D9Client and only includes bug-fixes (no new features).

I'll install someday Seven to test the most recent version ( and try to understand all the numbers 821 822 826...). But actually, i think that i don't need more than that for my limited test.

good day kuddel.

:tiphat:

 

[jedidia]

Color-keys are working in _ng but not with stretching.

Oh, then something's changed in the last 3 years or so without me noticing (shocking , right? :lol

We have already an alpha-blend support in D3D9 via SketchPad2 interface but it's not compatible with the inline engine.

About that sketchpad2, is there documentation for that somewhere? I have a feeling it might come in handy soon.

 

[jarmonik]

About that sketchpad2, is there documentation for that somewhere? I have a feeling it might come in handy soon.

The documentation is in /Orbitersdk/doc/gcAPI.chm
Also some source code examples are in here: http://www.orbiter-forum.com/showthread.php?t=37171

 

[kuddel]

Hey fellow developers and helpers!
I've tried some things, so I invite you to join my >>> poll <<< so I can get some "in the field" results.

Thanks in advance,
Kuddel

 

[GLS]

I've found this assert CTD on loading a few times: D3D9Pad2.cpp:540.
It seems to only show up when loading a scenario, after having run another.

 

[jarmonik]

I've found this assert CTD on loading a few times: D3D9Pad2.cpp:540.
It seems to only show up when loading a scenario, after having run another.

Ok, Thanks. I'll look into it. The sketchpad code needs some cleaning up and additional runtime checks to make sure everything is running smooth.

 

[Ripley]

Sure you are trying this build with Orbiter beta r65? It's not for orbiter 2016 release

Sorry for the late reply, but you're right.
It was my fault. :tiphat:

---------- Post added 18-02-17 at 00:18 ---------- Previous post was 17-02-17 at 11:28 ----------

I'm running Win10 + Orbiter 2016 [160828] and I've just (re)downloaded the file named "D3D9ClientBeta25.2-for2016(r821).zip", from kuddel's post, but during the splash screen it still gives me the error "Orbiter has stopped working".

I reverted back to the official Codeplex "D3D9Client 2016 Edition R1" release, and everything's fine again.

Since kuddel wrote this, I thought it should work:

...I think you should use D3D9ClientBeta25.2-for2016(r821).zip (linked against Orbiter 2016 [160828], build with Visual Studio 2012)

:tiphat:

 

[Marg]

Hi Fort et al,

here's a build for Orbiter 2016 (...that should be "XP-ready"(TM) )
This is a D3D9Client build that is NOT the most recent version!
It is a build from the 2016 branch of D3D9Client and only includes bug-fixes (no new features).

Changes (compared to the "codeplex" 2016-R1 version):

• Mars horizon flicker bug fixed
• Particle effect position bug fixed.
• Reverted particle lighting to defaults. In a hope to address reported "dark" particles issue.
• Particle streams: gravitational acceleration reduced as a function of atmospheric density (see http://www.orbiter-forum.com/project.php?issueid=1214)
• Fixing Texture-path issues...
• adjusted build_release.bat & get_orbiter_libs.bat to fit Orbiter 2016 release.
• Minor bug fixes.

Those changes have already found their way into the 2016 branch and I don't think they should be left out!

/Kuddel

This one works very OK on my Win7 PC... I still have "28082016" orbiter.
And it corrected huge thing - deflection smokes are hanging in the air much longer than before (I've read some discussions about this in another thread),
earlier they were really going down too fast (too much affected by gravity).

 

[Blake]

Hello.

I'm getting my SR71R release for Orbiter 2016 ready and I'm running into an issue with the D3D9 client. While loading it appears to get into a loop and hangs. The relevant lines from the D3D9 log are these:

...
(581: 67.5s 03.28ms)(0x3BE4)[ERROR] D3D9ClientSurface::BindGPU() Failed
(582: 67.5s 03.01ms)(0x3BE4)[ERROR] D3D9ClientSurface::BindGPU() Failed
(583: 67.5s 32.50ms)(0x3BE4) New Base Visual(0x75B2C50) Cape Canaveral hBase=0x3098718, nsbs=3, nsas=4
(584: 67.5s 00.11ms)(0x3BE4) Creating Runway Lights from .\Config\Earth\Base\Canaveral.cfg
(585: 67.6s 16.45ms)(0x3BE4) Texture 0x7D5EE68 (Taxiway1.dds) added in repository
(586: 67.6s 04.98ms)(0x3BE4) Texture 0x7D5D398 (Concrete.dds) added in repository
(587: 67.6s 03.26ms)(0x3BE4) New Base Visual(0x147F0E90) Habana hBase=0x30AE600, nsbs=2, nsas=1
(588: 67.6s 00.08ms)(0x3BE4) Creating Runway Lights from .\Config\Earth\Base\Habana.cfg
(589: 67.6s 09.57ms)(0x3BE4) New Base Visual(0x14789298) Matagorda hBase=0x3105208, nsbs=1, nsas=0
(590: 67.6s 00.08ms)(0x3BE4) Creating Runway Lights from .\Config\Earth\Base\Matagorda.cfg
(591: 67.6s 00.82ms)(0x3BE4) New Base Visual(0x1478A5F8) Wallops Island hBase=0x3108030, nsbs=1, nsas=0
(592: 67.6s 00.06ms)(0x3BE4) Creating Runway Lights from .\Config\Earth\Base\Wallops_Island.cfg
(593: 67.6s 00.12ms)(0x3BE4)[ERROR] Scene.cpp Line:871 Error:-2005530516 pDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER|D3DCLEAR_STENCIL, 0, 1.0f, 0L)
(594: 67.6s 03.75ms)(0x3BE4)[ERROR] Scene.cpp Line:871 Error:-2005530516 pDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER|D3DCLEAR_STENCIL, 0, 1.0f, 0L)
...

The D3D9ClientSurface::BindGPU() Failed line appears through out the log up to this point, but the final line above repeats until I kill the session (closing the window).

- Orbiter Vers. v160828.
- The inline client works.
- The GDI Compatibility mode does not appear to make any difference.
- Window or full screen does not appear to make any difference.
- D3D9 client works with the stock Delta Glider scenarios I have tried.
- I've reviewed the correct usage of GetDevMesh as per the notes on the initial post of this thread.

Running under the debugger is not telling me anything useful.



I've tried searching for those error messages and have not found anything useful. Any insight would be appreciated.

Thanks.

 

[jarmonik]

A failure to call oapiReleaseSketchpad() could cause the following issue. So, I guess that's the first thing to check. If that doesn't help then could you provide a download link so that I can run the add-on on my computer.

 

[Blake]

The only interaction the code has with the sketchpad is inside clbkDrawHud, and my understanding is you would not call release on that instance. I double-checked the code anyway.

Attached is the add-on. Just unzip in the Orbiter folder. I have been testing with the 0-Cold Start scenario, but all scenarios show the same issue. Of course anyone else who wants to pull it down and play with it is welcome to. I'll put up an official release when this issue is sorted out.

View attachment SR71R-0.8.0.zip

Interestingly, the start up screen shows 'loading' but if you click on the top of the screen in the right places you can bring up the dialogs from the top button bar. I assume the 'server' is running but the client is not, but I really don't know how the visualization works.

Thanks for the input. I would like for this to work with the D3D9 client.

 

[jarmonik]

Alright, here are some new builds. I have copied the recent changes from beta branch to 2016 branch, which includes bug fixes, the lens-flare code and cleaned up PBR rendering pipeline. Note that some errors may exists in the rendering code in PBR section.

The issue reported above should be fixed. One ReleaseGPU() call was bypassed by an early return from a subroutine.

I have tried to write some documentation for the client but I haven't got very far yet.

R2-Beta1 is for the official Orbiter 2016 build.
25_3 is for latest Orbiter beta r.65

I had to zip the PDF documentation due to 1MB upload limit for PDF(s).

 

[Blake]

Thanks!

Its working now. I have some cleanup, but it looks good.

 

[turtle91]

I don't know if his might be a system-specific issue on my system, but since upgraded to latest release (D3D9Client2016-R2-Beta1.zip ), I have some texture-issues at hires Antilope Valley. I tried various settings, including GDI-compat-mode, but got allways this strange texture-popup issues during flight.
I have also disabled all post-processing options, but still "texture-switching".
All other areas are fine (I am running a default setup, no other additional hires-text-packs installed, except Edwards).

The previous build was fine for me.
However, I am still using my notebook, with a shared AMD GPU/CPU.
So..again...could be a system-issue on my side.

Screenshot is attached.
And..btw...the D3D9-Guide is very interesting and informative. :thumbup:

 

[jarmonik]

I don't know if his might be a system-specific issue on my system, but since upgraded to latest release (D3D9Client2016-R2-Beta1.zip ), I have some texture-issues at hires Antilope Valley.

Does this fix the problem. It's for official Orbiter 2016 release.

 

[turtle91]

Huh...this was fast.

Yes, the newer build fixed the problem.
I even tried to switch between different vessels on different planets/locations, to force a texture-reload.
But whatever I have tried to force the problem, the issue seems to be resolved.
No more texture-issues.

...And...btw... the new lens-flare is much faster compard to the previous one. :thumbup:

Many thanks for the quick help and your outstanding work in general.

 

[Marg]

Some observations - "lens flare" is faster because it is not obscured by vessels, and meshes... I think.
I noticed that my space shuttle on the pad is lit by local lights (at night) brighter than before, surface details cannot be seen on the wings (they have _norm.dds files and there was some "relief"). Of course, distinguishing marks (NASA, Atlantis...) can be seen.

 

[jarmonik]

Some observations - "lens flare" is faster because it is not obscured by vessels, and meshes... I think.
I noticed that my space shuttle on the pad is lit by local lights (at night) brighter than before, surface details cannot be seen on the wings (they have _norm.dds files and there was some "relief"). Of course, distinguishing marks (NASA, Atlantis...) can be seen.

Could you confirm that if enabling these two lines (558-559) from D3D9Client.fx fixes the problem.

//diff = 1.5 - exp2(-diffuse.rgb)*1.5;
//spec = 1.5 - exp2(-specular.rgb)*1.5;

 

[Marg]

Could you confirm that if enabling these two lines (558-559) from D3D9Client.fx fixes the problem.

//diff = 1.5 - exp2(-diffuse.rgb)*1.5;
//spec = 1.5 - exp2(-specular.rgb)*1.5;

I enabled but nothing changed. But I noticed also, that if shuttle is at night, when there is a total darkness around, orbiter almost is not "overexposured".
but overexposure happens in the morning when sun is rising. As if the daylight is "summarized" with launch pad lights. But - if I turn the lights off, shuttle (and pad + surroundings) look way too dark.

 

[turtle91]

Some more observations:

-The lensflare-effect makes the Sun invisible if about 7.5 -8 AU away from Sun.
I discovered this, while coming back from a "short" Saturn-trip.
-No Sun-Star there, at about 7.8 AU the Sun's halo started to increase, but still no visible Sun-dot/star.
However, not a big deal, if going out far, I disable lens-flare and all is fine

-local-lights are a bit to bright, i.e. when used the front-light of the XR2 or the stock DG, it nearly illuminates the entire vessel very bright (nearly white).

-all XR2 skins don't have any reflections anymore...means...XR2 looks like made out of plastic (only the windows doing a nice reflection).