What is the lowest amount of input lag achievable in a game?

[Squire Grooktook]

So, I've talked with a few people about this, but have gotten some conflicting answers.

My understanding is that, theoretically, a game only needs 1 frame to draw a new frame in which an input entered on the previous frame is translated into an action (the actual time this represents varies depending on what the games fps is). Additional lag should come (as I understand it) from controllers and the screen.

Since (again, as I understand it) most wired controllers have 1 ms or less delay (?), and CRT's and some types of monitors also can achieve 1 ms delay or less, that means that the lowest possible input lag should be 1 frame (that is, the next frame the game draws in which the action takes place) + 1 or 2 ms?

A frame is 16-17 ms at 60 fps, so that would be like 17-19 ms at 60 fps? Is this true?

[Obiwanshinobi]

Keep in mind many computer games run at 100+ fps easily and most working PC CRTs can refresh at 100-120 Hz (at least in lower resolutions). I played the first Ys Chronicles at 100 fps (v-synced, otherwise it wouldn't run properly) and the second - at 120, in which case I believe most lag came from the USB controller. I guess a keyboard hooked up hardware port would be the fastest, but I've never felt any need to go there.
I also gather some car games calculate their physics at faster rate than graphical update (but of course you won't see the outcome before they draw the picture). Then I'm darn sure some point & click games update vector graphics slower than cursor (almost certainly Torchlight and I suspect so does RE4 Wii Edition). I read Diablo 3 on this-gen consoles sometimes renders the enemies choppier than the playable dude, meaning it's not QUITE 60 fps all the time and the perceived response times are somewhat fake. Doesn't NiGHTS on Saturn update Nights at different rate than terrain? What does a frame even mean then?

[Squire Grooktook]

^^^Yes, come to think of it, I remember reading some lag tests on different usb connectors, and some of them had noticeable differences. Which conflicts with the "wired controllers have negligible (1 ms or less) lag" which I had read.

re: fps: Keep in mind though, what I think most relevent is the pure delay added on top of the frame being rendered/drawn. If you were to press a button to move on frame zero, whilst a bullet is moving toward you, and the next frame is drawn with both the player and the bullet having moved, then I think that's fine regardless of how long it took to draw that frame. The main concern, for me, is how much additional lag time is added on top of that base 1 frame. Some people have told me that 3 frames is the absolute minimum that can be reached in any game at 60 fps, but like I said, I've gotten some conflicting answers on that.

[trap15]

Depends on a whole lot of things. The lowest amount of lag technically possible is actually 0 frames, but at that point you're actually racing the video sync: if you input immediately before the mainloop runs the input check, your input will be 'instant' (0F); if you input right after the input check, it'll be 1F.

[Squire Grooktook]

Depends on a whole lot of things. The lowest amount of lag technically possible is actually 0 frames, but at that point you're actually racing the video sync: if you input immediately before the mainloop runs the input check, your input will be 'instant' (0F); if you input right after the input check, it'll be 1F.

Yeah I can believe that.

Perhaps this is more a question of hardware. As BZPBanshee mentioned in our convo about this a few weeks ago, "most of the time it's not so much about the game loop as what the input has to go through to reach the game loop".

This was kind of provoked again by the link Ed posted to DisplayLag.com. These are actually kind of staggering and depressing to me. I mean I knew SF4 wasn't the fastest game in the world but 5 frames holy shit.

Am I totally wrong in my understanding that you can get 1 ms or less from certain controllers, and 1 ms or less from certain monitors (including CRT's obviously, but I believe others can reach about 1 ms too?) resulting in 1 frame or less lag, or are consoles just super laggy compared to computers? Or are there other factors at work? I really don't know what to make of some of those stats.

[Obiwanshinobi]

Eurogamer's Digital Foundry measures input delay this way: they set up a 60 fps camera and a diode flashing when the controller's button gets pressed next to a CRT. I can see how a 120 fps camera would make for more exact measurements at least in console games, but are such cameras even available on the market?

[trap15]

For PCs, the equation is extremely complicated. Factors other than the display that I am aware of (there may be more):

• How often your device's USB controller polls for input
• How often your OS polls your input devices for their inputs
• How in-phase the OS and device poll rates are
• How in-phase your device poll rate is with the display rate
• Where and when the game polls input relative to game logic
• Whether the OS adds any additional display buffering
• Whether the game adds any additional display buffering
• Whether the graphics card adds any additional display buffering
• How in-phase the game's input poll rate is with the OS poll rate
• Whether the OS or game adds any additional input buffering

These factors can change between two given machines and/or two given games, meaning there really is no one-size-fits-all answer to PC game input lag.

[Squire Grooktook]

For PCs, the equation is extremely complicated. Factors other than the display that I am aware of (there may be more):

• How often your device's USB controller polls for input
• How often your OS polls your input devices for their inputs
• How in-phase the OS and device poll rates are
• How in-phase your device poll rate is with the display rate
• Where and when the game polls input relative to game logic
• Whether the OS adds any additional display buffering
• Whether the game adds any additional display buffering
• Whether the graphics card adds any additional display buffering
• How in-phase the game's input poll rate is with the OS poll rate
• Whether the OS or game adds any additional input buffering

These factors can change between two given machines and/or two given games, meaning there really is no one-size-fits-all answer to PC game input lag.

Yeah, makes sense.

So with all that in mind, what (in your opinion) is the best possible latency that can realistically be achieved. Ie well programmed game to minimize lag, crt/lowest lag monitor, best controller/usb connector for lag, etc. Would it still be within your original value of 0-1 frame, or is that not realistic given the reality of current controller/screen/other factor latency.

[trap15]

I think an optimized setup can probably get 2 frames minimum, but don't quote me on that.

[Obiwanshinobi]

I wonder if hardware mouse and keyboard ports really detect input faster than USB (say, on my particular system), or they only save CPU cycles (which may technically improve the all around performance, but not necessarily give any more direct advantage). Well, with my keyboard there's absolutely no ghosting via hardware, but that's a different story altogether.
Also, do modern PCs even have those hardware ports for control devices?

[Squire Grooktook]

I think an optimized setup can probably get 2 frames minimum, but don't quote me on that.

I see, thanks. Let me know if you ever find out if a lower number is possible.

[nasty_wolverine]

I think an optimized setup can probably get 2 frames minimum, but don't quote me on that.

one frame is possible, but depends on:
- what gpu settings are used. (maximum single display high performance mode, with maximum prerendered frames set to one)
- where and how input is polled in the game loop (ideally at the start of the frame)
- disable aero (if in windowed mode, windows with aero enabled usually vsyncs the whole game/window whether you like it or not during compositing which may add lag)

even then its highly likely that its not a constant one frame. but you should overall average very close to one frame.

[Squire Grooktook]

I think an optimized setup can probably get 2 frames minimum, but don't quote me on that.

one frame is possible, but depends on:
- what gpu settings are used. (maximum single display high performance mode, with maximum prerendered frames set to one)
- where and how input is polled in the game loop (ideally at the start of the frame)
- disable aero (if in windowed mode, windows with aero enabled usually vsyncs the whole game/window whether you like it or not during compositing which may add lag)

even then its highly likely that its not a constant one frame. but you should overall average very close to one frame.

When above that average, would that be like 1 frame + a few extra ms. IE 1 and 1/2 frames? 'Cause that's what I was originally thinking. I suspected a little more then 1 frame due to controller/display/other factors latency, but I expected/hoped that in best case scenario it would be less then a full second frame's worth?

I heard someone say that they managed to attain 30-35 ms lag on a screen that had 13 frames of lag, based on a 210 fps camera recording test. That comes out to 1 frame (17 ms) to 1 frame and 5 ms if played on a lagless monitor. I don't usually trust random people on the internet on this sort of thing, but that does back up your claim.

[Squire Grooktook]

Did a bit more research into some of the other topics mentioned here.

Based on lag tests comparing multiple drivers, it seems that drivers can make a huge difference. A full frame or more by themselves! Definitely can't discount the quality of a driver/usb device as a factor now. This kind of blows the "wired controllers have sub 1 ms lag" out of the water, or at least they don't universally lack lag.

Also I looked into the crt eurogamer test that Obiwanshinobi mentioned. It says the guy who conducted the test is a game developer, and he concluded from the tests that 3 frames was the minimum latency a game could be played with. Mike Zaimont, lead programmer of Skullgirls/Lab Zero said the same thing on the Skullgirls website, and again when I asked him about it. So that's two developers who say 3 is the minimum...but both of them seem to be focused on consoles. Curiously, I've yet to see any camera based lag tests for pc's, everything seems to be focused on consoles. I'm still not totally sure what to believe here.

[ED-057]

I wonder if hardware mouse and keyboard ports really detect input faster than USB

On PS/2 keyboards and mice (or AT and RS232) it would take about 1ms for the serial data to be transferred, then it causes a CPU interrupt. A DOS game would probably have control of the IRQ handler and would get that input immediately thereafter. I don't know how another OS would handle it...

[Squire Grooktook]

A DOS game would probably have control of the IRQ handler and would get that input immediately thereafter. I don't know how another OS would handle it...

The mention of DOS brings up an interesting question, how would ancient, cartridge based consoles like Nes/Snes/Mega Drive compare to modern Consoles and PC's in terms of lag? Would they be faster due to having less stuff "going on" in the architecture and being more focused on the game, or slower due to being more compressed and low tech? Or the same?

Maybe it's just me, but I find this to be a pretty interesting topic.

[trap15]

Any 2D console with a line-based renderer (p.much everything until the 3D consoles) has 0 native lag.

[Squire Grooktook]

Any 2D console with a line-based renderer (p.much everything until the 3D consoles) has 0 native lag.

Interesting, does that include controller response/input processing time/other factors? If so, that's pretty cool.

I think I have an old CRT lying around somewhere (I think, unless it was thrown out or something lol). I should do some tests to see how the 3 major old consoles do one of these days.

[trap15]

Oh, actually it doesn't; NES and SNES have automatic input polling at 60hz, though I don't know where the phase is relative to the display, so that's a 1 frame minimum, not 0. SMS and Mega Drive are manually polled, so that has a 0 frame minimum. Don't know any others off the top of my head.

[Squire Grooktook]

^^^Thanks for the info.

Thinking about 2d games a bit more, it occurs to me that one of the few that's been tested a ton is Super Street Fighter 2 Turbo. The general consensus seems to be that it has 4-ish frames of native lag on the pcb. Which is quite a bit extra if old 2d technology can have 0 native lag. But then it seems like a lot of arcade games have a great deal of different lag times, from what I've heard. Guess it depends on the architecture.

If 1 frame is a realistically achievable number on a Super Nes though, that means that (depending on how they ported or programmed it, obviously), the SNES version of SF2 might actually be the most responsive

Also I did manage to track down a camera based lag test of a commodore 64 custom program, which had 1 frame or less of lag. So I guess that kinda maybe debunks the "3 frames is the lowest latency that can be achieved in gameplay" claim.

*EDIT*

I think this what Mike Z was telling me earlier, in regards to the "3 frame minimum"

http://www.gamasutra.com/view/feature/1 ... php?page=1

Not sure if true or not. *edit 2* Okay, I'm dumb, and I think I got this figured out.

The older consoles (snes, mega drive, etc.) and systems we mentioned don't have a real gpu, do they? That relates back to the line render talk, I think. Hence the explanation used above (that the gpu rendering has to have its own frame) shouldn't be universal for all game programming.

[e_tank]

writing this on a tablet and getting ready for bed so i'll keep this response brief so if the following isnt clear will elaborate later. when talking about input response frame of reference is important, for instance what trap15 refers to as 0 frame response others might call 1 frame response, 1 frame (1 / 60 s for a game that steps logic and gfx at 60 fps) being the minimum frame response time from when input is made and caught to when the frame that shows the response has been completely scanned out on the display. using the latter def sf2t has a min resp time of 4 frames (or 3 frames in the method trap15 is using). So on avg sf2t has a response time of 4.5 frames worth of time since 4 is the min meaning the input was made and caught right b4 the game checked. for ref most games on pre double buffered 3d hardware (8 & 16 bit systems) had a min resp time of 2 frames,games like sf use a bit of a buffer for the multiple input specials u execute.

I haven't looked at the link re 3 frame min, will look later, but he's prob referring to 3d double buffered hardware (psx sat and up) where the min resp time is typically 3 frames (which actually / typically isn't the lowest u can get, but would require some bit of hackery)

[Ed Oscuro]

@ Squire: I think that's just an arbitrary newer definition. Older consoles (like the SMS and even the Atari 2600) certainly do have a "graphics processing unit" in a basic sense (from what I've read, the SMS graphics chip offers at least graphics modes and primitives, and the Atari VCS circuitry provides something like graphics primitives for the "ball," "paddle" and some other things). The "GPU" name is just newer, and I don't think anybody defined it specifically so that simpler forms of graphics processors were excluded - it just tends not to be used in connection with those. Modern GPUs have registers and buffers for intermediate results, to be altered later.

Speculation ahoy: I believe many modern effects are unavoidably processing results stored in a frame buffer, including AA, anisotropic filtering, and certain other "effects" filters. (A "sepia tone" filter might not need to process an entire buffer, but it does seem like a simple way of accomplishing it. Likewise with a "noise" filter - sure you could do it with a particle system like a lens flare, but...)

One of the things mentioned in connection to reducing latency for VR is eliminating full screen effects, so that per-scanline rendering can be achieved without the use of a frame buffer.

I'm sure motion blur uses multiple frames to create a new frame. I'm not sure what its impacts are on lag, though.

In practical terms, all that should matter is keeping render times down below your desired framerate, and avoiding any effects that frames previously scanned out (if there are any).

[Squire Grooktook]

writing this on a tablet and getting ready for bed so i'll keep this response brief so if the following isnt clear will elaborate later. when talking about input response frame of reference is important, for instance what trap15 refers to as 0 frame response others might call 1 frame response, 1 frame (1 / 60 s for a game that steps logic and gfx at 60 fps) being the minimum frame response time from when input is made and caught to when the frame that shows the response has been completely scanned out on the display.

I think what Trap means, is that if an input is made and reaches the game loop during the part of the frame that checks for inputs, then the update will be made within that frame (0). If it's missed, then you'd indeed need to wait until the next frame (1) for an action.

@ Squire: I think that's just an arbitrary newer definition. Older consoles (like the SMS and even the Atari 2600) certainly do have a "graphics processing unit" in a basic sense.

True, but I think the discrepancy between the more simple 2d consoles gpu and modern systems gpu is probably explains the supposed "3 frame limit", especially since that article emphasizes the role of rendering as part of it, and Trap says that the old line rendering method does not require a frame of its own. I'm still not entirely convinced that the explanation above is a hard limit for modern games, but if that's the general way modern 3d oriented gpus work, then that would explain why most console modern games seem to be 3-4 frames or above.

[Ed Oscuro]

Naturally, this isn't meant to be very revealing about the inner workings of these systems, since this is just a question of terminology and not the actual workings of the devices. I associate the term "GPU" with systems that have a more general-purpose structure than the simpler graphics chips of older systems; for a rough date, nVidia started using the term in reference to its all-in-one (2D and 3D) graphics cards like the GeForce 256 (and of course ATI used a different name for essentially the same thing). There is a discussion of this here.

Nevertheless, I have tried to make clear that I think that frame buffers - which allow the storage and manipulation of an entire frame, as opposed to per scanline methods - is necessary for implementing many new graphics algorithms but also the cause of some laggy graphics methods.

But, of course, as other people pointed out, the graphics subsystem is just that - a process which happens after other systems are done (input polling, Windows-style messaging, core logic). Even before the appearance of bolt-on consumer graphics processors, the focus has shifted to creating more balanced systems which are both "responsive" but also pack the most punch in frames per second and detail - not real-time systems.

I'm also a bit confused by your statement "during the part of the frame that checks for inputs." Probably just a typo, but the frame is just output, and provides our marker for determining when an input has been translated into visual output - it is, of course, the part of the core logic loop where the checking happens. The frame, by itself, is basically the canvas on which the program etches its designs.

[Squire Grooktook]

I'm also a bit confused by your statement "during the part of the frame that checks for inputs." Probably just a typo, but the frame is just output, and provides our marker for determining when an input has been translated into visual output - it is, of course, the part of the core logic loop where the checking happens. The frame, by itself, is basically the canvas on which the program etches its designs.

Sorry, by frame, I meant the game loop. Although in most conversations I've participated, a frame is often used interchangeably to mean a unit of time or an update of the game loop. IE 60 fps = game updates 60 times in a second = 60 frames created based on those updates.

[Ed Oscuro]

Like I said, that is just a marker for measuring how much time has passed until an input is reflected in game output. It'd be kind of like saying that you put gas in the speedometer or in the MPH to make the car go vroom - no, input goes in the engine!

But this is just being pedantic; I'm sure we're in agreement about what's going on and, like I said, it's just one word here.

[ED-057]

Just a wild guess, but in the case of SSF2T the lag could be a side effect of the complex input parsing that it does. For example, if the player just pressed UP, does that mean their character should immediately jump? or did they only press UP as part of a 360 degree sweep to execute one of Zangief's moves? (with the rest of the sequence still being yet to come...)

[e_tank]

I think what Trap means, is that if an input is made and reaches the game loop during the part of the frame that checks for inputs, then the update will be made within that frame (0). If it's missed, then you'd indeed need to wait until the next frame (1) for an action.

correct, however you're still missing my point. you're assuming everyone's definition of "this game has an X frame response time" is the same. you were told sf2 turbo has a response time of 4 frames, but the source you got that from is using a different definition than the one trap15 is using, which by his definition it would be 3 frames. both are correct, but w/o a precise def / frame of reference you wouldn't know this.

the former is going by the definition laid out by both Mick West (the article you linked to prior) and Christer Ericson (a follow up to MWest's article by one of his former colleagues), which is defined by time (in units of frames) from when the input is received to when the frame that shows said input is completely scanned out to the display. trap15's definition is starting from frame 0 (and assuming a minimum response time), what is the first frame you will see the result of an input on.

now if that didn't make sense consider the following "game" loop running at 60 fps on raster line (pre double frame buffered) hardware (such as famicom, sms, megadrive, sfc, etc) connected to a crt tv.

Code: Select all

while not done:
  wait_for_vblank()
  read_input()
  if any_button_is_held()
    set_bkg_color_red()
  else
    set_bkg_color_blue()

by trap15's definition this program has a 0 frame minimum response time, by Mick West's and Christer Ericson's definition this program has a 1 frame (1 / 60 s) minimum response time. see what i'm saying now?

edit: ugh, stupid tags, took like 4 fucking edits in a row to get it formatted right, grrr