Sign in to follow this  
Interesting Dave

Someone shoot me and/or windows

Recommended Posts

I have a problem (other than the death wish caused by this bug(s)). Has anyone ever seen window messages cause timing issues? (both QPC (with affinity mask set) + timeGetTime()). Vista, 64bit. For example if my (windowed) window hasn't currently SetCapture(hWnd); any mouse movement over my game window jumps my (supposed to be v-synced) FPS from 60 to 70-200 (constant delta of 16ms to 4-30ms averaged over 32 frames). It's very possible that I'm not doing something I'm supposed to be doing with the messages, but I've tried everything any tutorial, msdn or forum post has ever even suggested. I'm on a AMD dual core, but have the timing issue driver patch (which fixed other things..), and I've grabbed various vista hotfixes and prayed for guidance. None of these things seem to help.

Share this post


Link to post
Share on other sites
Aardvajk    13207
It might help to know what graphics API you are using.

Also, post your message loop. Moving the mouse over the window is a situation where your application recieves a constant string of messages very quickly so there may be, as you say, something wrong with the way you are pumping your loop.

Is the change in frame-rate visually noticeable, or do you think that your FPS timing is being made inaccurate, or can't you tell? Have you tried measuring the frame-rate with something like Fraps?

Share this post


Link to post
Share on other sites
TheTroll    883
Sorry can't offer to shoot you. Do you realize how hard it is to get ammo now days?

My guess is you are not allowing windows to do it's messaging by taking too many cycles.

theTroll

Share this post


Link to post
Share on other sites
I'm using OpenGL

The FRAPS overlay stays at 60 normally, then if I apply the same test (move mouse over window when its not in focus) the overlay stays around 60 (59-61). However, when using FRAPS' benchmarking to get the frametimes, it gives very similar results to my own performance readouts(3.9 - 32.2 ms)

The game visibly speeds up during this time - AI warps across the screen to where they're going - that would be my dodgy time indep. movement code reacting badly to the wacked delta.


while(app->GetRun())
{
while(PeekMessage(&msg, NULL, 0,0,PM_REMOVE))
{
// handle or dispatch messages
if(msg.message == WM_QUIT)
break;
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}

//game codez
}

Share this post


Link to post
Share on other sites
empirical2    567
Sounds like messages are causing the game "once per frame" code to be called more than once per frame?

e.g instead of waiting for the next 1/60th of a second each mouse move message is triggering it over and over.

But cant see why from your snippet would need to see more.

Share this post


Link to post
Share on other sites
Figured that'd be the most likely cause, so first thing I checked, and just checked again. Def. not stuff getting called twice that shouldn't be.

On an up note, its fixed itself - to a degree. After putting some debug stuff (a few lines) in and then removing it (and the source control saying everything's exactly the same, it now only goes up to about 67fps.

*shrug* I'm not sure what that means.. :( any ideas?

Thanks for the help so far guys.


[EDIT] Ah no sorry, the code hadn't changed, but the data had. When there is more in a level (more to draw I guess), the effect on the fps is reduced?
When the window has focus, the fps stays a constant 60fps with the extra draw load..
Hmm.. can messages somehow turn off vsync?

[Edited by - Interesting Dave on June 23, 2009 6:09:20 PM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this