D3D9Client (semi-native) + Orbiter test build

[jarmonik]

I have a new build of D3D9Client and the Orbiter prepared for testing. This is a 32-bit build with a reworked semi-native surface interface with a DX7 fallback for add-ons those depend on it. It's much more simpler and more reliable than the old one. MFDs created for the Orbiter 2016 should be compatible with this build (Inline and D3D9). Although, any addon using Sketchpad2 interface would need to be recompiled, since, Sketchpad2 is now integrated to default DrawAPI and Sketchpad2.h no longer exists.

XR2Ravenstar, Dan's DGIV, NASSP work fine but depends on DX7 fallback. SSU will start but no HUD or MFDs are visible and the Orbiter.log shows plenty of HDC errors. Likely due to use of Sketchpad::GetDC() which is not supported.

-Stock vessel are translated to use Sketchpad instead of GDI.
-MFD mipmaps are enabled for virtual cockpit.
-Overlapping enum types oapi::Font::Style and oapi::FontStyle has been fixed.
-Terrain collision should now work properly also with cubic interpolation.
- I have also written some 2D API documentation and it's located in /Orbitersdk/doc/Orbiter2DGraphics.pdf

This package can be extracted on a top of existing Orbiter Beta r.90 installation:
users.kymp.net/p501474a/TestPackage.zip

The implementation should be tested if it works well enough to be merged to Orbiter main branch.

New OAPI functions:

OAPIFUNC oapi::Font* oapiCreateFontEx(int height, char* face, int width = 0, int weight = 400, FontStyle style = FontStyle::FONT_NORMAL, float spacing = 0.0f);
OAPIFUNC int oapiMeshMaterialEx(DEVMESHHANDLE hMesh, DWORD idx, MatProp prp, oapi::FVECTOR4* out);
OAPIFUNC int oapiSetMaterialEx(DEVMESHHANDLE hMesh, DWORD idx, MatProp prp, const oapi::FVECTOR4* in);
OAPIFUNC const char* oapiGetObjectFileName(OBJHANDLE hObj);
OAPIFUNC SURFHANDLE oapiLoadSurfaceEx(const char* fname, DWORD attrib);
OAPIFUNC bool oapiGetSurfaceSize(SURFHANDLE hSrf, int* width, int* height);

New types:

#define OAPISURFACE_ANTIALIAS    0x0800 ///< Create a surface with anti-aliasing the level will depend on launchpad settings.
#define OAPISURFACE_SHARED         0x1000 ///< Create a shared (global) resource

FONT_STRIKEOUT = 0x8,   
FONT_CRISP = 0x10,            ///< Override app-default, No Anti-aliasing
FONT_ANTIALIAS = 0x20        ///< Override app-default, Use Anti-aliasing

 

[jarmonik]

This build doesn't contain XRSound due to large size. We would need a base package containing sound files and a basic set of planetary textures those are not included in Orbiter Git repository.

 

[jarmonik]

I have also written some 2D API documentation and it's located in /Orbitersdk/doc/
Let me know if you have questions about the API or if something is not clear enough.

 

[JDat]

Great work! Thank you!

What features D3D9 still need to support for compatibility with old add-ons?
Maybe there is chance to update these old add-ons and remove old stuff from them?
Also this info can be useful for new add-on development to avoid use of obsolete API.
I saw some old add-on source code. They are still using GDI (hDC etc stuff). Is it OK, or better to avoid use it in new add-ons?
I like sketchpad approach when need to draw or write text in MFDs.

So, info about forced compatibility with old stuff and what you would like to remove.

 

[GLS]

Thanks!
So just to confirm, this is Orbiter with D3D9 and no MOGE, right?
Do I still use the "new" <forgot the name>.dll to interface with D3D9 or is that merged into the standard Orbiter libs?
Give me a couple of days to setup things and I'll post some feedback.

 

[jarmonik]

Thanks!
So just to confirm, this is Orbiter with D3D9 and no MOGE, right?
Do I still use the "new" <forgot the name>.dll to interface with D3D9 or is that merged into the standard Orbiter libs?

Martin's own graphics engine is still included. Based on my understanding he has an intention to release one more Orbiter with it before letting it go.
The gcAPI.lib is history and no longer supported but the newer version of the API (gcCore) still remains and there is no need to move those features to Orbiter side other than just some simple basic features. The gcCore API is accessible through gcGetCoreInterface() inline function declared in gcConst.h

