New Release D3D9Client Development

[jarmonik]

I was using one of the default Orbiter fonts with the GPCMFD, do you know if that is still available under the D3D9 client?

That's a good question. well, It should be.

Are you using MFD::SelectDefaultFont() or MFD2::GetDefaultFont() with SketchPad::SetFont() ?

It's very likely that MFD::SelectDefaultFont() won't work if the GPCMFD is derived from MFD2 class. However, in that case the MFD2::GetDefaultFont() should work when used with SketchPad::SetFont().

---------- Post added at 02:59 ---------- Previous post was at 02:52 ----------

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:

I have done lot of testing with D3D9Client and I have never seen anything like that and there's a nice shot in a post below. It should be pretty easy to fix that.

 

[David413]

That's a good question. well, It should be.

Are you using MFD::SelectDefaultFont() or MFD2::GetDefaultFont() with SketchPad::SetFont() ?

It's very likely that MFD::SelectDefaultFont() won't work if the GPCMFD is derived from MFD2 class. However, in that case the MFD2::GetDefaultFont() should work when used with SketchPad::SetFont().

I'm using the MFD::SelectDefaultFont() and the different screens select between the default "0" font and the "1" font. It would appear however that whatever font is set (depending on the flag setting in the config file) is the only font available. This same behaviour existed in the original Orbiter 2010 release, but patch 1 corrected the behaviour. I didn't feel like re-doing the entire program to use SketchPad so I've never updated it to MFD2 class. It might be possible that this is related to the Orbiter_ng in that it might not have been updated with patch 1 like the default Orbiter was.

 

[jarmonik]

I'm using the MFD::SelectDefaultFont() and the different screens select between the default "0" font and the "1" font. It would appear however that whatever font is set (depending on the flag setting in the config file) is the only font available. This same behaviour existed in the original Orbiter 2010 release, but patch 1 corrected the behaviour. It might be possible that this is related to the Orbiter_ng in that it might not have been updated with patch 1 like the default Orbiter was.

Then, it must be a bug in the orbiter_ng. MFD::SelectDefaultFont() should work when a MFD is derived from the original MFD class not the MFD2 class.

I didn't feel like re-doing the entire program to use SketchPad so I've never updated it to MFD2 class.

You are right, there's no point in re-doing a MFD. I am still using the old MFD class in the IMFD and I haven't detected any troubles with it. I don't use MFD::SelectDefaultFont(), I'll set the fonts like in the code above.

---------- Post added at 16:58 ---------- Previous post was at 16:38 ----------

:hesaid:
This is in RC35:

I'll might need some help with the shadow bug. That just doesn't make any sence. The client is using an orthographic projection for the shadows meaning that the light source is assumed to be an infinite distance away from the object. Therefore, a cast distance doesn't effect in the size of the shadow. Also the shadow should be no more than one pixel in size. In the screen shot the shadow looks like it's casted by a point light near the cylinder.

Could it be possible that the mesh is designed in a units of millimeters instead of meters and it's then scaled down to 1/1000th in size by a matrix ? Even if that would be the case the code should still get the shadow right.

Could someone post a scenario and link to an addon that's needed to reproduce it ?

Does the bounding box geometry reveal anything ? It would show hidden objects and meshes.

 

[jarmonik]

Ok, I think I found the bug. Does this work now ? (It's for the Orbiter 2010-P1)

 

[astrosammy]

I'll might need some help with the shadow bug. That just doesn't make any sence. The client is using an orthographic projection for the shadows meaning that the light source is assumed to be an infinite distance away from the object. Therefore, a cast distance doesn't effect in the size of the shadow. Also the shadow should be no more than one pixel in size. In the screen shot the shadow looks like it's casted by a point light near the cylinder.

Could it be possible that the mesh is designed in a units of millimeters instead of meters and it's then scaled down to 1/1000th in size by a matrix ? Even if that would be the case the code should still get the shadow right.

Could someone post a scenario and link to an addon that's needed to reproduce it ?

Does the bounding box geometry reveal anything ? It would show hidden objects and meshes.

Maybe it is because I use UCD to attach some vessels. Just a guess, I'll try to find that scenario. EDIT: Oops, didn't see your last post.

 

[Cras]

I was flying the XR-2 with space station parts from Orbiter Francophone. The MBRITR Solar panels seemed to be casting the big shadows in my pic, but I was able to see on one loading of the scenario the shadows of the KSC buildings.

The pattern was when I loaded in Orbit, I saw the shadow from my space station. When I loaded the scenario where the focus was on a vehicle on the ground, the shadows seen in orbit were KSC buildings, if that makes sense.

I will switch back to the PreloadBaseVisuals to 1, and test out the fix, and will report back.

 

[Columbia42]

I've been using RC34 for a while but I just downloaded RC36 and now the font on the right display panel of the XR2 looks a little blurry.

 

[Cras]

So far so good. I think you fixed the bug.

Did a few scenario loads with the focus on an XR2 in LEO, and I often found that I had a good chance of seeing a shadow of some sort resembling the solar array on the inorbit space station. So far, no sign of the large out of place shadows.

 

[David413]

Then, it must be a bug in the orbiter_ng. MFD::SelectDefaultFont() should work when a MFD is derived from the original MFD class not the MFD2 class.

You are right, there's no point in re-doing a MFD. I am still using the old MFD class in the IMFD and I haven't detected any troubles with it. I don't use MFD::SelectDefaultFont(), I'll set the fonts like in the code above.

I've posted a message in the beta forum to see if Martin can see if the Orbiter_ng was updated when the regular Orbiter was with P1 (I don't think so...)

