New Release D3D9Client Development

[orb]

C:\Documents and Settings\my name>

By looking at it, the Desktop folder is inside that "my name" folder.
I tryed putting:
C:\Documents and Settings\my name>Desktop\bitmaps (I named the folder where the bmps are 'bitmaps') and then the 'nvdxt' lines. I get that 'Desktop\bitmaps' isn't recognized as an internal or external command, operational program or batch file.

Commands you need to write are highlighted (assuming you copied the nvdxt to the bitmaps folder):

C:\Documents and Settings\my name> [highlight]cd Desktop\bitmaps[/highlight]

C:\Documents and Settings\my name\Desktop\bitmaps> [highlight]nvdxt -file dgmk4_1_norm.bmp -dxt5nm[/highlight]

C:\Documents and Settings\my name\Desktop\bitmaps> [highlight]nvdxt -file dgmk4_2_norm.bmp -dxt5nm[/highlight]

C:\Documents and Settings\my name\Desktop\bitmaps> [highlight]nvdxt -file dgmk4_2_ns_norm.bmp -dxt5nm[/highlight]

C:\Documents and Settings\my name\Desktop\bitmaps> [highlight]exit[/highlight]

 

[diogom]

Coverted using -dxt5nm, DG still black. -v8u8 as jarmonik suggested earlier also gives the same result.

 

[jarmonik]

Atlantis does work for me with 2010P1, so something has changed. I don't think it's the Atlantis code itself, because there were only cosmetic changes. So it must be something deeper in the graphics code.

I have no idea what's going on with the Atlantis. But the problem could be related in a software vertex processing. I got a few strange effects when I tested software processing. I'll take a look in the Atlantis when the beta is released.

As for the main menu, D3D9 complains that CopyRect failed. I've attached the log for reference. The mechanism I used was fairly similar to the way the old info boxes were implemented. As you can see, I was trying to be a good boy and have separate textures for source and target for blits. Maybe you can spot what I did wrong. One question: should the source surface _not_ have a texture interface?

You didn't do anything wrong. It's ok and recommended to use textures as an source surface. The error was caused because there was no corversion rule programmed for this particular case. The problem is that there doesn't exists a blitter that could blit between two textures in a video memory. In this case the client has two options.

1. Upgrade the target type from a texture to a rendering target texture.
2. Bring the source texture into a system memory pool.

I have implemented the first option. I'll do some testing with the new build and I'll upload the dll after that.

 

[jarmonik]

Here is RC33b with the new texture to texture conversion rule implemented. The package contains only a dll file and it's compatible with the existing shaders (*.fx files).

 

[Eraser]

I copy my question from the normal map topic.
jarmonik, can you use a similar approach for animated textures?
Something like "texture_anim_2_500.dds", where "2" is the frame number, and "500" - the frame duration, in milliseconds. This could be useful for making cool rocket exhaust, or explosions.

 

[jarmonik]

Coverted using -dxt5nm, DG still black. -v8u8 as jarmonik suggested earlier also gives the same result.

Reinstall the RC33 from the first post and make sure that every file is replaced. Having a black DG sounds like the shaders are from a RC32 build those aren't compatible with the RC33 executable (D3D9Client.dll).

---------- Post added at 15:41 ---------- Previous post was at 15:23 ----------

I copy my question from the normal map topic.
jarmonik, can you use a similar approach for animated textures?
Something like "texture_anim_2_500.dds", where "2" is the frame number, and "500" - the frame duration, in milliseconds. This could be useful for making cool rocket exhaust, or explosions.

That sound a little difficult approach. Usually in an animated particle effects one texture is split in four quarters or smaller parts and the animation is done by altering texture coordinates. I thought this was already suppored in the Orbiter.

 

[Eraser]

That sound a little difficult approach. Usually in an animated particle effects one texture is split in four quarters or smaller parts and the animation is done by altering texture coordinates. I thought this was already suppored in the Orbiter.

I have not found anything about animated textures in the .msh format description, although there is a textures with the "D" flag, for the virtual cockpit's instrument panels, which can be dynamically changed during the simulation. Perhaps addon developers can clarify this issue.

 

[martins]

I've now uploaded a new beta (110822) to the sourceforge public beta list.

• I have not yet started modifying the graphics client interface. This is just an update to make sure we are working on the same page.
• From the next beta I will however start making changes to the client, along the suggestions in this (and the beta) thread. Hopefully the documentation will remain up to date, so that graphics client developers (Jarmo and Artlav) can keep track with the changes.
• The problem with Atlantis and the D3D9 client running under the beta seems to have disappeared when I built the 100822 beta. I'll keep an eye out, but for now I'll regard it as a temporary glitch.
• I haven't yet tried the 33b client with the beta, but I'll do that asap. (Jarmo - will I need a new set of shader model files?)
• This beta contains a fair number of loose ends. I only released it now to facilitate work on the graphics client. So please don't expect a polished release candidate.

 

