Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

OklyDokly

profiling with threads and dialogs

This topic is 5234 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I''ve just written a profiler library for my game engine, but there''s something I wish to do, which I am having problems doing. My libraries are being designed so that they are plug and play from any type of windows application (MFC, win32 SDK, console applications etc), and the profiler so far can get the timings for blocks of code and dump the stats in a buffer. However, I want to be able to see the stats real time, every frame (or dump), instead of showing them in a console application, and I want to do this generically from any type of application. What I decided would be the best way to do this would be to dump the stats at the end of each frame to a modeless dialog box (which eventually could also contain other debug information). This leads me to my problem. The way the profiler is designed at the moment, the dialog can only be updated every dump. This might be a long time if we are say loading a level and profiling how long it takes to load, as a dump will only be at some point in the game code. I want the dialog to be updated a lot quicker, so it actually behaves like a real window, and so the best way I decided on doing this would be to have a profiler thread. Anyway I''m having a problem with the thread, and am wondering two things. 1) Can anyone think of a better way to solve this problem? 2) Does anyone know of any useful documentation which might help me. The program gets as far as creating the window in the new thread, but then leaves the thread when it gets to the GetMessage() function and never returns to it. I presume creating new windows in new threads isn''t like creating windows in normal applications

Share this post


Link to post
Share on other sites
Advertisement
quote:
I presume creating new windows in new threads isn''t like creating windows in normal applications

It is, once you call a GDI function or anything that touches the message queue (like GetMessage()) a message queue is created on the current thread.

Just use PostMessage() from your main thread to your profiler thread. Use a struct or something and pack it into the LPARAM, and extract it on the other side. Don''t use the message reception times for profiling as message queues are relatively slow, instead do the timing within the main thread and send the results over.

Share this post


Link to post
Share on other sites
Thanks antareus

I''ve pretty much got it working now. After a bit of research and a cup of coffee I decided it was best to use PeekMessage() rather than GetMessage(), and messages are sent across with the PostThreadMessage() function. Synchronisation is also handled by creating an event in the main thread, and setting the event when the message queue has started up. Also the profiler thread is only really used for dialog processing, most of the profiler implementation is done in the main thread.

By the way, would anyone be interested in an article about how I created this profiler. I feel it is a very useful tool, and that it is about time I made a contribution to the Gamedev community.

Share this post


Link to post
Share on other sites
Does the profiler create the dialog box?
That''s very tight coupling between the profiler and GUI.

The profiler ought to have some query method that returns a set of statistics in a record. Then you can write code to show it in the game (e.g. fps), pop-up a dialog, or write to a log file.

Share this post


Link to post
Share on other sites
yeah you can query the profiler stats too, and the dialog is only created on demand.

I''m eventually going to write a seperate library solely to display a dialog box which has lots of debug and profiling features, allowing you to do stuff like change variables on demand, and of course having a multi-page profiler in it as well.

At the moment though it is the profiler interface that creates the dialog box, although I have made sure to keep the dialog code well away from the profiling code so it doesn''t interfere

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!