I believe you need a manifest file to compile a project in release mode. Those two DLLs help you compile your code for release. Make sure you're compiling in Debug mode if that's what you want.

When it comes to doing breaks in my code, I just set breakpoints. In the end, it's probably less of a hassle than dealing with whatever craziness VS will throw at you.

Have you looked at the call stack?

It is quite possible the app is idleing, and the point of execution actually is in NT.dll without being in your code.

So, do you know how to access your call stack in the debugger?

Ok. So looking down the call stack, can you see your code anywhere in the call stack?

If so, there isn't a problem. Just work your way out of the NT.dll until you hit your code. It may take a few steps.

There are sometimes some issues when you call into system code. The system doesn't maintain the stack in the way that MSVC expects it -- so you have to repeatedly step out until the call stack starts making sense.

At other times, you'll be in a system DLL that wasn't called by your code.

Is your code multi-threaded? You may want to look at the THREADs window to make sure. Maybe you are halting in the wrong thread.

...

If you are always halting in the system DLLs, that actually tells you something -- it means that the majority of the time, your code is spending time in the system DLLs. :)

Maybe you are allocationg/deallocating memory/resources too much, or maybe there is another explanation. It really depends on what your code is asking the system DLLs to do.

Quote:
i heard that its an easy way to find out the slowest part of your code, just break 5 times, and whatever is in the call stack the most is probably a slow function, because most likely 90% of the time you should break in it etc.

That's a really, really terrible idea, actually. It's crude and inaccurate, even in the best-case scenario where your code is totally unoptimized (in which case its unsuitable for profiling anyway).

Look into getting yourself a profiler or learning how to insert timing/profiling code into your application.

Quote:
But it does show my exe using 99% cpu in task manager. And i get about 120 fps in the game.

This isn't really a problem. Windows is a not a cooperative multitasking environment. You're getting 99% of the CPU not because you're "stealing" it or anything, but because nobody else wants it but your game. If you want your game to reduce processor usage, have it Sleep() when it has nothing to do instead of spinning uselessly.

120FPS is probably not a huge performance issue either, depending on what you are drawing. But in any case, your "break every so often" methodology of profiling is rediculous and you should abandon it for more stable methods.

Quote:
What's the difference between /MT and /MD that I need to know about when making a game.

A quick search on the /MT and /MD compiler options from MSDN will tell you all about how they differ. Based on some of your posts, I'm not sure you have a complete understanding of what the differences are.

Quote:Original post by ViperG
I just hate it when i break that it mostly ends up in some dll that i don't care bout. Whenever that happens i have no symbols and my vars that i am watching aren't accesible.

I can't remember how VS2005 is set up by default, but that problem might be helped by going through Tools -> Options -> Debugging -> Symbols -> add http://msdl.microsoft.com/download/symbols and make sure it's enabled and caching somewhere sensible, if that's not there in the default setup. Then it should download the debugging symbols for system DLLs, so the call stack looks more correct.

Quote:Original post by jpetrie

Quote:
i heard that its an easy way to find out the slowest part of your code, just break 5 times, and whatever is in the call stack the most is probably a slow function, because most likely 90% of the time you should break in it etc.

That's a really, really terrible idea, actually. It's crude and inaccurate, even in the best-case scenario where your code is totally unoptimized (in which case its unsuitable for profiling anyway).

Yes, it is crude. But mathematically it is surprisingly accurate.

Know how monte carlo integration works? The rate at which a random sample based integration of a function converges to the intergrals value is not all that bad. This is the same technique -- monte carlo -- applied to profiling.

Quote:Look into getting yourself a profiler or learning how to insert timing/profiling code into your application.

Instrumenting profiling changes the very thing you are looking at. It has it's uses, but it isn't always the ideal solution.

Inserting timing/profiling code into your application manually usually takes developer time to think about the problem. It is a great way to deal with "slowdowns" on the order of fractions of a second that can't be repeated (startup slowdowns, for example). It is also nice in that the data is captured and explicit.

Quote:

Quote:
But it does show my exe using 99% cpu in task manager. And i get about 120 fps in the game.

This isn't really a problem. Windows is a not a cooperative multitasking environment. You're getting 99% of the CPU not because you're "stealing" it or anything, but because nobody else wants it but your game. If you want your game to reduce processor usage, have it Sleep() when it has nothing to do instead of spinning uselessly.

99% CPU means that your program is running most of the time. If your program wasn't running most of the time, one would EXPECT to randomly break and get "not in the program".

It isn't a problem, but it is useful information.

Quote:120FPS is probably not a huge performance issue either, depending on what you are drawing. But in any case, your "break every so often" methodology of profiling is rediculous and you should abandon it for more stable methods.

I find that it is easy to learn, easy to use, and it finds slowdowns faster than having to manually or automatically instrument your code and analyze the results.

It isn't a be-all end-all solution to profiling, but it actually works and actually lets you figure out what part of your code is slow.

It won't help you optimize the last 5% of your performance. But it will help you with the first 95% -- and it won't lead you astray into optimizing code that isn't taking any time in the first place!

[Edited by - NotAYakk on October 16, 2006 1:29:35 PM]