[orb]

I've now uploaded a new beta (110822) to the sourceforge public beta list.

[highlight]For the users who have problems with running this version of Orbiter, because of lack of required runtime libraries or wrong side-by-side configuration:[/highlight]

You need to have enabled automatic updates in Windows, to get the required security update for Visual C++ 2005 SP1 (MS11-025). This update contains the version 8.0.50727.6195 of C/C++ runtime libraries, which was used to build Orbiter 110822. Those libraries (dated at May 13/14, 2011) aren't available in a downloadable redistributable package.

 

[martins]

A sorry, I hadn't realised that Microsoft had sneaked in a new set of runtimes to my compiler. Is this a major problem? Would it help if I roll back that security update? (I take it it's KB2538218).

Why would they update the compiler, but not release the corresponding set of runtime distributables??

Edit: Found a relatively recent vcredist_x86 in my VS folder. I'll attach it to this post. Maybe this contains the required runtimes? Can somebody who has problems try this one and tell if it works?

 

[martins]

Back to the D3D9 client: the 33b version seems to fix the problem with the main menu :thumbup:
except ... it crashes when displaying the frame rate graph. The problem here may be that I am buffering the graph on the source texture, by copying one column per second from the target texture, before copying the buffered graph back to the target texture. So for this particular blit the source and target textures are reversing places. Is that a problem? I could build the buffer on a third surface, but even then this buffer surface would have to act both as source and target, so that may not fix the problem.

 

[orb]

Edit: Found a relatively recent vcredist_x86 in my VS folder. I'll attach it to this post. Maybe this contains the required runtimes? Can somebody who has problems try this one and tell if it works?

I didn't have problems, because it was updated automatically for me a while ago, but I can tell that this package contains required version of the libraries (msvcp80.dll.8.0.50727.6195.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E, msvcr80.dll.8.0.50727.6195.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E). It must have been updated by the security update for the compiler, too (however, it isn't downloadable as standalone from Microsoft site). :thumbup:

