Archived

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

Input lag in DirectX

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

I am sure this has been asked many times before but I am unable to find and relevent links to help me out. What I am experiencing is a kind of input "lag" when running certain Direct3D apps that I program. It is especially apparent in windowed mode but also occurs in fullscreen mode. (I am using standard win32 input, not DirectInput) I have read in other places that this is a known problem but have been unable to find any solutions to it. Any ideas? anyone? (Sorry that I cannot post a link to a demo, but this project is part of a major program)

Share this post


Link to post
Share on other sites
Around the place where you Present() [or Flip()/Blt() in older versions], try putting a Lock on the frame buffer immediately followed by an UnLock...

if that fixes it, then you''re probably not using WHQL certified drivers - contact the company that made the driver (assuming you''re not using a "leaked" driver) and politely ask them to stop buffering up more frames than they''re allowed to.

Some drivers have user settings too to buffer up frames.


Most modern 3d graphics chip drivers will buffer up data you send to it and the chip then renders from this at its own pace. This prevents the application from stalling until the chip. WHQL certified drivers aren''t allowed to store more than 1.5 frames worth of data (IIRC).

However some drivers, particularly the "leaked" ones buffer say 100 frames worth of data. The original reason many used to do it is to cheat on benchmarks, because if the driver is buffering up all the data between 100 Present() calls, then the frame rate is going to be simply however long it takes to store the data used for those frames rather than the time it actually takes to render them.

The result for an app running on one of these drivers is any input is ~100 frames behind the visual update.

The IHVs do have one excuse, and that''s that most apps starve the chip of data so they buffer up more to try and increase parallelism. Fine for non-interactive "sales" demos...


There are of course other causes of input lagging such as a bug in your input code, Windows message loop issues, poor use of threads (e.g. the mad people who thing setting the process/thread priority realtime is going to help in some way).


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites