-
My SwapBuffers() function now looks like this:
Code:
void Bitmaps::SwapBuffers()
{
InvalidateRgn(hwnd, NULL, false);
UpdateWindow(hwnd);
}
I clear the buffer in the WM_PAINT case after blitting to ps.hdc. Guess I don't need the UpdateWindow in there, huh? I just tried it without & it works the same.
But fill me in on the message pump idea. My message pump looks like this:
Code:
if (PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE))
{
int result = GetMessage(&msg, 0, 0, 0);
if (!result)
{
gQuit=true;
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
I've tried out a number of different message pumps, and when they work they all lead to the same result. The one above used to work but maybe I need to do something different to handle all the paint messages?
-
PeekMessage() will use 100% CPU as it keep asking the OS if there is a msg until it gets one. This will tend to make all the other apps slow down. The no use of no remove and a call to GetMessage() may be slower than using a single peekMessage() and removing them.
Code:
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if(msg.message == WM_QUIT)
break;
if(!TranslateAccelerator(msg.hwnd, hAccel, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
DO NOT send a paint msg in your WM_PAINT handler!
Can you say 'infinite loop'. Put a break point in there and see what I mean.
>>InvalidateRgn(hwnd, NULL, false);
I think you miss the point. The idea was you draw to a buffer( hdc-1). When the drawing is finished you call SwapBuffers.
Try InvalidateRect() and use the same rect as in the BitBlt()
SwapBuffers()
1. copies the new buffer (hdc_1) to the one used to update the screen (hdc_2)
2. calls for a paint in just the area that it has changed.
the WM_PAINT handler then takes this hdc_2 and copies it to the one in the paint struct. Do not put any other code in the WM_PAINT. Another BitBlt here will slow the app down and clear your buffer (hdc_1) if some other event causes a paint ie user moves messagebox across your app. This is a bad thing if you have a multi threaded app and are drawing to the hdc as the paint handler clears it.
-
I hadn't been aware that double buffering is significantly slower than blitting directly into the front DC. The main cause of the problem (delayed reaction) seems to have been the number & size of the bitmaps I'm blitting to the screen. That may not be a complete explaination, but reducing the graphics load does solve the problem.
I'd been lazy before and used 32x32 bitmaps of 4x4 dots (pellets; the game's based on Pac-Man). I changed it to draw the pellets using a pen, and the performance is much improved.
It is still significantly slower than it was without double buffering, although the game is rather expensively designed overall. I may revert to no DB, but the better thing to do is redesign the game to be less blit-intensive. My goal has been to make the game run on slower computers. So basically my job now is to give the game a major tune-up, which it desperately needed anyway... :)