Skip to main content
GameDev.net gamedev.net
🔒 Locked

Controller latency

Started by Ezbez Jan 7, 2010 at 8:50 AM 3 replies 3.3k views
Original Post
Ezbez
Ezbez
This is a decent article trying to quantify a not-uncommon problem with video games; unresponsive or laggy controls. I like that this issue is being examined and measured and I hope that game companies will try to measure this before releasing their games in the future. However, the article made some claims I wasn't sure of. Namely, they state that 67ms is the minimum latency for a 60fps game, and 100ms for a 30fps game. For example, this basic game loop: 
while running:
    handle_inputs()
    draw_frame()
    cap_framerate_to_60()
Reading the inputs happens immediately before drawing the frame. If the button was pressed immediately before handle_inputs polls for events (and ignoring inherent latency in hardware or operating system), the latency is only however long it takes to run handle_inputs() and draw_frame() (and for the monitor to refresh). There's no reason that would be 67ms! For a 60fps game, it would be at most 16.7ms. Even if the input was given shortly after handle_inputs polls for inputs, it still only takes the time of at most 2 handle_inputs(), two draw_frames() and a cap_framerate_to_60(), which will be at most 33ms. I'd be comfortable adding in another frame or maybe the two that the article gives based on latency from hardware and operating system, but I see no reason to give this 67ms as some hard minimum. A game with a quick update and draw functions (which is capped at 60fps by v-sync) could have almost immediate responses with less than a frame of latency, depending on when in the loop you pressed the button. So how do they come up with such set-in-stone numbers? Is there some justification for the additional 33ms of hardware and other latency inherent outside of the game or does that number just come from thin air? Or am I missing something in my analysis of the minimum latency? Furthermore, I find that subtracting out the response time of the screen is a little naive - the human mind still sees that as part of the latency and developers should be developing for what people are playing on, not some theoretical perfect monitor.
oliii
oliii
You have to add the time it takes for the image to be create in-memory, to being rendered on your LCD. Basically, hardware latency. This also includes your joypad latency, from the moment you press the button to the moment the driver records that change. Although that is most likely negligeable nowadays.
Everything is better with Metal.
Buckeye
Buckeye
Quote:
am I missing something in my analysis of the minimum latency?

I'm certainly not an expert on controllers or latency testing. And I'm not defending your analysis or the analysis presented in the article you cited. Just responding to your question.

I think you're missing an understanding in the scientific method. That method calls for the collection of data for observable phenomena using reproducible measurements, forming a hypothesis and testing that hypothesis. The article describes the method used to gather data, along with consideration of possible sources of error. I don't think it went so far as to form a hypothesis.

So, with regard to the scientific method, if you don't believe the results, you can't just dismiss them by saying "I see no reason.." If you want to challenge the reported result, a better approach would be to challenge the method, not the results. That would normally involve pointing out such things as sources of error that were considered incorrectly or missed, math errors, etc. You only make the statement of what latency you'd be comfortable with, without presenting any counter-arguments.
Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly. You don't forget how to play when you grow old; you grow old when you forget how to play.
Ezbez
Ezbez
I wasn't challenging their measurements (except for in my last paragraph, which was rather tangential). In fact, I like that this is being measured. What I don't like is this statement:

Quote:
The lowest latencies a video game can have is 50ms (three frames) - the PS3 XMB runs at this rate, but few games reach it.


Which I just realized is slightly different from what I was arguing against: 50ms not 67ms.

My problem being that two frames is the absolute minimum without any hardware or operating system latency, so I wanted to know why they add an additional frame to their time. Clearly the answer is the other latency which I shoved under the rug in my post, but I want some justification as to why they put his specific number on the other latency.

For example, here's how I see it:
For convenience, let's define "hardware latency" as all the latency between the button press and the event reaching the program (so this includes the OS, the hardware, etc.). With this we get the maximum latency occurs when I button is pressed one hardware latency length before the program polls for events (ie. the press just barely misses an event poll). This means we wait one hardware latency, then one handle_events, one draw_frame, one cap_framerate_to_60, and then a new frame of one handle_events, and one draw_frame. Clearly this means the minimum maximum latency* is at most hardware latency plus two frame lengths.

Since they assert that latency must be at least 50ms, hardware latency must be at least 16.7ms. While I'm sure this is reasonable, they give no justification for that number! Furthermore, they give 100ms for a 30fps game. That means a hardware latency of 33ms - but why on earth is the hardware latency dependent upon the frame rate of the game? So either they're wrong about this "three frame" thing or else I'm wrong about my "hardware latency + two frames" thing. Where's the mistake?


*"minimum maximum latency" meaning the lower boundary for the longest a player might have to wait for the results. No game can guarantee results faster than this amount, though individual results may take less time depending on when they fall in the frame.
Antheus
Antheus
It's Slashdot, but a relevant read as well.

Code itself is not the problem here, the latency measured in this type of tests comes from both, the input controller (in some cases, X-Box controller can introduce up to 20ms latency), the double/triple buffering coming from the way the graphics APIs work, as well as LCD displays (which apparently add 2-3 frames of latency).

Quote:
For convenience, let's define "hardware latency" as all the latency between the button press and the event reaching the program (so this includes the OS, the hardware, etc.).


Let's not.

Latency, as it matters, and as it applies to SAS (aka simulator syndrome), is the time from brain deciding on decision, sending impulse to finger, signal travelling through hardware, and result being interpreted by brain from the generated image on screen.

In practical terms, the approximation of recoding finger movement or button press and timing how long it takes for that action to display on screen is adequate.

This is the important latency. Majority of latency today comes from the time after the image has been generated, and after the input has been long processed.

Quote:
but why on earth is the hardware latency dependent upon the frame rate of the game?


Aliasing.

This type of simulations are discrete. In signal theory, systems with feedback need to take into consideration potentially catastrophic effects of aliasing (shuttle almost crashed during landing on test flight for similar problems).

I'm not in the mood for double checking the numbers here, but yes, latency of such feedback loop is affected by sampling rate.

Topic Locked

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

Sign in to reply to this topic.