gcCore *pCore = gcGetCoreInterface();
if (pCore) {
    // Runs with D3D9
} else {
    // Runs with DX7 / MOGE
}

 

[jarmonik]

What features D3D9 still need to support for compatibility with old add-ons?

Mainly everywhere GDI access. Which is problematic for a high level render-targets due to way the GPU and pipeline operates. But a Sketchpad can easily draw into them.

Maybe there is chance to update these old add-ons and remove old stuff from them?
Also this info can be useful for new add-on development to avoid use of obsolete API.

There's been plenty of information available and the trouble with the GDI been known to us over 10 years already. That's the reason why the Sketchpad interface was create 10 years ago. But as long as an old method works, why upgrade ?

So, info about forced compatibility with old stuff and what you would like to remove.

Not sure what you mean by 'forced compatibility'. We should support old addons and the way they use to work as long as it can be done without dirty hacks or a lose of system stability, which did happen with the old surface interface. Also if supporting an old thing prevents us from going forward then something is wrong.

 

[GLS]

Martin's own graphics engine is still included. Based on my understanding he has an intention to release one more Orbiter with it before letting it go.
The gcAPI.lib is history and no longer supported but the newer version of the API (gcCore) still remains and there is no need to move those features to Orbiter side other than just some simple basic features. The gcCore API is accessible through gcGetCoreInterface() inline function declared in gcConst.h

gcCore *pCore = gcGetCoreInterface();
if (pCore) {
    // Runs with D3D9
} else {
    // Runs with DX7 / MOGE
}

OK, then it should be easy to test, as that is my setup.

 

[n72.75]

NASSP work fine but depends on DX7 fallback

Do you know what part?

 

[jarmonik]

Do you know what part?

Lots of them. You can see them in Orbiter.log if you change "Debug Level" to "2". Also you should get "Debug Break" on them under a debugger if you also check the debug break checkbox.

 

[jarmonik]

If an application needs to use GDI in a Sketchpad callback then something like this could work (depending on case of course):

SIZE sz;
skp->GetRenderSurfaceSize(&sz);

// Create a durface for GDI and draw onto it
SURFHANDLE hGDI = oapiCreateSurfaceEx(sz.cx, sz.cy, OAPISURFACE_GDI | OAPISURFACE_TEXTURE);

HDC hDC = oapiGetDC(hGDI);
// Do GDI Stuff
oapiReleaseDC(hGDI, hDC);

// Copy the GDI surface to destination.
skp->CopyRect(hGDI, NULL, 0, 0);

 

[GLS]

Here is the Space Shuttle Vessel report:
After making the needed replacements I have a functional version, with the exception of the ADI mesh. That used the type SKETCHMESH, which is not longer used (but is still declared). Replaced it with a regular MESHHANDLE, and LoadSketchMesh() with oapiLoadMesh(), and also replaced DrawSketchMesh() with DrawMeshGroup(), and it seems something is being drawn (movement is visible in the edges), but it's all white.

On the D3D9 log (level 4) and the Orbiter log, the only thing wrong is at the end: "[ERROR] [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)".

Also ran attached to VS (even though I had to build in release for runtime compatibility) and no breaks occurred.

Not sure if relevant, but can't get the D3D7 client working in Orbiter_ng, it goes into command line window and crash during loading. Next attempt doesn't even open the Launchpad.

 

[WolfAngriff]

Let me know if you have questions about the API or if something is not clear enough.

Ah ah ! Nothing's clear to me ! But don't worry, i know i'm a noob. And i'm comfortable with that. But, as i try to report what"s happening using a human language to the french speaking community, i TRY to understand what's going on without bothering creators with too much basic questions. So, if i have understood something, here's what : this is an addon to use with Orbiter Beta r90. This is a 32 bit version. Some good old addons will work with it, even their MFDs. Older addons created with Sketchpad won't. The ground collision works (or should work). The ground collision is managed by D3D9. I don't understand the "fallback to DX7" thing, but do i need to understand this ? If, after testing, things work good, this addon will be brought to the Orbiter X64 main developpement branch. The original graphic engine is still in use with this addon, but does it mean it should be removed from the future version ?

