New Release D3D9Client Development

[Donamy]

Are you trying to start with a .dll not recompiled for 2016 ?

 

[GLS]

Are you trying to start with a .dll not recompiled for 2016 ?

No... :shrug:

 

[jarmonik]

Running Orbiter 2016 with D3D9 R3.12, R3.13 or R4.0 and loading a mesh with a group containing FLAG 8 produces a CTD +/- when the sim should start. Both logs show the message:

[ERROR] MeshGroupFlag 0x8 in use (OPERATION NOT IMPLEMENTED)

I'm sure this worked without the CTDs in Orbiter Beta... not sure if the log message was present...
So is this something not available just for Orbiter 2016, or it's not available at all and the CTD is (maybe) something else?

We have had never support for Flag 0x8, this is the first time I know that someone have tried to use it. Of course, if the "additive with background" feature is really required then of course we can add a support for it. The reason for not having a support is simply that if no-one uses it, there's been no adaquate way to test it. I don't know about the CTD, it's possible that assert() is use to trigger it. What are you trying to do with flag 0x8 ?

 

[GLS]

We have had never support for Flag 0x8, this is the first time I know that someone have tried to use it. Of course, if the "additive with background" feature is really required then of course we can add a support for it. The reason for not having a support is simply that if no-one uses it, there's been no adaquate way to test it. I don't know about the CTD, it's possible that assert() is use to trigger it. What are you trying to do with flag 0x8 ?

I'm just playing with things, figuring out what "tools are in the toolbox"... :lol: It's fine if you don't support it (if I really need it, for sure I'll ask for it), but I don't think it should go CTD... :shrug:

It doesn't seem to be an assert, as it shows the "orbiter.exe. has stopped working" window, and not the "assertion failed" window. Debugging gives: "Unhandled exception at 0x5DC64DAD (igdumdim32.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000030."
Just looked up that dll and it's used by the Intel GPU, so tried running in the NVIDIA GPU and it works. It might something uninitialized, that the NVIDIA GPU doesn't care about, but makes the Intel GPU go nuts. :shrug:
Anyway, when I was running Orbiter Beta there was no CTD.

 

[GLS]

New build 3.13 of the client is out for Orbiter 2016. There are a lot of changes but, the most important ones are related to shadows and terrain.

- Stencil shadows are now better aligned with a terrain and should appear in the right place for vessels and base object meshes.

- Underground meshes are nolonger creating a "false" shadows.

- When "linear interpolation" and "Experimental lunar terrain interpolation" are selected the resulting visual terrain should match the surface used by physics with an accuracy of 2cm. Otherwise, the deviation can be a few meters.

One thing that also changed with r3.13 (and also r4.0) is that we now have that infamous "collision" between debug/release, static/dynamic CRT libraries:

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'

 

[kuddel]

One thing that also changed with r3.13 (and also r4.0) is that we now have that infamous "collision" between debug/release, static/dynamic CRT libraries:

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'

So, only the initial version (rev.1229) works for you?

Changes to gcAPI.lib[1] were only at rev.1239 and rev.1243;
and version 3.13 was rev.1230 and version 4.0 was rev.1248.

Building a Module (DLL) as debug however might almost *never* work with the provided library. You might have to re-build a debug library of gcAPI (gcAPI_dbg.dll) yourself from the sources...
See current 'trunk'-changes[2] for how you might be able to do this.

As these debug-build capability is still work in progress here, your mileage might vary



[1] ...on the '2016' branch. 'trunk' revisions might be another story.
[2] For example: trunk\Orbitersdk\samples\GenericCamera\GenericCamera.sln
Here gcAPI is *not* (re-)build for release builds,
but for debug-builds gcAPI is build as 'gcAPI_dbg.lib' with different runtimes.

 

[GLS]

So, only the initial version (rev.1229) works for you?

Changes to gcAPI.lib[1] were only at rev.1239 and rev.1243;
and version 3.13 was rev.1230 and version 4.0 was rev.1248.

Building a Module (DLL) as debug however might almost *never* work with the provided library. You might have to re-build a debug library of gcAPI (gcAPI_dbg.dll) yourself from the sources...
See current 'trunk'-changes[2] for how you might be able to do this.

As these debug-build capability is still work in progress here, your mileage might vary



