It is common knowledge that if the framerate of a game is over 25-30 fps, we humans perceive it as running smoothly. More is better, but if it is above that, it at least doesn't lag.

I have been looking for research as to how long a mouse input can take to reach the screen, and still feel instantaneous to the average person, for example. I'm sure it may vary a little bit, from person to person, but I'm sure we all have a limit on how fast anyone can perceive small time differences between events.

I'm interested in this because I want to try and statically update the data for my game, for example every 0.05 seconds, instead of as soon as I get a new input. This will save computer power, while still not causing delay in the game.

What is an acceptable input delay?

  • 7
    \$\begingroup\$ What makes you think this would save an appreciable amount of power? What are your benchmarks for this like? \$\endgroup\$
    – user1430
    Jul 23 '13 at 15:13
  • 6
    \$\begingroup\$ Sounds like an extreme case of premature optimization. \$\endgroup\$
    – House
    Jul 23 '13 at 16:41
  • 4
    \$\begingroup\$ That's not a benchmark, that's a theory, and it's not really well-based in reality. I think you're wasting your time trying save computational power here, which leads me to wonder what the actual problem you are trying to solve is? \$\endgroup\$
    – user1430
    Jul 23 '13 at 17:13
  • 1
    \$\begingroup\$ @sarahm: Input lag/latency is always acceptable, it's just a question of how much lag is acceptable. A Quake-style FPS certainly has a lower tolerance than a Tycoon game, yes, but the input latency will never be 0. Intentionally adding extra latency like the OP is asking though should certainly be avoided for most types of games, though. \$\endgroup\$ Jul 23 '13 at 18:12
  • 2
    \$\begingroup\$ For touch screens, Microsoft recently made a research. It was about when a box, dragged by a finger, seems to be moved without delay. It was very short time frame, when I remember correctly around 2ms. I think this would be a great user experience. So as you can see, faster is better due to very short time frames. Anyway, for most monitors 60Hz is still standard and faster input handling won't be visible to the player in all cases where the input doesn't change future movements. \$\endgroup\$
    – danijar
    Jul 23 '13 at 19:31

This is essentially the same (update your input around 30+ times per second). If you update less often, you'll experience "input lag."

This is even more noticeable when a game uses a hardware cursor and has some icon following the cursor (such as during drag-and-drop operations). You'll most likely see the icon lagging behind.

In the end this really depends on how often you update your game logic. There's no real need to update inputs if you don't handle game logic anyway (unless we're talking about something like a mouse cursor). But either way, I'd pick the bigger value of your frame rate and your game update rate for inputs. If the update rate is higher, you'll need it for fast reactions, if your frame rate is higher you'll need it to avoid visible lag.

Also, as a note regarding power consumption: querying inputs x times per second will most likely cause more power consumption than simply reacting to input happening. Always think about situations where no input happens.

  • 1
    \$\begingroup\$ Nice side note! Very important distinction to make. Don't poll for events when you don't expect them to happen constantly. \$\endgroup\$ Jul 23 '13 at 15:45
  • 2
    \$\begingroup\$ There are libraries notably XNA that do not allow for event driven input. \$\endgroup\$ Jul 23 '13 at 16:03

I'm not sure there is much in the way of formal research into this area. You could perhaps posit some numbers based on an understanding of human reaction times (which has had extensive academic study), although note that this and what you are talking about are not the same thing. The acceptable delay between making a motion with a mouse and seeing a result is almost certainly much smaller than the time it would take a human to react to something displayed on the screen with the mouse.

This is, in fact, an important consideration. While in some cases it may be acceptable to only process new input around 30 frames-per-second, as with rendering (the idea being that that's the persistence of vision interval anyway), you could in some implementations of this approach have too much round-trip delay between an action happening on the screen and the player's reactionary input getting back into the game logic.

In the real world, usability tests and general playtesting usually catches this kind of thing (especially for games that also have a networking component and can have the additional network round-trip delay). Based on feedback from playtesters about how "laggy" or "floaty" your controls feel, you will adjust your input timing or optimize the round-trips to achieve better results.

Consequently I think it's a bad idea (premature optimization, in a way, as Byte56 commented) to focus on achieving a theoretical ideal input delay on the misguided attempt that you will "reduce computer power." You almost certainly won't, first of all, and you'll be solving the problem with the wrong constraints and flexibility areas in mind.

  • \$\begingroup\$ Yes, human reaction times are not the same thing as human perception times. I don't have numbers but I wouldn't be surprised if the difference between reaction and perception was more than a factor of 20 (with lots of variability). What we really should be looking for is the frame rate at which additional FPS is not even perceived. I haven't personally tried an 120 Hz monitor, but due to the fact that they are manufactured and sold, should probably be looked into \$\endgroup\$
    – bobobobo
    Jul 23 '13 at 18:18
  • \$\begingroup\$ Yh it migth be premature optimization :) im not going to implement it just yet anyway. I just like to play with ideas, I meen you wont achive any progress in the long run if you never think outside the box. Also it give you other perspectives and inputs that will help you grow :) \$\endgroup\$ Jul 24 '13 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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