New Release D3D9Client Development

[misha.physics]

Was there anything special you did to make this appear, settings-wise.

Nothing special. Just downloaded the v240310 build, set a path to Orbiter 2016/Texture directory for "PlanetTexDir" in Orbiter_NG.cfg, and set Orbiter options on Launchpad (Video and others). No other addons at all.

The ground is just displayed flat when camera is approaching it at low altitude.

It happens both for the linear and cubic interpolation for the surface elevation settings on the Launchpad.

When the surface elevation is dissable (checkbox is unchecked) then all terrain is flat and there's not any black gaps, so everything is fine.

I've deleted the path for "PlanetTexDir" and copied Moon textures into /Textures/Moon/Archive from Orbiter 2016 and the flat problem remains.

One more observation: for example, the ground in Cape Canaveral is flat at closer distance of the camera, if we zoom out then the ground becomes elevated (we know this), but the runway area is elevated too (after zoom ut), so the runway doesn't remain flat as it should be, so the flat settings for the runway don't work and therefore DG is immersed into runway textures.

 

[jarmonik]

Here's a new patch for testing. It looks like there was nothing wrong in the tile cache. If a planet had no elevation data available then elevation manager was disabled due to resent optimizations. Having a planet with disabled elevation manager somewhere in a solar system caused issues in many other places. Why ? I don't know. It's now re-optimized slightly in a different way that elevation manages are valid for all bodies. Even though they return zeroes.

Let's do some final tests before Merge of the Pull Request. https://github.com/orbitersim/orbiter/pull/445

EDIT: I also found a bug that may effect in a virtual cockpit mouse click zones. Testing required.

 

[gamer19]

So this can't be tested on non-beta Orbiter right ?
I play with 2016 only

 

[n72.75]

Here's a new patch for testing. It looks like there was nothing wrong in the tile cache. If a planet had no elevation data available then elevation manager was disabled due to resent optimizations. Having a planet with disabled elevation manager somewhere in a solar system caused issues in many other places. Why ? I don't know. It's now re-optimized slightly in a different way that elevation manages are valid for all bodies. Even though they return zeroes.

Let's do some final tests before Merge of the Pull Request. https://github.com/orbitersim/orbiter/pull/445

EDIT: I also found a bug that may effect in a virtual cockpit mouse click zones. Testing required.

Well the elevation issue definitely seems to be fixed. I wouldn't have guessed that was the problem in a hundred years.

The soft-dock code looks very cool. Haven't had a chance to play around with that yet, but it sounds like GLS tested it.

So this can't be tested on non-beta Orbiter right ?
I play with 2016 only

Correct. OpenOrbiter Only.

 

[jarmonik]

Well the elevation issue definitely seems to be fixed. I wouldn't have guessed that was the problem in a hundred years.
The soft-dock code looks very cool. Haven't had a chance to play around with that yet, but it sounds like GLS tested it.

The soft-dock code is very much Martin's code that's modified. Yeah, that tile problem is a real mystery. I kinda bugs me that the reason for the failure is yet unknown. Physics and graphics elevations are very much separate systems and the problem effects them both in a same way. Have to move on.

 

[misha.physics]

Here's a new patch for testing.

I copied these files into my 240310 build and was going to test this, but I get errors after running Orbiter_ng.exe. The errors say the ucrtbased.dll and vcruntime140.dll are missed. Do I need these files to try your patch? I just haven't gotten these errors before, maybe I do something wrong.

And I see right now a new Orbiter build on GitHub. Do I understand correctly that for now it doesn't contain the fixes/changes you've put in the PR445_Test.zip patch above?

I also found a bug that may effect in a virtual cockpit mouse click zones. Testing required.

Could you describe this bug a little more detailed so I can try/reproduce it?

Those "some see the issue, but others don't" always makes me think of uninitialized members

Could you explain what do these "uninitialized members" mean? And how it can be that some people can see the issue, but others don't.

 

[GLS]

Could you explain what do these "uninitialized members" mean? And how it can be that some people can see the issue, but others don't.

Consider this code:

int a;
int b;

b = a + 3;

What will be the value of b? It depends on what is in a... but as we don't define the content of a, it will depend on what is in that particular memory location: your pc might have 74, mine might have 943, and somebody else's might have -9872186. Plus, next time you run it, it might have a different value. And this is how sometimes the same code does different things in different computers.
That's why it is a good practice to initialize variables (variables inside classes are called member variables). Still, we humans tend to miss things.

 

[Gondos]

The soft-dock code is very much Martin's code that's modified. Yeah, that tile problem is a real mystery. I kinda bugs me that the reason for the failure is yet unknown. Physics and graphics elevations are very much separate systems and the problem effects them both in a same way. Have to move on.

If I'm not mistaken the soft docking stuff was added to the base VESSEL class, won't it kill any chance for 2016 modules to be compatible? Maybe it's already the case that a recompile is mandatory anyway?

 

[n72.75]

If I'm not mistaken the soft docking stuff was added to the base VESSEL class, won't it kill any chance for 2016 modules to be compatible? Maybe it's already the case that a recompile is mandatory anyway?