So, if someone has a few seconds (or minutes ?) to tell me if i'm right or wrong, it could be very nice !

And, as always, a BIG thanx to all of you for your hard work and commitment.

 

[jarmonik]

Here is the Space Shuttle Vessel report:
After making the needed replacements I have a functional version, with the exception of the ADI mesh. That used the type SKETCHMESH, which is not longer used (but is still declared). Replaced it with a regular MESHHANDLE, and LoadSketchMesh() with oapiLoadMesh(), and also replaced DrawSketchMesh() with DrawMeshGroup(), and it seems something is being drawn (movement is visible in the edges), but it's all white.

On the D3D9 log (level 4) and the Orbiter log, the only thing wrong is at the end: "[ERROR] [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)".

Also ran attached to VS (even though I had to build in release for runtime compatibility) and no breaks occurred.

Not sure if relevant, but can't get the D3D7 client working in Orbiter_ng, it goes into command line window and crash during loading. Next attempt doesn't even open the Launchpad.

Thanks for the report. I did spot some problems with DrawMeshGroup() and I will get them sorted out. No worries. The error you mentioned doesn't really mean anything and we are probably going to remove it.

 

[DarkWanderer]

Do you plan to PR the new APIs into main Orbiter repo?

 

[jarmonik]

Do you plan to PR the new APIs into main Orbiter repo?

Yes, it's intended to be merged to the orbitersim/main but it's not really my call. It might be good idea to merge the modifications before the next Orbiter is released. Or release two versions of Orbiter. Add-on developpers would need a stable orbiter build with an API compatible forward into the future. I would like to leave D3D9Client for Orbiter 2016 behind.

 

[n72.75]

Running into a bit of an issue with the latest commit, and I'm fairly certain that it's my fault. This branch builds without issue for me, but when loading a scenario Orbiter reports that the dx9 runtime libraries cant be found. I know these are installed, and I'm a little lost on finding the source of the issue.

 

[Ajaja]

@n72.75
There should be something like this in Orbiter.log:

000000.000: ---------------------------------------------------------------
000000.000: D3D9 DLLs  : C:\WINDOWS\SYSTEM32\d3d9.dll [v 10.0.19041.1387]
000000.000:            : C:\WINDOWS\SYSTEM32\d3dx9_43.dll [v 9.29.952.3111]
000000.000: ---------------------------------------------------------------
000000.000: Module D3D9Client.dll ........ [Build 211207, API 211207]

What is in your logfile?

 

[n72.75]

I'll have to check when I get home tonight. Might be a d3dx9_43.dll vs d3dx9_42.dll thing. Thanks.

 

[n72.75]

**** Orbiter.log
000000.000: Build Dec 19 2021 [v.602931718]
000000.000: Timer precision: 1e-07 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 211219, API 211219]
000000.000: Module AtmConfig.dll ......... [Build 211219, API 211219]
000000.000: Module DGConfigurator.dll .... [Build 211219, API 211219]
000000.000: ---------------------------------------------------------------
000000.000: BaseDir    : C:\Orbiter\orbiter\out\build\x64-Debug\
000000.000: ConfigDir  : C:\Orbiter\orbiter\out\build\x64-Debug\Config\
000000.000: MeshDir    : C:\Orbiter\orbiter\out\build\x64-Debug\Meshes\
000000.000: TextureDir : C:\Orbiter\orbiter\out\build\x64-Debug\Textures\
000000.000: HightexDir : C:\Orbiter\orbiter\out\build\x64-Debug\Textures2\ [[DIR NOT FOUND!]]
000000.000: ScenarioDir: C:\Orbiter\orbiter\out\build\x64-Debug\Scenarios\
000000.000: ---------------------------------------------------------------
000000.000: D3D9 DLLs  : C:\Windows\SYSTEM32\d3d9.dll [v 10.0.19041.1387]
000000.000: ---------------------------------------------------------------
000000.000: Module D3D9Client.dll ........ [Build 211219, API 211219]
000000.000: Module DX9ExtMFD.dll ......... [Build 211219, API 211219]
000000.000: Module Framerate.dll ......... [Build 211219, API 211219]
000000.000: Module GenericCamera.dll ..... [Build 211219, API 211219]
000000.000:
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: [3DDevice Initialized]

Almost looks like something didn't link properly.