New Release D3D9Client Development

[n72.75]

So I'm running into a weird problem with [--I think--] D3D9 client.

This morning I was using both Orbiter Beta for some NASSP dev stuff, and Orbiter 2016, checking out Igel's Vostok.
In all cases Orbiter abruptly closed without an error message, however application logs show some details.

It's very strange that I'm getting similar [looking] errors in two separate instances and versions of Orbiter/D3D9 client.

Hopefully the offset values give some insight. Let me know if there is a way I can help gather more data.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Orbiter 2016, running the March 20 D3D9 client version (updating it now, I know it's old. I mostly use the BETA)

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x57c23356
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00accb4c
Faulting process id: 0x5280
Faulting application start time: 0x01d76b4dc57fc40d
Faulting application path: C:\Orbiter\Orbiter2016\modules\server\orbiter.exe
Faulting module path: unknown
Report Id: 94fb29fd-62bf-444b-a67b-a567b9303a63
Faulting package full name:
Faulting package-relative application ID:

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x57c23356
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc000041d
Fault offset: 0x00accb4c
Faulting process id: 0x5280
Faulting application start time: 0x01d76b4dc57fc40d
Faulting application path: C:\Orbiter\Orbiter2016\modules\server\orbiter.exe
Faulting module path: unknown
Report Id: a6cc5d32-e7f0-47a8-b030-8d57cc545d63
Faulting package full name:
Faulting package-relative application ID:

Orbiter BETA running r1356. I was using Apollo 7 to generate and log telemetry data over TCP (I'm 99% sure this is unrelated)

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x5d7c2f68
Faulting module name: OrbiterSound.dll, version: 0.0.0.0, time stamp: 0x5f31ea23
Exception code: 0xc0000005
Fault offset: 0x00015a2e
Faulting process id: 0x5174
Faulting application start time: 0x01d76b615704ff50
Faulting application path: C:\Orbiter\OrbiterBeta\modules\server\orbiter.exe
Faulting module path: C:\Orbiter\OrbiterBeta\Modules\Plugin\OrbiterSound.dll
Report Id: 40d2c04e-e8f5-45fe-8fa9-5298c3815120
Faulting package full name: 
Faulting package-relative application ID:

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x5d7c2f68
Faulting module name: D3D9Client.dll, version: 30.1.0.0, time stamp: 0x5f55d06b
Exception code: 0xc0000005
Fault offset: 0x000291a0
Faulting process id: 0x30d0
Faulting application start time: 0x01d76b63df7b0d6a
Faulting application path: C:\Orbiter\OrbiterBeta\modules\server\orbiter.exe
Faulting module path: C:\Orbiter\OrbiterBeta\Modules\Plugin\D3D9Client.dll
Report Id: 67e1902c-7afa-4e6d-9f32-b50d2d007909
Faulting package full name:
Faulting package-relative application ID:

 

[kuddel]

Exception code 0xc0000005 usually indicates (a) memory access violation.
But whether it's caused by D3D9Client or OrbiterSound, or if it happened at D3D9Client rsp. OrbiterSound (due to be given a invalid memory address, for example) is not clear.

As you can reproduce this "so nicely": Is there any other addon that is running in all those instances?

 

[DaveS]

I have been doing some experiments with existing atmosphere renderer, in a bid to get the best look overall. So far all my experiments have confirmed this, that the best solution for now is to tie horizon haze color and intensity to the actual solar angle. All my experiments have shown that the atmospheric color should start low (currently for Earth that is -1.500) and as the sun gets higher in the sky, the horizon color should track it at a specified rate to a specified maximum (for Earth that should be 0.5).

If this could be implemented with the current atmosphere renderer, it would be great.

 

[Mr. Residuals]

All my experiments have shown that the atmospheric color should start low (currently for Earth that is -1.500) and as the sun gets higher in the sky, the horizon color should track it at a specified rate to a specified maximum (for Earth that should be 0.5).

So basically that means like in the D3D9 Atmosphere Controls it should look like this right for the Horizon thing.: (See photo below)


In terms of the appearance, it should look like what is shown below, right?
(Here's the photo)

 

[DaveS]

Try the config files in the attached archive. Just extract it into Orbiter folder and overwrite the original files.

 

[jarmonik]

I have been doing some experiments with existing atmosphere renderer, in a bid to get the best look overall.

Could you post the modified shader ?

 

[DaveS]

Could you post the modified shader ?

What modified shader? I have not modified the shaders at all, just the parameters.

 

[jarmonik]

So far all my experiments have confirmed this, that the best solution for now is to tie horizon haze color and intensity to the actual solar angle.

Sorry, this led me to believe that you experimented with the shader code.

Also, how the atmosphere is looking can greatly depend on display settings. It looks much worse on my laptop than on desktop computer. We probably would need some-kind of build in display calibration and post-processing shader to match with the display.

But anyway here's a link to online display tests. Gamma and contrast are likely to most important ones. http://www.lagom.nl/lcd-test/gamma_calibration.php

 

[4throck]

All modern (last 5 years) displays should come reasonably well calibrated from factory and target sRGB
If not, there are controls on the graphic drivers that allow you to adjust gamma. Don't think we need an Orbiter specific adjustment.

 

[jarmonik]

My display is probably 12 years old running in sRGB. But, of course, there are "Movie" and "Photo" modes giving a very different color scale which don't look good for any purpose. The display on my Intel HD Graphics 4000 laptop is terrible even if it's not that old.
But, yes, agreed. Let's forget the build in calibration.

 

[DaveS]

This have nothing do with monitor color calibration or gamma settings. I present two screenshots, taken at the same time but with different horizon color settings. The first screenshot show the sunrise with horizon color set to -1.500. The second screenshot shows the same sunrise but with horizon color set to 0.5. The first one is more realistic with a golden color (there's a reason why the hour around sunrise/sunset is called the "golden hour") than the second with a cold blue horizon. It is more suitable for a sun that is high in the sky, around midday. D3D9Client version R4.22, Orbiter 2016, scenario is Delta-glider\DG-S ready for takeoff.

 

[N_Molson]

True, the second one looks "alien", like its another cold planet with maybe methane chemistry or such....

 

[DaveS]

This is the Wikipedia article on the "golden hour" as it relates to photography:

Golden hour (photography) - Wikipedia

en.wikipedia.org

 

[4throck]

My display is probably 12 years old running in sRGB. But, of course, there are "Movie" and "Photo" modes giving a very different color scale which don't look good for any purpose. The display on my Intel HD Graphics 4000 laptop is terrible even if it's not that old.
But, yes, agreed. Let's forget the build in calibration.

The sRGB mode should be ok. Over time your white point might drift and need adjustment, but there are usually RGB controls for that.
White point can be set visually by matching an overcast sky, as clouds are usually white
Laptop screens have viewing angle issues, but its possible to correct them.

Windows 10 has a built in calibration tool:

How to calibrate your PC's monitor on Windows 10

Is your Windows 10 device showing the right colors and black levels? In this guide, we'll show you the steps to calibrate your display.

www.windowscentral.com

A correct setting will improve ClearType font rendering across the system, so I recommend giving it a try.

 

[DaveS]

Could you post the modified shader ?

Just out of curiosity, which of the shaders in the D3D9Client folder of Modules\ do control the atmosphere rendering?

 

[gattispilot]

Weird. So I am converting some my HDC to sketchpad. When I run it in D3D9 I get a message Assertion fail.
I am using r4.11
[ BaseDir : D:\Orbiter2016\ ConfigDir : D:\Orbiter2016\Config\ MeshDir : D:\Orbiter2016\Meshes\ TextureDir : D:\Orbiter2016\Textures\ HightexDir : D:\Orbiter2016\Textures2\ ScenarioDir: D:\Orbiter2016\Scenarios\ 000000.000: --------------------------------------------------------------- D3D9 DLLs : C:\WINDOWS\SYSTEM32\d3d9.dll [v 10.0.19041.928] : C:\WINDOWS\SYSTEM32\d3dx9_43.dll [v 9.29.952.3111] 000000.000: --------------------------------------------------------------- 000000.000: Module D3D9Client.dll ........ [Build 200907, API 160828] 000000.000: Module ParkingBrakeMFD.dll ... [Build 210307, API 160828] 000000.000: Module CamControl.dll ........ [Build ******, API 050206] 000000.000: Module CameraMFD.dll ......... [Build 201023, API 160828] 000000.000: Module ScnEditorTLE.dll ...... [Build ******, API 060425] 000000.000: Module GPCMFD.dll ............ [Build 111222, API 100830] 000000.000: --------------------------------------------------------------- 000000.000: >>> WARNING: Obsolete API function used: oapiRegisterMFDMode 000000.000: At least one active module is accessing an obsolete interface function. 000000.000: Addons which rely on obsolete functions may not be compatible with 000000.000: future versions of Orbiter. 000000.000: --------------------------------------------------------------- 000000.000: 000000.000: **** Creating simulation session 000000.000: D3D9: [DirectX 9 Initialized] D3D9: 3D-Adapter.............. : NVIDIA GeForce GTX 1660 Ti D3D9: MaxTextureWidth......... : 16384 D3D9: MaxTextureHeight........ : 16384 D3D9: MaxTextureRepeat........ : 8192 D3D9: VolTexAddressCaps....... : 0x3F D3D9: NumSimultaneousRTs...... : 4 D3D9: VertexDeclCaps.......... : 0x30F D3D9: MiscCaps................ : 0x2FCEF2 D3D9: XNA Math Support........ : Yes D3D9: Vertex Texture.......... : Yes D3D9: Separate AlphaBlend..... : Yes D3D9: Shadow Mapping.......... : Yes D3D9: D3DFMT_A16B16G16R16F.... : Yes D3D9: D3DFMT_A32B32G32R32F.... : Yes D3D9: D3DFMT_D32F_LOCKABLE.... : Yes D3D9: D3DFMT_A2R10G10B10...... : Yes D3D9: D3DFMT_L8............... : Yes D3D9: D3DDTCAPS_DEC3N......... : No D3D9: D3DDTCAPS_FLOAT16_2..... : Yes D3D9: D3DDTCAPS_FLOAT16_4..... : Yes D3D9: Runs under WINE......... : No D3D9: D3D9Build Date.......... : 200906 D3D9: Available Texture Memory : 4073 MB 000000.000: D3D9: [3DDevice Initialized] 000000.000: D3D9: [Loading Constellations] 000000.000: D3D9: [D3D9Client Initialized] ... D3D9: ERROR: D3D9ClientSurface: GetDC() Failed D3D9: ERROR: Surface name is clbkCreateSurfaceEx Handle=0x223A5998 (256,256) D3D9: ERROR: Surface Has a Surface Interface D3D9: ERROR: Surface Is Lockable D3D9: ERROR: Surface is in a DefaultPool D3D9: ERROR: Surface has RENDERTARGET usage D3D9: ERROR: Surface Format is 22 D3D9: ERROR: ActiveFlags( OAPISURFACE_RENDERTARGET ) /ICODE] here is the code where I changed from HDC to sketchpad. I also noticed the font did not change in the rcsqty. [ICODE] void Atlantis::RedrawPanel_PANELRCSstatus(SURFHANDLE surf, int part) { char cbuf[20]; oapi::Font* font = oapiCreateFont(50, true, "Seven Segment"); oapi::Sketchpad* skp = oapiGetSketchpad(surf); skp->SetFont(font); skp->SetTextColor(0x0000FF); skp->SetTextAlign(oapi::Sketchpad::LEFT); sprintf(cbuf, "%2.0f", RCSQTY); skp->Text(0, 100, cbuf, strlen(cbuf)); skp->Text(210, 100, cbuf, strlen(cbuf)); skp->Text(105, 100, cbuf, strlen(cbuf)); oapiReleaseSketchpad(skp); }
and this:
void Atlantis::RedrawPanel_EVENTAFTstatus(SURFHANDLE surf, int part) { char cbuf[20]; oapi::Font* font = oapiCreateFont(70, true, "Arial"); oapi::Sketchpad* skp = oapiGetSketchpad(surf); skp->SetFont(font); skp->SetTextColor(0x000000); skp->SetTextAlign(oapi::Sketchpad::LEFT); sprintf(cbuf, "%d", Minutes4set); skp->Text(5, 85, cbuf, strlen(cbuf)); sprintf(cbuf, "%d", Minutes3set); skp->Text(70, 85, cbuf, strlen(cbuf)); sprintf(cbuf, "%d", Minutes2set); skp->Text(145, 85, cbuf, strlen(cbuf)); sprintf(cbuf, "%d", Minutes1set); skp->Text(220, 85, cbuf, strlen(cbuf)); oapiReleaseSketchpad(skp); }

 

[jarmonik]

Weird. So I am converting some my HDC to sketchpad. When I run it in D3D9 I get a message Assertion fail.
I am using r4.11

The stock implementation of Sketchpad is locked to 3 predefined fonts. I don't know if this is a bug or a feature but no custom user fonts allowed. However, gcCore::CreateSketchpadFont() will let you to create any font you like with additional customization options. Or you can just add '*' in the front of the name to override the build in limitation like "*Seven Segment".

The debug assertion is related to a failed GetDC() it has nothing to do with sketchpad at-least not directly. I haven't been able to find a reason for the failure, based on data everything is O.K. You could switch the Debug Level to 3 and reproduce the assertion. And then zip and attach the D3D9ClientLog.html from /Modules/D3D9Client/ to your reply.

It's possible that a use of Sketchpad has changes the surface format to something that's more sensitive to DC related errors.

 

[gattispilot]

Oh. Well I was told that "HDC is deprecated in Orbiter 2016". That is why I changed them. I did notice that the seven segment font did not work in normal graphics.

When I get home I will run it in debug level 3? and see.

And I was hoping that would fix the random CTD and call stack window issue

 

[gattispilot]

I did the *.oapi::Font* font1 = oapiCreateFont(50, true, "*Seven Segment");. And I got the font to show. No issues. but where to set the debug level?
D3D9: ERROR: UnDeleted Surface(s) Detected D3D9: ERROR: Surface 0x16D13E70 (clbkCreateSurface) (256,36) D3D9: ERROR: [Failed to Reset DirectX Device] (Likely blocked by undeleted resources)

 

[DaveS]

but where to set the debug level?

Video tab, Advanced button.