Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm learning metro development with c++, DirectX, win8 CP, vs11 beta. I've come across some unexpected behavior:

Running the tutorial series ( Direct3D Tutorial Sample 1 ), and any sample or app for that matter, If I'm watching motion on the screen such as the cube slowly rotating, and I move the mouse, the object stops updating/rotating until I stop moving the mouse.

Here is a very short video of what I mean: http://www.screencast.com/t/cEHkVUaRcw

It even does this with the shooting sample game, which is very mouse intensive. It makes all the motion very jumpy.

I believe it has something to do with the system. I can interrupt the dispatcher from processing messages and it stops manifesting this behavior so it feels like the computer is so busy processing messages that it can't keep up with the rest of the updating. But this problem only started recently so I do not believe it is a problem with my computer's processing power.

Has anyone else experienced this and know how to resolve it or does anybody have an idea into why this is going on?

Here is the game loop code that MS ships with the sample.

while (!m_windowClosed)
{
    timer->Update();
    CoreWindow::GetForCurrentThread()->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessAllIfPresent);
    m_renderer->Update(timer->Total, timer->Delta);
    m_renderer->Render();
    m_renderer->Present(); // This call is synchronized to the display frame rate.
}

Thank you.

share|improve this question
    
It seems like whatever handles your mouse events either prevents or blocks the drawing routine from running. Be sure that events are handled but that drawing is still allowed to occur regardless. Without some code to see it's hard to tell. –  dennmat Apr 30 '12 at 14:58
    
good points. Thanks. I added the overall game loop code for perspective. I've not altered it from the way MS ships it in the sample. If I comment out the ProcessMessage line, the problem doesn't manifest. It is difficult to dive deeper into that method to see what's going on. Not sure how to. –  Steve H Apr 30 '12 at 15:21
add comment

4 Answers

up vote 1 down vote accepted

I finally found the reason for this behavior. I have a password manager app that loads at startup and is designed to automatically input username/password for my various websites.

When, in a metro app (or at least the DirectX ones), if the window core dispatcher is flagged to ProcessAllIfPresent, it spends time each frame loading and unloading one of the dlls associated with the password manager program.

Once I went to the task manager startup tab and disabled that password management app and closed it down, the behavior went away. Starting it back up brings the behavior right back.

I found it by monitoring the output window while running my DirectX app. I didn't notice it until I discovered "Simulator Debugger" mode where the output window was visible while running the app.

share|improve this answer
add comment

My guess would be the window's callback function, or that ProcessEvents function, has some code for handling mouse movement. When this callback gets messages, your "user" code will be halted while the message is being processed. Mouse movement could be a huge number of messages, hence completely stopping your application from updating.

I personally haven't seen this with simple mouse movement, but sooner or later (dragging the window around, for example) you would likely have encountered this. Edit: well, in a metro style app you might not be doing too much dragging of windows.

If you run your update/render loop in a separate thread from the message processing, it will be unaffected by the callback processing messages. You will need some form of synchronization though if you want to call device or devicecontext methods in reaction to some messages, as D3D doesn't take kindly to being called from multiple threads at once. (resizing your frame buffer after receiving a WM_SIZE message indicating the window has been moved or resized, for example)

share|improve this answer
add comment

Message processing should be very quick. What you need is a profiler to find out why it isn't.

Profile both the stationary mouse case and the rapidly moving mouse case and compare the two profiles to find out what's taking so long.

share|improve this answer
add comment

I saw this happen with another game project. The mouse messages were being immediately dispatched into a crappy UI library (libRocket). High- resolution gaming mice could generate hundreds of mouse events per frame, and the UI processing simply couldn't keep up.

The solution was to simply set a flag that the mouse had moved and then -- after the event loop -- signal to the UI library that the mouse moved and polling the OS for the current mouse position.

The gaming mice can be pretty ridiculous since they are geared for specs that make no technical sense, but many "l337 gamers" really have no idea how games or computers work and spend tons of money buying low-latency hardware that no game can even take advantage of. (even if you turn off vsync, for instance, the physics that drives all game logic is often fixed time step with only interpolation for high-fps graphics playback.)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.