[1] ...on the '2016' branch. 'trunk' revisions might be another story.
[2] For example: trunk\Orbitersdk\samples\GenericCamera\GenericCamera.sln
Here gcAPI is *not* (re-)build for release builds,
but for debug-builds gcAPI is build as 'gcAPI_dbg.lib' with different runtimes.

The change was probably not in the code, but in the build process: 3.12 was probably built with an older VS that didn't enforce the CRT library type like the more recent versions do.
Anyway, I'm setting things up to build "my own" version of the library. I'll probably create a second debug config in SSU to target the "_dbg" flavor of the library. It also solves the "static vs dynamic" issue, unless you don't want your library included when compiled with static?

---------- Post added at 06:46 PM ---------- Previous post was at 05:14 PM ----------

Built a static debug version and it works!

 

[kuddel]

[...]It also solves the "static vs dynamic" issue, unless you don't want your library included when compiled with static?[...]

The lib itself is Jarmonik's brainchild and as far as I know he deliberately build it with Visual Studio 2008...(please correct me if I'm wrong here :thumbup

I am currently trying out several options on how to build all the stuff and the gcAPI.lib thing is one of the issues these endeavors should explore

I will also probably try a completely different runtime setup for all of the D3D9Client related builds, as I noticed that the "recommended" setup by the Orbiter-BETA provided prop-sheets use MultiThreadedDLL for release builds and MultiThreadedDebugDLL for debug builds[1].

As far as I know, for a complete coverage we would need to provide a lib for all possible combinations:
Release/Debug <=> Multithreaded/Singethreaded <=> Statis/Dymanic
...and possibly some more I've missed.
The general goal however is: Provide one library for all release module DLLs that need gcAPI support, while during development the Modue-developer still can do so by getting the source-code.

Complicating the tasks is that I like to keep the ability to build D3D9Client with several versions of Visual Studio (2008, 2015, 2017, 2019), all preferably as debug and release builds.
Adding the two main branches (trunk for BETA, 2016 for Orbiter-2016) sometimes makes this more complicated then it looks :lol:

Nevertheless, I'm glad that you could make a debug-build for your purpose.


[1] See Orbitersdk\VS2015\PropertyPages\orbiter.props & Orbitersdk\VS2015\PropertyPages\orbiter_debug.props

 

[GLS]

The lib itself is Jarmonik's brainchild and as far as I know he deliberately build it with Visual Studio 2008...(please correct me if I'm wrong here :thumbup

3.12 maybe, but the last 2 versions where probably built with a more recent VS. I used the 201x solution, and only changed the CRT libs from static to dynamic, compile, copy to the SSU folders, compile and it all works.

I am currently trying out several options on how to build all the stuff and the gcAPI.lib thing is one of the issues these endeavors should explore

I will also probably try a completely different runtime setup for all of the D3D9Client related builds, as I noticed that the "recommended" setup by the Orbiter-BETA provided prop-sheets use MultiThreadedDLL for release builds and MultiThreadedDebugDLL for debug builds[1].

As far as I know, for a complete coverage we would need to provide a lib for all possible combinations:
Release/Debug <=> Multithreaded/Singethreaded <=> Statis/Dymanic
...and possibly some more I've missed.
The general goal however is: Provide one library for all release module DLLs that need gcAPI support, while during development the Modue-developer still can do so by getting the source-code.

Complicating the tasks is that I like to keep the ability to build D3D9Client with several versions of Visual Studio (2008, 2015, 2017, 2019), all preferably as debug and release builds.
Adding the two main branches (trunk for BETA, 2016 for Orbiter-2016) sometimes makes this more complicated then it looks :lol:

Nevertheless, I'm glad that you could make a debug-build for your purpose.


[1] See Orbitersdk\VS2015\PropertyPages\orbiter.props & Orbitersdk\VS2015\PropertyPages\orbiter_debug.props

AFAIK, there are (only) 4 possible configurations: static debug, static release, dynamic debug, dynamic release.
BTW: if you are doing re-organization work, you could put the dll and library under the same solution. :shrug:

For now it all works.... until M$FT changes the rules again.... :shifty::facepalm:

 

[jarmonik]

I can confirm that the gcAPI.lib has been previously build with VS2008 and the latest was build with VS2015 under an impression that it's working. So, I can make one last rebuild of it using VS2008 and after that the gcAPI.lib is becoming obsollete since the functionality will be provided via virtual gcCore interface which is more developper friendly. And no more modification or features are added to gcAPI.lib

