Archived

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

Paralax

DDraw7 Blts disturb the app's window!!

Recommended Posts

Hello, I got a really mysterious problem with Direct Draw 7.0 I was coding on a 2D Engine for a game and someday - without doing anything with the code - my testing window got severely disturbed by Direct Draw: receiving messages took the app some seconds the mouse pointer disappeared and/or stopped moving when inside the window moving the window or closing/minimizing/maximizing it was nearly impossible. And I can't think, how this could happen. The weirdest thing about this is, that deactivating hardware accelerated blitting for DDraw in the DirectX control panel makes the program go fine again! So I quickly assembled a testing app which only shows some random garbage in a window using a primary surface+backbuffer - same problem again! The little test program could be downloaded at http://www.8ung.at/speckdrumm/test.zip . Although it does just basic things I didn't want to include it here (ca.300lines). The zip contains the small release exe and the cpp file. If anybody had this error, I would like to hear, how he solved it. Thanks a lot everybody, and have a nice day. Paralax Speckdrumm Interactive - Specktacular Entertainment http://www.speckdrumm.com Edited by - Paralax on January 27, 2001 6:54:46 AM

Share this post


Link to post
Share on other sites
You wrote:
"And I can''t think, how this could happen. The weirdest thing about this is, that deactivating hardware accelerated blitting for DDraw in the DirectX control panel makes the program go fine again!"

Well, I can think of what the problem might be especially since running in software mode does the trick.

Let me just describe the symptoms first, see if I am thinking of the same thing:
Is every response in the application greatly delayed? When you try to move the window (using the mouse), does it only move the window like a minute after you instruct it to? When you try to exit, (using Escape key), do you have to hold the key down for about a minute before it actually exits? Is it frustrating you?

If this is the case, than the problem is rather simple. I had a very similar thing occur in one of my projects, but it is easily remedied. I looked at your sourcefile, and your main loop (which is called EVERY time thru the application is:

lpddsprimary->BltFast(50,50, lpddsback, NULL, DDBLTFAST_WAIT);

If you experiment removing this, your application should run fine. The reason it bogs down, is because in windowed mode, Blting takes a VERY long time to do, especially with the "DDBLTFAST_WAIT" parameter. What actually happens in your app, is that it keeps trying to blt, but it has to wait in line until the previous 100 blts have finished. And while it is waiting, more blts are trying to happen. So you get a big traffic jam. The reason it runs fine in software mode, is that blts take a LOT longer to perform in software mode, so the main loop isnt called as often, therefore the blts actually have time to be performed before the next one is called. Therefore, you dont have a problem.

This can be remedied rather easily. The easiest way, is to run in full screen exclusive mode. In this mode, the blt doesnt have to wait for GDI stuff, so it occurs almost immediately and doesnt clog up. I imagine your release version won''t run windowed mode, so it should run just fine without changes.
To remedy your windowed version, you need to slow your main loop down a bit. What I do, is I check the time each time my GameLoop function is called, and make sure that there is a time delay of at certain amount. If there isnt'', I return from the game loop (dont call evil Blt, or any DirectDraw functions if this is the case). A good time delay that works for me is 15 milliseconds.

DON''T add Sleep() calls, that is just wasted time. Just check the time delay, and that is all.

This problem will go away as your application becomes more complicated, since each loop thru the gameloop, it will take a while to process all the stuff. At the early stages, not much is done, so it runs too quickly, therefore you need to stall it a bit.

Share this post


Link to post
Share on other sites
Hey thanx a lot! You helped me save some hours/afternoons of trying to find out, why this happened.

I already know, why it didn''t occur before: Before I was testing my software alpha blending routines - no queue could be created by these

Have a nice day and may the coding gods be with you,
Paralax

Speckdrumm Interactive - Specktacular Entertainment

http://www.speckdrumm.com

Share this post


Link to post
Share on other sites