Jump to content
  • Advertisement

Archived

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

Stephan

DirectDraw Render Loop Problem

This topic is 5957 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

Hello together, here''s a very simple WinMain Rendering Loop which only blits one big Surface to the Primary Surface: while (TRUE) { if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)) { if (!GetMessage(&msg, NULL, 0, 0)) return msg.wParam; TranslateMessage(&msg); DispatchMessage(&msg); } else if (g_bActive) { g_pDDSPrimary->Blt(&destRect, g_pDDSOne, &srcRect, 0, NULL); } else { WaitMessage(); } } The problem is, that the windows scheduler has sincere problems with blits in such tight loops. Windows messages are delayed up to several seconds until they appear in the applications message queue. If you try to move the window around, it will take seconds until the window is actually moved. I''ve inspected some DirectX sample progams and found that they bypass this problem with a little addition: while (TRUE) { if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)) { if (!GetMessage(&msg, NULL, 0, 0)) return msg.wParam; TranslateMessage(&msg); DispatchMessage(&msg); } else if (g_bActive) { thisTickCount = GetTickCount(); if ((thisTickCount - lastTickCount) > 10) { g_pDDSPrimary->Blt(&destRect, g_pDDSOne, &srcRect, 0, NULL); lastTickCount = thisTickCount; } } else { WaitMessage(); } } So basically they do some "busy waiting" to prevent too many blits. Is this really the right way? Why has the windows scheduler problems with blits? Best regards, Steve

Share this post


Link to post
Share on other sites
Advertisement
Edit post doesn''t work. Same posting with readable source code.
----------------------------------------------------------------

Hello together,

here''s a very simple WinMain Rendering Loop which only blits one big Surface to the Primary Surface:


  
while (TRUE)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (!GetMessage(&msg, NULL, 0, 0))
return msg.wParam;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else if (g_bActive)
{
g_pDDSPrimary->Blt(&destRect, g_pDDSOne, &srcRect, 0, NULL);
}
else
{
WaitMessage();
}
}


The problem is, that the windows scheduler has sincere problems with blits in such tight loops. Windows messages are delayed up to several seconds until they appear in the applications message queue. If you try to move the window around, it will take seconds until the window is actually moved.

I''ve inspected some DirectX sample progams and found that they bypass this problem with a little addition:


  
while (TRUE)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (!GetMessage(&msg, NULL, 0, 0))
return msg.wParam;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else if (g_bActive)
{

thisTickCount = GetTickCount();
if ((thisTickCount - lastTickCount) > 10) {
g_pDDSPrimary->Blt(&destRect, g_pDDSOne, &srcRect, 0, NULL);
lastTickCount = thisTickCount;
}
}
else
{
WaitMessage();
}
}


So basically they do some "busy waiting" to prevent too many blits. Is this really the right way? Why has the windows scheduler problems with blits?

Best regards,
Steve

Share this post


Link to post
Share on other sites
I wrote a little progran using the win GDI and found that the keys were lagged (but not when profiling was enabled), I never did find out what was wrong, but maybe your problem is mine.

I did try and use while(messages) in the message queue but that just resulted in an endless loop with no blitting or game updates as the queue was never empty.

Have to try and see if I can sort things out, cheers for the info (never had this problem in VB ).

,Jay

Share this post


Link to post
Share on other sites
Yup, that was the problem, my code works fine now. It seems that as I was inserting a GDI window update message into the queue each iteration of the main loop, there was no way the message handler could keep up. As such keyboard hits were getting pushed to the back of the queue along with other events (window closing etc) creating the lag.

,Jay

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!