The gcCore interface will be officially published when it's ready enough and no more compatibility breaking modifications are made to it. Right now any application using it will need to be recompiled after every change made to the interface.

Connection to gcCore Interface can be easily acquired by including the following code into a user application. This does NOT require to link the gcAPI.lib into a work.

typedef gcCore * (__cdecl *__gcGetCoreAPI)();

gcCore * gcGetCoreAPI()
{    
    HMODULE hModule = GetModuleHandle("D3D9Client.dll");    
    if (hModule)  {
         __gcGetCoreAPI pGetCoreAPI = (__gcGetCoreAPI)GetProcAddress(hModule, "gcGetCoreAPI"); 
         if (pGetCoreAPI) return pGetCoreAPI();
    }       
    return NULL;
}

EDIT: I am working on a Terrain ToolKit right now to import/export terrain information to Orbiter and There is plenty of development going on with the gcCore Interface. After the toolkit is out the gcCore sould be stable enough to publish it. The work is about 75% completed. Lot of progress is made but the workload was 10 times bigger than initially estimated.

 

[GLS]

Right now any application using it will need to be recompiled after every change made to the interface.

You mean for current library version, right? With that new interface, unless the signature of the functions gets changed, a new version will be transparent to the code of the client. It will be like a dll. :thumbup:

 

[jarmonik]

You mean for current library version, right?

I am not exactly sure what you mean but you can get a pointer to gcCore interface in the latest 4.1 build. I am unsure but most of the standard features should be on-line via gcCore in 4.0 too.

---------- Post added at 13:57 ---------- Previous post was at 13:50 ----------

I was just about to publish my latest work with the TerrainToolKit but when I tried a release build I noticed a tons of problems...

From switch one is this:

If I have an interface compiled as a Debug build

class MyInt
{
virtual void MyFunc(std::string &lbl);
}

And I call the function from a module compiled as release:
...
pInterface->MyFunc(string("Hello World"));
...

I get a debug assertion in std::string :facepalm:
If the modules are both debug or release builds it works.

 

[GLS]

I am not exactly sure what you mean but you can get a pointer to gcCore interface in the latest 4.1 build. I am unsure but most of the standard features should be on-line via gcCore in 4.0 too.

---------- Post added at 13:57 ---------- Previous post was at 13:50 ----------

I was just about to publish my latest work with the TerrainToolKit but when I tried a release build I noticed a tons of problems...

From switch one is this:

If I have an interface compiled as a Debug build

class MyInt
{
virtual void MyFunc(std::string &lbl);
}

And I call the function from a module compiled as release:
...
pInterface->MyFunc(string("Hello World"));
...

I get a debug assertion in std::string :facepalm:
If the modules are both debug or release builds it works.

That's probably due to memory being allocated on one side, and then accessed on the other, and each side is using a different CRT library (debug vs release). The solution would be to have a debug dll and release dll.... not sure what issues that would cause in Orbiter if both dlls are installed.
Thank you micro$oft... :compbash:

 

[jarmonik]

Luckily there is a simple fix to replace the std::string with "const char *". Sometimes the old way is better then a can of new ones it appears :lol:.

 

[GLS]

Issue with lights: it looks like the range parameter in AddPointLight() is not being respected. The function description isn't 100% clear, but my understanding of it (and what MOGE apparently does) is create an distance/intensity curve from the att_x parameters, and then cut that curve at the distance specified by the range parameter, so the entire universe isn't lit up (the formula never goes to 0).
Using R4.0 for Orbiter 2016.

 

[kuddel]

As far as I know one should not pass objects around DLL boundaries.
Most libraries offer their API in extern "C" to avoid problems.
Like:

extern "C" {
   void foo();
   // ...
}

Arguments are passed either as plain old data-types (char *) or must be acquired and released by the API itself (IIRC).

 

[jarmonik]

Issue with lights: it looks like the range parameter in AddPointLight() is not being respected. The function description isn't 100% clear, but my understanding of it (and what MOGE apparently does) is create an distance/intensity curve from the att_x parameters, and then cut that curve at the distance specified by the range parameter, so the entire universe isn't lit up (the formula never goes to 0).
Using R4.0 for Orbiter 2016.

