New Release D3D9Client Development

[cslevine]

Well, here is the base addon ( Paris for Orbiter ) wich is not well displayed with D3D9client, after RC22 :

[ame="http://www.orbithangar.com/searchid.php?ID=4472"]PARIS Simplified Paname for Orbiter v4.0[/ame]

it was beautifully displayed with RC22.
So hope the developpers of D3D9client could testing this addon for help them to improve and fix these displays issues of so called (transparency) but that i am calling "non displayed" mesh or "flat mesh" issues

Best regards

 

[jarmonik]

Well, here is the base addon ( Paris for Orbiter ) wich is not well displayed with D3D9client, after RC22

I found the bug and it's fixed already. The Paris will work again in RC36.

 

[Pyromaniac605]

Is this RC35 specific problem or does it exists in older versions ?

Does it have any effect if you set "EnableNormalMapping" to zero from D3D9Client.cfg ?

Are there any errors in D3D9ClientLog.html ? (The log is located in /Modules/D3D9Client/ )

The problem existed in RC34, I can't recall it being a problem before that.
Disabling normal mapping fixed it.

Edit: Or not. Some of them still don't work.
Here's my D3D9 log.

(0: 0.00s 3us)(0xBB4) ================ clbkInitialise ===============
(1: 0.00s 176us)(0xBB4) Orbiter Version = 100830
(2: 0.03s 31317us)(0xBB4) Index:0 640 x 480 60Hz (22)
(3: 0.04s 31749us)(0xBB4) Index:1 640 x 480 59Hz (22)
(4: 0.04s 32842us)(0xBB4) Index:2 640 x 480 72Hz (22)
(5: 0.04s 34641us)(0xBB4) Index:3 640 x 480 75Hz (22)
(6: 0.04s 35365us)(0xBB4) Index:4 720 x 480 56Hz (22)
(7: 0.04s 35924us)(0xBB4) Index:5 720 x 480 60Hz (22)
(8: 0.04s 36503us)(0xBB4) Index:6 720 x 480 72Hz (22)
(9: 0.04s 37563us)(0xBB4) Index:7 720 x 480 75Hz (22)
(10: 0.04s 38230us)(0xBB4) Index:8 720 x 576 56Hz (22)
(11: 0.04s 38946us)(0xBB4) Index:9 720 x 576 60Hz (22)
(12: 0.04s 39456us)(0xBB4) Index:10 720 x 576 72Hz (22)
(13: 0.04s 39850us)(0xBB4) Index:11 720 x 576 75Hz (22)
(14: 0.04s 40392us)(0xBB4) Index:12 800 x 600 56Hz (22)
(15: 0.04s 40784us)(0xBB4) Index:13 800 x 600 60Hz (22)
(16: 0.04s 41186us)(0xBB4) Index:14 800 x 600 72Hz (22)
(17: 0.05s 41584us)(0xBB4) Index:15 800 x 600 75Hz (22)
(18: 0.05s 41963us)(0xBB4) Index:16 1024 x 768 60Hz (22)
(19: 0.05s 42401us)(0xBB4) Index:17 1024 x 768 70Hz (22)
(20: 0.05s 42832us)(0xBB4) Index:18 1024 x 768 75Hz (22)
(21: 0.05s 43242us)(0xBB4) Index:19 1152 x 864 75Hz (22)
(22: 0.05s 43661us)(0xBB4) Index:20 1280 x 720 60Hz (22)
(23: 0.05s 44089us)(0xBB4) Index:21 1280 x 720 59Hz (22)
(24: 0.05s 44508us)(0xBB4) Index:22 1280 x 768 60Hz (22)
(25: 0.05s 44927us)(0xBB4) Index:23 1280 x 800 60Hz (22)
(26: 0.05s 45332us)(0xBB4) Index:24 1360 x 768 60Hz (22)
(27: 0.05s 45752us)(0xBB4) Index:25 1366 x 768 60Hz (22)
(28: 0.05s 46177us)(0xBB4) Index:26 1600 x 900 60Hz (22)
(29: 1.01s 8671us)(0xBB4) D3D9Client destructor called
(30: 1.01s 9582us)(0xBB4) Deleting Framework
(31: 1.01s 9961us)(0xBB4) --------------ExitModule------------
(32: 1.01s 10004us)(0xBB4) Log Closed

 

[jarmonik]

Is anyone else able to reproduce the CTD with XR2 skins ?

 

[Cras]

XR2 skins so far work fine for me.

I have been doing some more testing about my braking issue.
I tested it on a fresh install, braking perfomance in the XR2 KSC approach scenario is degraded under Orbiter NG and D3D9 when compared to Inline client on Orbiter.exe

I then took the XR2 to the moon to see how it works on a different celestial body and one with no atmosphere. In Orbiter NG D3D9, I cannot land the XR2. It will hit the surface of the moon, and then bounce up and down forever, with the velocity vector on surface HUD continuing to pan from top of my screen down. The XR2 lady continues to tell me that "Wheels up, Wheels down" over and over again. Under the scenario editor, it shows the XR2's status to be Active (Flight), it never switches over to Inactive(Landed). Under Inline Client and Orbiter.exe, I can land just fine.

