Sign in to follow this  
DanielH

[MDX] Closing the application takes forever

Recommended Posts

I'm making a simple terrain engine that is supposed to read new world sectors from cache files to be able to handle huge terrains. Works pretty neat but I haven't added any cache control to free unused memory so if I move the camera around the memory usage increases very rapidly :p What surprises me is that closing the application takes FOREVER. I can see in the task manager that after i press the "X" on the window, the memory usage decreases with like 1mb/second and keeps doing that for about 60 seconds before it finally closes down. Why does this happen? Freeing memory shouldnt take too long, should it? The game uses lot's of indexed buffers to keep geomipmapping data. I realise that most of the time is probably spent freeing up that memory, but shouldnt it take more like 1 second than 120? :|

Share this post


Link to post
Share on other sites
One possibility - are you leaking any D3D memory? I suppose that shouldn't be the case in a managed environment, but worth checking nonetheless.

If you leak lots of memory via native languages and have the debug runtimes enabled you'll get 10's of 1000's of lines of debug output. Simply writing that much data to the console really slows things down - I've had it take an extra 30-40 seconds to shutdown in these situations...

Failing that, maybe dig into the available .NET tools for debugging/profiling/monitoring? I'm not sure what they're called, but I've seen references to their existance [smile]

hth
Jack

Share this post


Link to post
Share on other sites
That's very strange. I don't imagine it takes that long to allocate the data. How much data is being allocated? I'm thinking that even if it's a lot it seems it shouldn't take nearly so long to free all the memory. Mine takes about 3 seconds.
I'd be suspicious of a misplaced variable concatenation or some loop related delay. If you have some safe release of memory, then multiple attempts to release the same memory wouldn't show up.
It's one possibility. I guess their's tons of other possiblities though. (It might not necessarily be related to freeing memory.) Maybe post up any code related to cleanup.
(edit: oops - I posted same time as jollyjeffers)

Share this post


Link to post
Share on other sites
I improved the performance by using a single indexbuffer per terrain patch and LoD-level. That should have decreased the number of indexbuffers with about 9 times. I could perhaps use a single indexbuffer for all LoD-levels on a patch but that would mean I have to generate all levels even if they aren't needed and that doesn't seem too good. Or maybe I just should keep one level of detail in the memory.

I also attempted to do some cache system to free terrain sectors that haven't been visited lately. I don't think it works though. I set alla references to null, but I see no difference in used memory. Is there any way to force a GC?

The performance is a lot better now but I still think it's too slow to shutdown. I have never had this problem with any game I've written in C++!

Share this post


Link to post
Share on other sites
Quote:
Works pretty neat but I haven't added any cache control to free unused memory so if I move the camera around the memory usage increases very rapidly
It sounds very much like you are leaking memory with d3d resources (yes this can happen with managed dx). Make absolutely sure you are disposing all d3d resources when you close your app and if you absolutely need to create any d3d resources on a per-frame basis, make sure you are disposing them each frame too (or better yet, put them in a using).

If this is the case, I shudder to think what was happening to the memory you were leaking in your native dx apps [wink]

Regards,
ViLiO

Share this post


Link to post
Share on other sites
A garbage collection can be forced by calling GC.Collect. It's generally not a good idea to do so. What would be better is to make sure any of your classes which contain DirectX resources implement the IDisposable interface. Then call dispose on them when you're done. You should look here: http://www.gotdotnet.com/team/libraries/whitepapers%5Cresourcemanagement%5Cresourcemanagement.aspx in section 3.4about implementing the dispose pattern. Don't forget to call Dispose on DirectX objects, too.

Share this post


Link to post
Share on other sites
1 thing you might want to check depending on how your running the application:

There was this error / bug with vs 2005 dev edition where in some cases if I ran the application in debug mode through the vs interface it would take a fairly decent amount of time to load up and shut down.

But if I just ran the .exe of my application everything ran great.

If vs is your IDE and you test this, and this is the problem just let me know and I can try to find the Microsoft link on how to correct this problem, as I dont remember off the top of my head its been so long.

Share this post


Link to post
Share on other sites
I had the same problem with my program but managed to track it down to some variables not having their finalize or dispose methods called before the owner class closed down.

I just went through every variable instanced whether my own or directx owned and attempted to finalise or dispose of them. If that didn't work I set the variable to NULL. If that didn't work I assumed Microsft handled it fine.

Almost all of my classes are IDisposable so I can release memory when the object is finished with.

The program runs significantly better now.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this