As I remember the range is not being used in D3D9. We compute the range from the att_x parameters. So, the range is automatically set to 2% illumination or something like that. For a mesh outside of that range the light source is off-line. Is there a problem ?

 

[GLS]

As I remember the range is not being used in D3D9. We compute the range from the att_x parameters. So, the range is automatically set to 2% illumination or something like that. For a mesh outside of that range the light source is off-line. Is there a problem ?

It shouldn't be a problem, just something I noticed when I had a very small range, and it was doing what I expected in MOGE, but in D3D9 the whole mesh was lit.
My "concern" was more in the performance side of things: if the intensity wasn't being limited, then all meshes would be lit (even if a tiny amount), which would eat a bit of fps. But if there is a cutoff, then it shoudn't be a problem. :shrug:

 

[JMW]

Hi Guys.

Big problem for me.
Is fine normally, but now illuminating everything (360 deg) in D3D9Client.

000219.985: 
000219.985: **** Creating simulation session
000219.985: D3D9: [DirectX 9 Initialized]
000219.985: D3D9: 3D-Adapter = Intel(R) HD Graphics 4000
000219.985: D3D9: MaxTextureWidth........: 8192
000219.985: D3D9: MaxTextureHeight.......: 8192
000219.985: D3D9: MaxTextureRepeat.......: 8192
000219.985: D3D9: VolTexAddressCaps......: 0x3F
000219.985: D3D9: NumSimultaneousRTs.....: 4
000219.985: D3D9: VertexDeclCaps.........: 0x37F
000219.985: D3D9: XNA Math Support.......: Yes
000219.985: D3D9: Vertex Texture.........: Yes
000219.985: D3D9: Shadow Mapping.........: Yes
000219.985: D3D9: D3DFMT_A16B16G16R16F...: Yes
000219.985: D3D9: D3DFMT_A32B32G32R32F...: Yes
000219.985: D3D9: D3DFMT_D32F_LOCKABLE...: No
000219.985: D3D9: D3DFMT_A2R10G10B10.....: Yes
000219.985: D3D9: D3DDTCAPS_DEC3N........: No
000219.985: D3D9: D3DDTCAPS_FLOAT16_2....: Yes
000219.985: D3D9: D3DDTCAPS_FLOAT16_4....: Yes
000219.985: D3D9: Available Texture Memory = 1781 MB
000219.985: D3D9: [3DDevice Initialized]
000219.985: D3D9: [Loading Constellations]
000219.985: D3D9: [D3D9Client Initialized]
000000.000: Module Sun.dll ............... [Build 160828, API 160828]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 160828, API 160828]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 160828, API 160828]
000000.000: Module VenusAtm2006.dll ...... [Build 160828, API 160828]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 160828, API 160828]
000000.000: Module EarthAtmJ71G.dll ...... [Build 160828, API 160828]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 160828, API 160828]
ELP82: Precision 1e-005, Terms 116/829
000000.000: Module Mars.dll .............. [Build 160828, API 160828]
000000.000: Module MarsAtm2006.dll ....... [Build 160828, API 160828]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 160828, API 160828]
000000.000: Module Jupiter.dll ........... [Build 160828, API 160828]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 160828, API 160828]
000000.000: Module Europa.dll ............ [Build 160828, API 160828]
000000.000: Module Ganymede.dll .......... [Build 160828, API 160828]
000000.000: Module Callisto.dll .......... [Build 160828, API 160828]
000000.000: Module Satsat.dll ............ [Build 160828, API 160828]
000000.000: Module Saturn.dll ............ [Build 160828, API 160828]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 160828, API 160828]
SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 160828, API 160828]
SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 160828, API 160828]
SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 160828, API 160828]
SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 160828, API 160828]
SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 160828, API 160828]
SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 160828, API 160828]
SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 160828, API 160828]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 160828, API 160828]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module J-F-35B.dll ........... [Build 200127, API 161124]
000000.000: Module ShuttleA.dll .......... [Build 160828, API 160828]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: D3D9: [Scene Initialized]
000000.000: Finished initialising panels
000019.022: D3D9: [Session Closed. Scene deleted.]
000019.022: D3D9: [Destroy Render Window Called]
000019.022: **** Closing simulation session
D3D9: ERROR: Invalid Window !! RenderWndProc() called after calling clbkDestroyRenderWindow() uMsg=0x82

 

[JMW]

Edit: Uploaded "Before" image