Would it help if I roll back that security update? (I take it it's KB2538218).

For what it's worth, there is a way to choose the used assembly version at compiling time:

#ifndef __midl
//#define _SXS_ASSEMBLY_VERSION "8.0.50727.762"
#define _SXS_ASSEMBLY_VERSION "8.0.50727.4053"
//#define _SXS_ASSEMBLY_VERSION "8.0.50727.6195"
#define _CRT_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _MFC_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION
#define _ATL_ASSEMBLY_VERSION _SXS_ASSEMBLY_VERSION

#ifdef __cplusplus
extern "C" {
#endif
__declspec(selectany) int _forceCRTManifest;
__declspec(selectany) int _forceMFCManifest;
__declspec(selectany) int _forceAtlDllManifest;
__declspec(selectany) int _forceCRTManifestRTM;
__declspec(selectany) int _forceMFCManifestRTM;
__declspec(selectany) int _forceAtlDllManifestRTM;
#ifdef __cplusplus
}
#endif
#endif

Source: Avoiding problems with VC2005 SP1 Security update KB971090 (applies to the KB2538218 update as well)

 

[jarmonik]

Back to the D3D9 client: the 33b version seems to fix the problem with the main menu :thumbup:
except ... it crashes when displaying the frame rate graph. The problem here may be that I am buffering the graph on the source texture, by copying one column per second from the target texture, before copying the buffered graph back to the target texture. So for this particular blit the source and target textures are reversing places. Is that a problem?

The frame rate graph from the auxiliary info displays is running fine. No CTDs no errors. It should be ok to do the blitting like that atleast in d3d9. I'll try to extract some data from the client to see how it's handling the situation exactly. Of course, it would be good to find out why it's causing a CTD on your computer. I could make a debug build of the client after that I should be able to track the CTD based on it's address and register set.

So far, I haven't detected any CTDs with the new beta.:thumbup:

PS, The auxiliary info displays can be accessed by right-clicking the menu bar.

---------- Post added at 15:02 ---------- Previous post was at 14:59 ----------

(Jarmo - will I need a new set of shader model files?)

You don't need a new shader files for 33b. I will upload new shaders if the situation will change.

---------- Post added at 18:16 ---------- Previous post was at 15:02 ----------

It looks like the framerate display is a part of the menu bar. Both surfaces are converted into a render target textures. This could be a problem if GDI is involved in drawing but it looks like the graph is drawn by blitting a pixel. That's a great idea.

(1959: 20.11s 8us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1960: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (4,16)
 (1961: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1962: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1963: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1964: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1965: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (38,16)
 (1966: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1967: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1968: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (62,16)
 (1969: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1970: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1971: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (6,16)
 (1972: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (26,16)
 (1973: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1974: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (58,48)
 (1975: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (2,48)
 (1976: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1977: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (56,16)
 (1978: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1979: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (56,16)
 (1980: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1981: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,1)
 (1982: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1983: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,1)
 (1984: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (6,16)
 (1985: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (6,16)
 (1986: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (20,16)
 (1987: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,48)
 (1988: 20.11s 3us)(0xD94) StretchRect 0xA480D70 (main_menu_tgt.dds) -> 0xA480C88 (main_menu.dds) (1,1)
 (1989: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (58,48)
 (1990: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (2,48)
 (1991: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1992: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1993: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (4,16)
 (1994: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1995: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (38,16)
 (1996: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1997: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (4,16)
 (1998: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (1999: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (2000: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (2001: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (7,16)
 (2002: 20.11s 3us)(0xD94) StretchRect 0xA480C88 (main_menu.dds) -> 0xA480D70 (main_menu_tgt.dds) (24,16)

 

[martins]

Yes, there is no GDI involvement at all in the new menu/info bar design. Everything is done by blitting. The graph is implemented by blitting a 1-pixel wide column for each time sample (not just a single pixel, so that larger jumps don't look discontinuous - took me a while to make this look good).

Note that the other graph display (render statistics) currently only works with the inline client, but I may add the required interface to the graphics client for polling these values from external clients. I am thinking of polling for

• number of vertices rendered
• number of textures loaded
• number of surface tiles rendered
• number of vessels, celestial bodies, surface bases rendered

Would this information be easy to provide for the D3D9 client? I thought this would be quite handy as a debugging tool to explain why the frame rate slows down in particular situations.

 

[jarmonik]

Would this information be easy to provide for the D3D9 client? I thought this would be quite handy as a debugging tool to explain why the frame rate slows down in particular situations.

Yes, all the necessary information is available.

 

[jarmonik]

Ok, here is a debug build of the client. If you could reproduce the CTD with this build. The client should be able to capture and log the CTD in the D3D9ClientLog, if not, then you should see a typical windows report about the CTD on a screen.

Existing shaders will work with this build.

 

[martins]

Ok, it looks like the CTD doesn't have anything to do with the frame rate graph after all - that just seems to have been a coincidence of the scenarios I tested.

I consistently can reproduce the CTD in the "Atlantis satellite launch" scenario under the following two conditions

• Atlantis is present
• all visual effects enabled

If I either edit Atlantis out of the scenario, or disable the "Specular water reflections" and "planet night lights" options (but leave everything else on), the CTD disappears.

From the log file it seems that the client fails to load most of the Canaveral base tiles (which are present). These failures don't appear in cases that don't CTD.

Also, if I interpret the log file correctly, it looks like the client is trying to create a 1x0 surface just before the crash. Not sure where this is coming from.

I am beginning to think that this problem may be related to my video hardware (or lack thereof). Maybe running out of video memory? I am not sure if it is worth spending too much time on this, if nobody else has problems. Although it would be nice to get it working on modest hardware (frame rate is still playable).

 

[jarmonik]

I am beginning to think that this problem may be related to my video hardware (or lack thereof). Maybe running out of video memory? I am not sure if it is worth spending too much time on this, if nobody else has problems. Although it would be nice to get it working on modest hardware (frame rate is still playable).

Yes, I can confirm that. The computer has run out of video memory. The last error message comes from the TileBuffer::LoadTile_ThreadProc. (1x0) is the mipmap count and flags.

There is a driver memory model management flag "DisableDrvMgm" in the D3D9Client.cfg file you could set it to one and see if it has any effect in operation. I haven't been able to test it in action since my computer has never run out of video memory with the Orbiter. There is very little documentation about it but the manual says: "Direct3D will manage resources instead of the driver. Direct3D calls will not fail for resource errors such as insufficient video memory."

I'll try to track down a few memory leaks and improve the shutdown. Based on the information from a DirectX the memory leak is about 2MB in size.

 

[martins]

Unfortunately setting the DisableDrvMgm flag doesn't make a difference to the CTD or the texture load failures.

 

[jarmonik]

Unfortunately setting the DisableDrvMgm flag doesn't make a difference to the CTD or the texture load failures.

It's sad to hear that. I spend the last evening tracking down the memory leaks and I was only able to find two small textures. 90% of the leaks reported by the DirectX are less than 128 bytes in size. They are too small to contain any practical data. I don't know what's going on there. I'll try to analyze the client and find some ways to improve the memory efficiency but it's going to take more than just a few days.

Is anyone familiar with the COM (Component Object Model) ? Is there a way to get a list of all allocated objects those are derived from the IUnknown for a memory tracking purposes ?