Here are the fleet MFDs (RPOP and GPCMFD) with updated fonts such that the ShuttleFleetMFD flag is not needed. I think this works well enough for now.

Dave

 

[jarmonik]

Here are the fleet MFDs (RPOP and GPCMFD) with updated fonts such that the ShuttleFleetMFD flag is not needed. I think this works well enough for now.

Ok, Thanks, I'll remove the flag from the next release.

---------- Post added 25-11-11 at 00:04 ---------- Previous post was 24-11-11 at 23:09 ----------



ATTENTION: D3D9Client and Memory problems

There has been some reports about errors caused by an insufficient video memory. What is the current status with this problem ?

Does any of the following configuration settings help with the problem ? If does then which ones ?

MemAllocLogic
DisableDrvMgm
LoadTexturesInSystemMem
ManagedTiles

Does anyone use any of these settings in other than the default state ?

If they doesn't provide any help with any issue then I'll clean up the code and remove them.
.
.

 

[Marvin42]

D3D9Client and Memory problems

Hi,:facepalm:

System with ATI 200M, driver from ATI, increased memory allocation to 512M, Celeron 1,6Ghz
with Orbiter2010, default instalation+sound(from Dan) (no hires tiles installed)

Orbiter with D3D7 - no CTD, average 10 FPS, spikes of 15 FPS on Earth, playable

Deafult install of D3D9 - no CTD, averge 6FPS with spikes to 10 FPS on Earth, playable
4xMultisampling - enabled
MemAllocLogic 1 = small change of average to 8 FPS

DisableDrvMgm 1 = no change with MemAllocLogic to 1

MemAllocLogic 1 + LoadTexturesInSystemMem 1 = spikes to 15 FPS, average 8 FPS, definite change in playing performance

MemAllocLogic 1 + ManagedTiles 1 + LoadTexturesInSystemMem 1= average 12FPS, constant spikes to 25FPS on Earth.

Thanks :thumbup:

 

[jarmonik]

D3D9ClientRC37

Here is RC37 release.

- Some random shadow anomalies fixed.
- Advanced configuration dialog.
- Automated creation of symbolic links added in advanced setup.
- Shuttle fleet MFD flag removed.

Here are a few things to check.
- The automated creation of symbolic links
- The AA and anisotrophy hardware auto-detection in advanced setup
- Font AA power setting in CKBlit.fx while using Proof Quality fonts. This is the line "return float4(gColor.rgb, gColor.a*pow(abs(a),0.85f));" and the value under interest is 0.85f. You may adjust it between 0.5 and 1.0. It will make the charters stronger or thiner.

ATTENTION: D3D9Client and Memory problems

There has been some reports about errors caused by an insufficient video memory. What is the current status with this problem ?

Does any of the following configuration settings help with the problem ? If does then which ones ?

MemAllocLogic
DisableDrvMgm
LoadTexturesInSystemMem
ManagedTiles

Does anyone use any of these settings in other than the default state ?

If they doesn't provide any help with any issue then I'll clean up the code and remove them.

 

[Cras]

the whole automated creation of symbolic links creates a warning pop up window upon loading Orbiter_NG. This is under Win XP x64.

As a result, the D3D9 client doesn't load and I don't get the VIDEO tab in the launchpad.

Full error pop up read out is:

Orbiter Launchpadrbiter.exe-Entry Point Not Found
The procedure entry point CreateSymbolicLinkA could not be located in the dynamic link library KERNEL32.dll

 

[orb]

the whole automated creation of symbolic links creates a warning pop up window upon loading Orbiter_NG. This is under Win XP x64.

As a result, the D3D9 client doesn't load and I don't get the VIDEO tab in the launchpad.

Full error pop up read out is:

Orbiter Launchpadrbiter.exe-Entry Point Not Found
The procedure entry point CreateSymbolicLinkA could not be located in the dynamic link library KERNEL32.dll

I haven't tried the last release yet as I've been working in Linux lately, but I can confirm that statically linking against KERNEL32.dll that has CreateSymbolicLink is a bad idea, and this will make all users with Windows XP unable to use D3D9Client at all. Symbolic links are supported since Windows Vista. In Windows XP, or 2000 you can use only hard-links and junctions.