This may be the cause of the issue of bad brake performance, as the plane does not actually land. However I have yet to try OGLA to see if it is a D3D9 issue, or a Orbiter_NG issue.

The results are consistant in three seperate installations, and when running D3D9/Orbiter_NG under Windows Xp X64 SP2 and Windows 7 x64 SP1.

 

[Cras]

Follow up on my braking issue (again, sorry), but it is a D3D9 issue. I tried the XR2 on Final Approach at KSC scenario using both the D3D9 client and the D3D7 client under Orbiter_NG, and the brakes are as expected in D3D7, and degraded under D3D9.

 

[jarmonik]

Follow up on my braking issue (again, sorry), but it is a D3D9 issue. I tried the XR2 on Final Approach at KSC scenario using both the D3D9 client and the D3D7 client under Orbiter_NG, and the brakes are as expected in D3D7, and degraded under D3D9.

I have replied in the bug report in a project tools section. http://www.orbiter-forum.com/project.php?issueid=866

 

[David413]

Shuttle fleet beta for D3D9

Hello everybody,

I have been home sick with a headcold the past couple of days, and I have recently purchased a new computer with Windows 7. Anyway, here is a beta version of the shuttle.dll that I think will work with the latest D3D9 client. Please try it and let me know if it works.

p.s., although the client warns that using the GDI will cause lower framerates, I get great framerates.

Dave

 

[Turbo]

Hello everybody,

I have been home sick with a headcold the past couple of days, and I have recently purchased a new computer with Windows 7. Anyway, here is a beta version of the shuttle.dll that I think will work with the latest D3D9 client. Please try it and let me know if it works.

Dave

Thanks alot for this! It seems to be working perfectly for me. Ive only flown 1 mission so far, but it worked great! The bay doors are working (which was the only real problem I noticed before), and the RMS is still working too. OMS textures are great, as are the Callouts for launch and landing. The DAP is also working good. (Ive only flown Atlantis so far, will test more later)

Thanks for your time making this work with d3d9! Now I can use it 100% of the time. I hope you feel better, and get over your cold quickly .



Edit1: Jarmonik, Im having an issue with the RC35 Reentry textures. The textures show, however they are plain White (no orange / grey smoke colors) during Reentry with any vessel. The issue goes away if I revert back to RC34. I can take a SS if needed, however its the same texture with any reentrys that ive done (stock atlantis and DG, Shuttle fleet). Thanks

 

[Astronut25]

Wierd Lighting Glitch

While playing around with some spotlights, I noticed that some items glow brilliantly in the light while most stuff works perfectly.

Any ideas on what is happening here?

DX9

DX7

 

[mateusiak22]

Hello everybody,

I have been home sick with a headcold the past couple of days, and I have recently purchased a new computer with Windows 7. Anyway, here is a beta version of the shuttle.dll that I think will work with the latest D3D9 client. Please try it and let me know if it works.

p.s., although the client warns that using the GDI will cause lower framerates, I get great framerates.

Dave

When a new version shuttle fleet ? Waiting a year

 

[jarmonik]

Edit1: Jarmonik, Im having an issue with the RC35 Reentry textures. The textures show, however they are plain White (no orange / grey smoke colors) during Reentry with any vessel. The issue goes away if I revert back to RC34. I can take a SS if needed, however its the same texture with any reentrys that ive done (stock atlantis and DG, Shuttle fleet). Thanks

I have already made a many changes in the particle effect color are sun light dependency. If the problem will still exists in RC36 then we take a closer look in it.

---------- Post added at 14:58 ---------- Previous post was at 14:53 ----------

While playing around with some spotlights, I noticed that some items glow brilliantly in the light while most stuff works perfectly.
Any ideas on what is happening here?

If the problem is local light sources related then there must be something wrong in the specular material behaviour. Can you post the mesh material defination that's used with the bad parts in the forum.

 

[Astronut25]

Ok, I've tracked it down, the meshes that are glitching are scaled/enlarged.


Two URMSs attached to this spacecraft. The small one is the original size of the mesh, while the other one is enlarged

Two inflatable modules on this space station. The inflated one is glowing brilliantly

 

[jarmonik]

Ok, I've tracked it down, the meshes that are glitching are scaled/enlarged.

Oh, Yes, that makes sence. The normals are scaled and that will scale the light. I need to normalize the normals after passing through a transformation matrices. Thanks for pointing that out.

 

[jarmonik]

RC36 Released

I have uploaded the RC36 release into the first post.


Improved near clipplane control:
I have implemented an improved near plane control that will reduce z-fighting problem from AMSO and should also fix some other near plane clipping issues. Give it a try and report any problems you find. There is also a bounding box geometry view implemented that can be activated from D3D9Client control panel [Ctrl+Shift+C] [Ctrl+Shift+B] (Key conflicts are detected with some addons. Will be fixed later). Green box is a meshgroup, Blue box is a mesh and Red box is a vessel.


ShuttleFleet MFD:
ShuttleFleet MFD font override has been implemented and can be activated from D3D9Client.cfg it's the "ShuttleFleetMFD" parameter. This will conflict with other addons when enabled.


