Archived

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

Direct3D windowing problem

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

Whenever my D3D window is completely covered, the mouse movement is screwed up. Is there a windows message or function that I can use to determine if a window is completely covered? Someone please help! I''ve been trying to find an answer for about a week. Please provide code if you can. Thanks.

Share this post


Link to post
Share on other sites
This should not be a problem. In fact, a completely covered window should not affect mouse movement at all.

What sort of mouse-oriented code do you have in place? In particular, are you attempting to capture/release the cursor? Hide/show the cursor? Are you using DirectInput?

[edited by - darrell l on November 6, 2002 11:33:49 PM]

Share this post


Link to post
Share on other sites
lucid, you probably have your code inside the main
window loop. What happens when your dx window is
completely covered is something like your app
steals almost all the computer''s resources.
Everything get''s garbled, not just mouse.
I got the same thing !

I do not quit understand yet myself exactly why it
is so, but here is a simple way to handle the problem:

Just make the program wait a few milliseconds after
the completion of a frame, f.inst right after the
device->present().

I do this by applying a simple function of my own:

void delay(int ms){
HANDLE h=CreateEvent(NULL,true,false,NULL);
WaitForSingleObject(h,ms);
CloseHandle(h);
}

Then my "gameloop" is somewhat like:

while ( ''peekmessagestuff'' )
. render a lot of stuff
. dx8device->present(0,0,0,0)
. delay(5)

Now you can cover or hide your multimillion dollar
game without problems :-)

I think there must be an even better way to handle
this though. This way at least is very simple ...

Share this post


Link to post
Share on other sites
does the mouse move a bit then stall, then move a bit then stall etc...?

you can stop that bt handling the WM_ACTIVATE massage. What you can do in you game loop is have a BOOL called bAppIsActive. so it would be something like

  
while(msg.message != WM_QUIT)
{
if(PeekMessage(...)
{
//trnaslate, dispatch here

}
else
{
// Only render if app is active

if(bAppIsActive)
{
//render stuff

//handle music

//handle direct input

}
}
}


so only when your app is active the rendering will be done and everything, but when you get an inactive message make sure to set the bAppIsActive to FALSE;






"I know sometimes I ask stupid questions...but i mean well "
[Triple Buffer-My home]|[SCRIPTaGAME]|[My Old Site]

Share this post


Link to post
Share on other sites
My program consists of a spinning triangle. I want the triangle to spin even when the window loses focus. I am not doing any fancy mouse stuff and I am not using DirectInput. I cannot use the WM_ACTIVATE message, since that will stop the spinning as soon as the program loses focus.

The program works fine when the window is in the background or even when it is 99% covered with other windows. As soon as the window is 100% covered, I get the stalling problem that alfmga referred to. Someone else gave me a solution similar to Bratsj''s solution using a simple call to Sleep(milliseconds); While this solution works, it''s not very elegant and probably not the best way to do it.

Basically, my program thread needs to go to sleep instead of hogging the CPU. The difference between PeekMessage and GetMessage is that PeekMessage returns NULL if there are no messages in the queue while GetMessage puts the program to sleep until a message is received.

So code like this would solve my problem:

if(windowTotallyHidden)
GetMessage(...);
else
PeekMessage(...);

The problem is determining when the window is hidden... :o(

As a side note, I am bothered by that fact that I have to do something special to get proper behavior. And I am surprised that every tutorial I have downloaded has this problem. As far as I''m concerned this is a bug with DirectX or Windows... OpenGL does not have this problem.

Share this post


Link to post
Share on other sites