Much better solution is to use GetProcAddress to get the address of CreateSymbolicLinkA in kernel32.dll and use it only if returned address isn't NULL.

If symbolic links are used just for directories, using junctions is much better solution, as it works since Windows 2000 (and can be used to link cross-partition). Hard links for files can be used on the same partition, so if it isn't to create cross-partition file links, hard links can be used instead, too. All of them (i.e. symbolic links, hard links, junctions) will work only on NTFS system, so making them automatically isn't the best idea either, as Orbiter ran from a thumb drive would be most likely on a FAT file system.

 

[jarmonik]

I have used the GetProcAddress() function to avoid this problem. So, it must be a build problem. Ok, I found the problem. CreateSymbolicLink() was still used in one place.:facepalm:

void VideoTab::CreateSymbolicLinks()
{
    typedef BOOL (WINAPI* CSLProc)(LPCSTR, LPCSTR, DWORD);

    HMODULE hKernel = LoadLibrary("kernel32");
    CSLProc CSLFunc = (CSLProc)GetProcAddress(hKernel, "CreateSymbolicLinkA");

    if (CSLFunc == NULL) {
        LogErr("Symbolic link function not available");
        MessageBox(NULL,"The operation system lacks the ability to create symbolic links. Windows Vista or Windows 7 is required.","D3D9Client Configuration",MB_OK);
    }
    else {

        LogAlw("Symbolic link function is available");
        
        DWORD sattrib = GetFileAttributes("Modules/Server/Sound");
        DWORD cattrib = GetFileAttributes("Modules/Server/Config");

        bool bCreate = false;
        if (sattrib==0x410 || sattrib==0x10) LogAlw("Sound directory symbolic link is present");
        else bCreate = true;
        if (cattrib==0x410 || cattrib==0x10) LogAlw("Config directory symbolic link is present");
        else bCreate = true;

        if (bCreate) {

            int ret = MessageBox(NULL,"This function will create a symbolic links in /Modules/Server/ folder as required by some addons like the Orbiter Sound.\n\nDo you want to proceed ?","D3D9Client Configuration",MB_YESNO);

            if (ret==IDYES) {

                if (sattrib==0xFFFFFFFF) {
                    if (CSLFunc("Modules\\Server\\Sound","C:Sound",0x1)==0) {
                        DWORD err = GetLastError();
                        if (err==0x522) MessageBox(NULL,"Administrator privileges required","Error",MB_OK);
                        return;
                    }
                    else LogAlw("Symbolic link created to (Sound) folder");
                }

                if (cattrib==0xFFFFFFFF) {
                    if (CreateSymbolicLink("Modules\\Server\\Config","C:Config",0x1)==0) {
                        DWORD err = GetLastError();
                        if (err==0x522) MessageBox(NULL,"Administrator privileges required","Error",MB_OK);    
                        return;
                    }
                    else LogAlw("Symbolic link created to (Config) folder");
                }
                MessageBox(NULL,"Links created successfully","D3D9Client Configuration",MB_OK);    
            }
        } 
        else {
            MessageBox(NULL,"Symbolic links already exists","D3D9Client Configuration",MB_OK);    
        }
    }
}

 

[astrosammy]

Many addons using HUD texts are having problems with the D3D9 client. The text just doesn't show up. Maybe there could be a fix, like for David's MFDs?

I've noticed that all of that addons were released for Orbiter 2006 but work perfectly with the inline client in Orbiter 2010, here are some examples:

UCGO, UMMU
[ame="http://www.orbithangar.com/searchid.php?ID=3471"]Delta II Missions Mod[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=3822"]Progress M1[/ame]

 

[jarmonik]

Many addons using HUD texts are having problems with the D3D9 client. The text just doesn't show up. Maybe there could be a fix, like for David's MFDs?

You need to enable "GDI Compatibility" mode from the video tab to make an old style GDI HUDs to work but it will cause a major framerate drop especially with some hardware. If the "GDI Compatibility" mode is disable then GDI drawing attempts to the HUD (i.e. backbuffer) will fail.

It would be very good idea for addon developpers to update the HUD code to use SketchPad instead of GDI. However, it's perfectly OK to use the GDI in many other places or programs like MFDs.

EDIT: If the "GDI Compatibility" mode doesn't fix the problem then let me know about it.

 

[Cras]

checking the GDI compatibility box fixes the UCGO UMMU, Space Tugs, CTV huds for me.

Pretty much anytime I see the special HUD not work, the GDI compatability mode fixes it.

 

[astrosammy]

Yes, it works now. Unlike in older versions of the client, the framerate seems to be good and stable, and even anti-aliasing works if I enable it in Catalyst Control Center.

 

[astrosammy]

When I flew to Mars today and prepared for a Phobos landing, I found the following bug:
Phobos, Deimos and any other celestial bodies with mesh do not show up (they are there, but not their meshes).
This happens in both the P1 and Beta versions of RC37 and RC36. I also tested it in RC35, and they showed up again.