27 replies to this topic

[Alex]

I'd really run a profiler on a release build before optimizing anything...you're chances are high that you optimize at the wrong spot...
Also unless you're running on console only you'll do hard to get a constant frame rate..systems are so different and often you fight with different bottomlecks depending on the hw etc...as long as things are precached (few jerks when something new is processed) and your code is happy to handle variable frame times I wouldn't worry too much. Eventually the user can fine tune the settings to get a decent frame rate...

I don't quite agree with wernaeh about never being cpu bound. AFAIK you are almost always cpu bound unless you have a pure gfx demo (no ai, physiks etc etc). Even with pure gfx you're likely to get cpu bound unless you do something wrong to the hardware OR everything you render fit's the gfx card's vram and is static (only vertex/pixel shader processing required). Even then the cost of a dip call is huge. So unless your data requires few dips/frame (eg. less than about 100/frame in a 1ghz cpu at 30Hz) you will still be cpu limited.

Still it's a good idea to optimize the physics and maybe decouple it from the rendering.
If you can decouple the physics then you can run it at a frequency that fits the system's capabilities and you can run it in a spereate thread to utilize multicore or hyperthreaded systems. I don't know how viable/complicated it is to decouple physics as I've never done that. So maybe I'm jsut talking rubbish :)

Alex

[.oisyn]

Reedbeta: I see a bug in your code, specifically when WM_QUIT is not the last message in the queue

[Reedbeta]

.oisyn: WM_QUIT is always the last message in the queue

[monjardin]

I assume .oisyn is talking about this part:

while (PeekMessage(&msg, NULL, 0, 0, true))

    DispatchMessage(&msg);

if (msg.message == WM_QUIT)

    break;

Are you sure that WM_QUIT is always last? It seems like you should still be able to retrieve messages after a quit is posted. I know I've written MFC programs that had some user interaction after a quit request to clean-up and save data.

[.oisyn]

I stand corrected
Couldn't find any documentation about it in the msdn library though, but WM_QUIT seems to function like a WM_PAINT (it is held in the queue until there are no more messages left)

But what if another message is posted (from another thread) just before PeekMessage returns it's fetched WM_QUIT?

This outputs WM_USER, WM_QUIT, WM_USER, WM_USER:

#include <windows.h>
#include <iostream>

int main()
{
	PostQuitMessage(0);
	PostMessage(0, WM_USER, 0, 0);

	MSG msg;
	while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
		std::cout << msg.message << std::endl;

	PostMessage(0, WM_USER, 0, 0);
	PostMessage(0, WM_USER, 0, 0);

	while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
		std::cout << msg.message << std::endl;
}

So I guess it's technically still possible to miss the WM_QUIT in your loop, albeit under specific circumstances (do I hear raceconditions? )

[MarekKnows.com]

In my game loop i've been running some simple tests and I noticed that if I have <4000 particles on the screen then I get about 32fps. However when I bump up the # of particles beyone 4000 the fps drops very quickly to 8.... when I get to 7000particles, my game runs at 3fps.

I am now trying to re-work my game so that I don't get such a big performance hit.

[Reedbeta]

.oisyn said:

So I guess it's technically still possible to miss the WM_QUIT in your loop, albeit under specific circumstances (do I hear raceconditions? )

At the risk of hijacking this thread completely, I hadn't considered what could happen if multiple threads were posting to the main window's message queue. (I did mention that my application is currently single-threaded.) Nevertheless, I stand by my code: IMHO, the WM_QUIT message should only be posted when the application is truly ready to quit, i.e. after resources have been freed, graphics contexts deleted, worker threads stopped, and the main window about to be destroyed. For instance, when the user wants to quit I call DestroyWindow() on the main window; then I do all cleanup in the message handler for WM_DESTROY, and only then (just before returning from the handler) do I post WM_QUIT. In other words, WM_QUIT is not a signal for the application to begin its shutdown process; it's a signal that the shutdown process is done.

[.oisyn]

Sure, but you're not in control of other processes that are able to send your thread messages . But I agree that is an unlikely situation, and the reason I pointed it out was because I didn't know the WM_QUIT messages were held in the queue up until the last message. But personally, from what I know now, I would be defensive and put the "if(WM_QUIT)" inside the loop, the "optimization" of pulling it outside the loop (I'm not saying that was your reason) is of course quite pointless