GDI Compatibility & Sketchpad::GetDC()
The GDI compatibility option in a video tab will only effect into the backbuffer behaviour. It is perfectly OK to use GDI in MFD's and other costom displays. However, the GDI access into the backbuffer should be avoided. (Example: a GDI HUD).

There is also an other problem that's related into the Sketchpad::GetDC() function. As far as I recall the idea of the sketchpad is to provide a GDI independent drawing interface for the Orbiter but for some unknown reason there is a GetDC() function in the SketchPad. It's causing some trouble because the DC can't be always acquired for non-GDI drawing surface. Almost every application in the Orbiter seems to be using it in some cases. For an example the ShuttleFleet seems to be using a sketchpad based callback function to draw the HUD but the GetDC() is used which will make it to require a GDI compatibility mode to work. Why not use Skp->Text() instead of GDI's TextOut() ?

I have implemented an error/warning reporting for Sketchpad::GetDC(). An error or warning is reported only once for every surface that's receiving a GetDC() call from a sketchpad. Error means a failed operation (NULL returned). Warning just warns about the bad use of the function. The DC is acquired successfully.

The D3D9Client has two different versions of the SketchPad known as GDIPad and D3D9Pad. GDIPad is using GDI for drawing and D3D9Pad is using DirectX for drawing. The D3D9Pad is a default pad that is used for drawing into the MFD's and other surfaces. The D3D9Pad cannot use GetDC() where as GDIPad can use GetDC(). There is a new parameter "ForceGDIPad" in the D3D9Client.cfg that will force the client to use the GDIPad for generic surfaces like MFDs. The HUD will be still drawn by using D3D9Pad. The GDI compatibility mode in the video tab will enforce the HUD to use GDIPad as well which will also configure the backbuffer with GDI ability.

Bugs reported earlier
The bugs those are reported earlier should be all fixed. Please, give it a try and see if the problems are fixed. If not then report them here.

 

[David413]

Thank You

Seems to work great; one question however, what exactly is the "ShuttleFleetMFD" parameter doing? I'd rather update the GPCMFD to get the correct fonts rather than have you need to create a workaround that will cause conflicts with other add-ons. But, I don't know what to fix.

Thanks again,
Dave

 

[jarmonik]

Seems to work great; one question however, what exactly is the "ShuttleFleetMFD" parameter doing? I'd rather update the GPCMFD to get the correct fonts rather than have you need to create a workaround that will cause conflicts with other add-ons. But, I don't know what to fix.

It's very simple. You need to create a font and assign it into the hDC in a begining of MFD2::Update() here is the code. There is a wrong font assigned into to the hDC by default in DirectX 9. I don't know why it happens.

// Create the font in the constructor of the MFD
GPCMFD::GPCMFD(DWORD width, DWORD height, VESSEL *vessel) : MFD2(width, height, vessel)
{
    hFont = CreateFont(height/27, 0, 0, 0, 400, false, false, 0, 0, 3, 2, 1, 49, "Arial");
}

// Delete the font in the destructor of the MFD
GPCMFD::~GPCMFD()
{
   DeleteObject(hFont);
}


GPCMFD::Update()
{
    // Select the font in use in begining of Update()
    SelectObject(hDC, hFont);

    // Do the MFD content writing here

    // Remove the font from use by selectign a default system font in the end of Update
    SelectObject(hDC, GetStockObject(SYSTEM_FONT));
}

---------- Post added at 00:49 ---------- Previous post was at 00:29 ----------

Actually it might be better to do the update like this:

GPCMFD::Update() 
{
   // Select the font in use in begining of Update()
   // and store the old font    
   HFONT hOldFont = (HFONT)SelectObject(hDC, hFont);     

   // Do the MFD content writing here    

   // Remove the font from use by selecting the old font    
   SelectObject(hDC, hOldFont); 
}

 

[Cras]

I am getting some shadows being cast on the planet from orbit. Judging by the shape of them, they are being caused by the solar panels on my space station.

Here is a pic. I first noticed it happen under RC34 (it may have been RC35, but I think it was 34), and then now really noticed it again just now under RC36.

Here is a pic I just took of it:


ADDITION---

It seems to be caused by PreLoadBaseVisuals = 1 . I set it because I was getting some nasty little freezes as I passed overhead of some bases that have some mesh surrounding them, mainly Rochaumbeau, so I set it to 1 to help in that department. This line seems to cause these shadows, because I just loaded on scenario, and I seemed to be getting shadows cast on the Earth from orbit that are the same shape as shadows cast by the buidlings at the default KSC.

With the PreLoadBaseVisuals set back to 0, those shadows do not seem to appear upon loading the scenario.

 

[astrosammy]

:hesaid:
This is in RC35:

 

[David413]

It's very simple. You need to create a font and assign it into the hDC in a begining of MFD2::Update() here is the code. There is a wrong font assigned into to the hDC by default in DirectX 9. I don't know why it happens.

Thanks, I'll give it a try. I was using one of the default Orbiter fonts with the GPCMFD, do you know if that is still available under the D3D9 client?

Regardless, I'll play around with the fonts now. Thanks...

Dave