New Release D3D9Client Development

[jarmonik]

I have to add that reverting back to 3.13, then to 3.12 didn't fix my MFD issue.
D3D9's ExtMFDs show up completely empty.

The latest build of the DX9ExtMFD only works with D3D9Client versions 4.0+

There is a bug that causes a keyboard issues if the gcGUI is enabled in "Default" of "Windowed" mode. Version 4.0 should work fine as long as the experimental gcGUI is "Disabled" from client configuration dialog.

 

[Ripley]

The latest build of the DX9ExtMFD only works with D3D9Client versions 4.0+

My bad! Of course!

There is a bug that causes a keyboard issues if the gcGUI is enabled in "Default" of "Windowed" mode. Version 4.0 should work fine as long as the experimental gcGUI is "Disabled" from client configuration dialog.

External MFDs are still blank with latest DX9ExtMFD, latest client R4.0 and gcGUI disabled.

 

[jarmonik]

External MFDs are still blank with latest DX9ExtMFD, latest client R4.0 and gcGUI disabled.

I just remembered that it wont work in a true-fullscreen mode. In which case error: "Failed to create a swapchain. (Feature not supported in true-fullscreen mode)" should be printed in Orbiter.log.

Could you chack that if the true-fullscreed is the case here or is there something else wrong ?

The new DX9ExtMFD will create it's own front and backbuffer for MFD drawing, I don't know if there are any other limitations to the availability of that feature. You were using Windows XP, right ?

 

[Ripley]

You were using Windows XP, right ?

Ehehehh, those days are long gone, I'm on Win10 now.

I just remembered that it wont work in a true-fullscreen mode.
...
Could you chack that if the true-fullscreed is the case here or is there something else wrong ?
...

Yes, that was the case :thumbup:
In full screen, opening an D3D9extMFD resulted in an empty MFD (as you know), but it was also impossible to close it.
Double clicking on the (invisible) "x" at the righmost of the MFD's titlebar, the MFD "minimized" but the titlebar was still visible.

In Video -> Window mode, D3D9extMFD finally worked as expected, BUT:

I tried with all 3 gcGUI modes, and while going in and out of Orbiter, I noticed that the "DX9 External MFD" option in CTRL+F4 menu had disappeared...mostly when switching from "windowed" to "default" gcGUI mode.

Completely exiting and relaunching Orbiter fixed the issue.

I also saw a "gcGUI test" option in the CTRL+F4 menu, but only in gcGUI "windowed" mode.
Moving that window (D3D9 Controls) around with the mouse was a bit erratic: with a first click on the titlebar, it jumped and sticked to the left of my monitor, ouside of Orbiter window.
It is as if there is an offset position between the mouse pointer and the window coordinates, drawing the window at the left of the mouse.

In gcGUI "default" mode, the same window (D3D9 Controls) appears automatically whenever my mouse touches the left Orbiter window border.



By the way, the other "normal" options I have in CTRL+F4 menu are:
DX9 External MFD
Scenario Editor
D3D9 Debug Controls
D3D9 Atmospheric Controls

 

[GLS]

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?

 

[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.