Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 08-21-2011, 12:41 PM   #766
jarmonik
Beta Tester

Default

Quote:
Originally Posted by diogom View Post
 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 ----------

Quote:
Originally Posted by Eraser View Post
 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.
jarmonik is offline   Reply With Quote
Thanked by:
Old 08-21-2011, 12:54 PM   #767
Eraser
Donator
 
Eraser's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 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.
Eraser is offline   Reply With Quote
Old 08-22-2011, 01:40 AM   #768
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Old 08-22-2011, 03:48 AM   #769
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by martins View Post
 I've now uploaded a new beta (110822) to the sourceforge public beta list.
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:

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.
orb is offline   Reply With Quote
Thanked by:
Old 08-22-2011, 04:35 AM   #770
martins
Orbiter Founder
Default

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?
Attached Files
File Type: zip vcredist_x86.zip (2.54 MB, 21 views)
martins is offline   Reply With Quote
Thanked by:
Old 08-22-2011, 05:22 AM   #771
martins
Orbiter Founder
Default

Back to the D3D9 client: the 33b version seems to fix the problem with the main menu
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.
martins is offline   Reply With Quote
Thanked by:
Old 08-22-2011, 09:22 AM   #772
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by martins View Post
 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_FF1 F_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).


Quote:
Originally Posted by martins View Post
 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:
Code:
#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)
orb is offline   Reply With Quote
Thanked by:
Old 08-22-2011, 03:16 PM   #773
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 Back to the D3D9 client: the 33b version seems to fix the problem with the main menu
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.

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 ----------

Quote:
Originally Posted by martins View Post
 (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.

Code:
(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)
jarmonik is offline   Reply With Quote
Old 08-22-2011, 03:31 PM   #774
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Thanked by:
Old 08-22-2011, 03:37 PM   #775
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 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 is offline   Reply With Quote
Old 08-22-2011, 04:21 PM   #776
jarmonik
Beta Tester

Default

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.

Last edited by jarmonik; 09-20-2012 at 09:42 PM.
jarmonik is offline   Reply With Quote
Old 08-23-2011, 04:16 AM   #777
martins
Orbiter Founder
Default

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).
Attached Files
File Type: zip D3D9ClientLog_CTD1.zip (14.1 KB, 5 views)
martins is offline   Reply With Quote
Thanked by:
Old 08-23-2011, 11:27 AM   #778
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 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.
jarmonik is offline   Reply With Quote
Old 08-24-2011, 02:41 AM   #779
martins
Orbiter Founder
Default

Unfortunately setting the DisableDrvMgm flag doesn't make a difference to the CTD or the texture load failures.
martins is offline   Reply With Quote
Thanked by:
Old 08-24-2011, 10:26 AM   #780
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 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 ?
jarmonik is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project

Tags
d3d9client, graphicsclient


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 09:18 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.