It probably would be good to test this against some Orbiter 2016 vessels. I believe there have been several other small VESSEL class changes (including one I'm responsible for); and if I'm not mistaken, at least one or two core/API/base class changes occurred prior to Orbiter becoming open source.

I wouldn't recommend not including this feature though; I think it's going to be very important for SSV and NASSP. Hopefully all the symbols still line up. I'm kind of, of the mind that at a certain point, not having a new version is more impactful to the community than losing support for older versions.

 

[misha.physics]

Just wanted to confirm that the last 240315 build works fine. The elevation issue doesn't occur. And these new water settings are amazing. Thanks!

 

[jarmonik]

If I'm not mistaken the soft docking stuff was added to the base VESSEL class, won't it kill any chance for 2016 modules to be compatible? Maybe it's already the case that a recompile is mandatory anyway?

Existing functions still operate the same was as before. Compatibility isn't effected. Compatibility breaks down only if virtual functions are added/removed.

 

[misha.physics]

By the way regarding elevations. I made tests with the last build, and I always notice the cubic interpolation + D3D9 terrain flattening issue I mentioned before. Maybe someone could confirm this. You could just create the file in the last Orbiter build directory:

Textures/Earth/Flat/CapeFlatTest.cfg

Then add the line:
ELLIPSE 250 -80.6745 28.6268 500 300 130 10
And look at your Cape Canaveral.

The linear interpolation works fine:



But the cubic one have the gap (for the same camera position). It happens then the camera follows the area:



I was going to create a corresponding issue on GitHub (since I haven't seen similar issues), but maybe it will be better if you do this.

It's for a future development, just not to forget this. Maybe it could be fixed before the Orbiter 2024 release, but not necessary. There's no difference between linear and cubic interpolation for surface elevation at high altitudes, only near elevations (see attached pictures).

 

[gattispilot]

try to get my Eagle to work and get get:
D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL

Not sure all these bases not catalogued?

D3D9: ERROR: Base Object 0x34955A8 = 'Alcantara' not cataloged
D3D9: ERROR: Base Object 0x3495918 = 'Al Anbar' not cataloged
D3D9: ERROR: Base Object 0x34A6EB0 = 'Baikonur' not cataloged


For drawing on a Texture should we be using Sketchpad and not older HDC graphics?

 

[gattispilot]

I have no clue. My Eagle freezes when I exit I get this as the start screen,
Here is the log:
000084.918: D3D9: [Session Closed. Scene deleted.]
D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL
000084.918: D3D9: [Destroy Render Window Called]
D3D9: ERROR: [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)
000084.918: **** Closing simulation session

for 2016

if I remove these lines it seems to work
oapi::Font* font = oapiCreateFont(15, true, "Arial");
skp->SetFont(font);
What this does is changes the font in the UACS hud. oapi::Font* font = oapiCreateFont(15, true, "Arial"); skp->SetFont(font); int x = HIWORD(skp->GetCharSize()); int rightX = hps->W - x; int startY = int(0.215 * hps->H); int y = startY; int space = LOWORD(skp->GetCharSize()); int largeSpace = int(1.5 * space);
with these 2 line:
000000.000: D3D9: [Scene Initialized]
000000.000: Finished initialising panels
000003.350: D3D9: [Session Closed. Scene deleted.]
D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL
000003.350: D3D9: [Destroy Render Window Called]
D3D9: ERROR: [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)
000003.350: **** Closing simulation session

 

[jarmonik]

D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL

I can't find this error from D3D9Client. Have you replaced the D3D9Client that comes with OpenOrbiter with an older one ? If yes, then that's not going to work.

 

[gattispilot]

I can't find this error from D3D9Client. Have you replaced the D3D9Client that comes with OpenOrbiter with an older one ? If yes, then that's not going to work.

Sorry this is for 2016

 

[gattispilot]

So when I use these 2 line to change the font for the UACS menu I get this:
D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL
000046.756: D3D9: [Destroy Render Window Called]
D3D9: ERROR: [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)
000046.756: **** Closing simulation session

oapi::Font* font = oapiCreateFont(15, true, "Arial", FONT_BOLD); skp->SetFont(font);

int x = HIWORD(skp->GetCharSize()); int rightX = hps->W - x; int startY = int(0.215 * hps->H); int y = startY; int space = LOWORD(skp->GetCharSize()); int largeSpace = int(1.5 * space); if (hudMode == HUD_OP) { buffer = std::format("Selected available cargo: {}", mdlAPI.GetAvailCargoName(cargoHUD.idx)); skp->Text(x, y, buffer.c_str(), buffer.size());

 

[GLS]

So when I use these 2 line to change the font for the UACS menu I get this:
D3D9: ERROR: D3D9Client::clbkReleaseSurface() Input Surface is NULL
000046.756: D3D9: [Destroy Render Window Called]
D3D9: ERROR: [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)
000046.756: **** Closing simulation session

oapi::Font* font = [B][COLOR=rgb(184, 49, 47)]oapiCreateFont[/COLOR][/B](15, true, "Arial", FONT_BOLD); skp->SetFont(font);

int x = HIWORD(skp->GetCharSize()); int rightX = hps->W - x; int startY = int(0.215 * hps->H); int y = startY; int space = LOWORD(skp->GetCharSize()); int largeSpace = int(1.5 * space); if (hudMode == HUD_OP) { buffer = std::format("Selected available cargo: {}", mdlAPI.GetAvailCargoName(cargoHUD.idx)); skp->Text(x, y, buffer.c_str(), buffer.size());

Missing the oapiReleaseFont() call?

 

[gattispilot]

Thanks. yes that seem to fix it

 

[DaveS]

@jarmonik Could you include a section on *.flt files in the OpenOrbiter D3D9Client manual?