# New ReleaseD3D9Client Development

#### kuddel

##### Donator
Donator
Have you been able to fix the texturing issues?
When can we have a release of d3d9 beta with this feature?

This "texturing issue" is fixed already (rev.1196 @ trunk) . A new release will have it fixed.
A GO/NO-GO on a new BETA release-version would be: GO!
For when jarmonik will build and publish a new release, I cannot predict any date.
Quite a number of changes/fixes since "R28.11" (rev.1173), so it's time for a new release

As X-mas came early this year (with AMSO for Orbiter-2016), maybe a new build will come up soon.

#### jarmonik

Beta Tester
New Build

There are new builds 4.0 and 29.0 published for Orbiter 2016 and Orbiter Beta, currently carying "Beta" status.

- There is a new gcCore interface to access gcAPI functions. Since, the interface is growing larger and the old method is slightly problematic and time taking to maintain the gcCore could be a solution to that. The old gcAPI is going to remain and work as it is however new functions will be available only through gcCore interface, currently declared in gcConst.h

- There is a new custom swapchain interface added. This means that users can create a double buffered DirectX rendering context in a custom window or control. Which can be written in by SketchPad or oapiBlt().

- New version of DX9ExtMFD is made available which is using the swapchain interface. Unzip it in "/Modules/Plugin/" folder.

- Screen space GDI access is restored. And can be enabled from the D3D9Clontrol dialog from the launchpad. However, I haven't been able to test it. Most addons known to use it are crashing even with the DX7.

- The accurate terrain interpolation is no longer an experimental feature and the checkbox is removed.

- There is also an experimental gcGUI interface that should put through some testing and if it passes then a new development tools will be hopefully made by using it. I have a surface base/terrain editing tool and vessel visual editor in the plans. The gcGUI can be enabled form D3D9Controls from the launchpad and there are two modes "Default" and "Windowed". Testing is required at 4k resolution and multi-monitor configurations. Note: that the controls in the dialogs are not yet operational. The old D3D9Debug control dialog is still fully operational.

The "Default" mode has two dockbars in left/right edge of the screen and the controls can be freely moved around the screen. The dock bars can be currently locked in current open/closed position by holding down [LShift + LCtrl] and pressing [LeftArrow] or [RightArrow].

The "Windowed" doesn't have dockbars and the sub-dialogs can't be detached from the main section.

#### Attachments

• DX9ExtMFD.zip
131.6 KB · Views: 15
• gcGUI.jpg
345.6 KB · Views: 94
Last edited:

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Major bug to report: I can't use the MFD target selection menus in D3D9Client. They come up but the arrow keys does nothing, I can't move between the different menu items. Only way to make it go away is by left-clicking.

#### jarmonik

Beta Tester
Major bug to report: I can't use the MFD target selection menus in D3D9Client. They come up but the arrow keys does nothing, I can't move between the different menu items. Only way to make it go away is by left-clicking.

Oh no. How did this happen :facepalm: You need to roll back to 3.13 until I can make a new build. Sorry about this. EDIT: Also, disabling gcGUI should solve the problem.

BTW, have you tried the new gcGUI dialogs in 4k resolution ? Are they working/scaling properly ?

Last edited:

#### Ripley

##### Tutorial translator
Donator
Oh no. How did this happen...You need to roll back to 3.13 until I can make a new build...
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.
Pressing SEL cycles through my installed MFDs (I can see the side selection buttons with the ">" and "<" arrows changing accordingly), but the MFD itself remains blank.

#### jarmonik

Beta Tester
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

##### Tutorial translator
Donator
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.
External MFDs are still blank with latest DX9ExtMFD, latest client R4.0 and gcGUI disabled.

#### jarmonik

Beta Tester
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

##### Tutorial translator
Donator
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

Last edited:

#### 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:
Code:
[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

Donator
Beta Tester
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

Beta Tester
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:
Code:
[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:
Code:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'

#### kuddel

##### Donator
Donator
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:
Code:
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

##### Donator
Donator
[...]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:
...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:
...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

Beta Tester
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.

PHP:
typedef gcCore * (__cdecl *__gcGetCoreAPI)();

gcCore * gcGetCoreAPI()
{
HMODULE hModule = GetModuleHandle("D3D9Client.dll");
if (hModule)  {
}