🔒 Locked

Someone shoot me and/or windows

Started by Interesting Dave Jun 23, 2009 at 2:56 PM 5 replies 1.3k views

Original Post

Jun 23, 2009 at 2:56 PM

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.

Aardvajk

Jun 23, 2009 at 3:31 PM

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?

TheTroll

Jun 23, 2009 at 3:48 PM

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

Interesting Dave

Jun 23, 2009 at 4:09 PM

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}

empirical2

Jun 23, 2009 at 4:33 PM

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.

Interesting Dave

Jun 23, 2009 at 5:09 PM

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]

Zahlman

Jun 24, 2009 at 2:23 PM

You aren't perhaps missing a 'break;' in a switch on message type? :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.