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've played some games at cca 30 fps and some of them had low reaction time - cca 0.1sec. I hadn't knew why.

Now when I'm designing my framework for crossplatform game, I know why. Probably they've been preparing new frame during rendering the previous.

RENDER  1 | RENDER  2 | RENDER  3 | RENDER  4
PREPARE 2 | PREPARE 3 | PREPARE 4 | PREPARE 5

I see first frame when second frame is being rendered and third frame being prepared. If I react in that time to 1st frame it will result in forth frame. So it takes 3/FPS seconds to appear results. In 30 fps it would be 100ms, what is quite bad.

So i'm wondering what should I design my framework to response to user interaction quickly?

share|improve this question
4  
Please don't cross-post to SO, it dilutes the value of the question and answers and wastes peoples time. This is probably a more appropriate site, so I've flagged the SO version for closure. –  Josh Petrie Oct 29 '11 at 17:16
    
I think these days almost all games are preparing frames in parallel with rendering them, just by the fact that graphics drivers can buffer future frames. –  Kylotan Oct 30 '11 at 11:22
    
@JoshPetrie Why would i cross-post it to SO? It's not programming related, it has nothing to do with programming languages, libraries,... But it is about game code design. –  Miro Jul 1 '12 at 13:28
    
I agree, which is why I said you shouldn't (originally your post read: "Note: I've posted it also on StackOverflow.") and voted to close the (now-deleted, I believe) version of the question on SO. –  Josh Petrie Jul 1 '12 at 15:30
add comment

2 Answers

up vote 8 down vote accepted

For an in-depth study of latency in games, Mick West is the undisputed master. Read these two articles first, and it will make everything else make so much more sense.

There are two aspects to this. The first, which you've picked up on, is the latency between an instantaneous control input (e.g. a button press), and the time at which the user perceives the effects of that action. The firing of a gun is usually the best example of this as it's easy to measure. There are many contributing factors to this, most of which are completely out of your control. Worse, it's a cumulative effect, so if each stage is introducing a bit of latency, it can all mount up to lead to severe overall latency. Different types of latency you'll see:

  • display latency (how long between a frame being presented at the input and the pixels on the screen changing to reflect that frame)
  • GPU /sync latency (how long between you calling Present and the input being presented to the display, usually tied to framerate, e.g. at 30fps there may be anywhere from 0-32ms between calling Present and the next VSync where the GPU output would change)
  • buffering latency (you've pointed this one out - frames prepared based on the world state from previous frames because rendering takes so long it's more efficient to have the rendering being done while the next frame is being prepared)
  • processing latency (time between input being sampled, usually at the start of an update cycle, and the results of that input being reflected in the world state used by the rendering)
  • input latency (if your input devices don't immediately reflect the live state, it's possible your input sampling is actually based on the state some time ago. That's pretty rare nowadays, but depends on what input devices you're talking about)

Sadly, there aren't many good answers as to how to minimise display latency. The most obvious answer to display latency is don't buffer frames. The rest of the chain of latency is out of your control, but this one isn't. You can choose to render less, and forego maximising your GPU/CPU parallelism, in favour of reduced latency. The next obvious answer is: render at 60Hz instead of 30Hz. That will cut your sync latency to 16ms. Again, to achieve that, you'll either have to render less, or render smarter. If you are running at just over 60Hz most of the time, but occasionally drop down, then rather than live with the massive hit of dropping to 30Hz, you can turn off lock-to-VSync, and live with those horrible screen tearing artifacts when you do take too long to render. However none of those options are great if you also want to make best use of your rendering power, which is why pretty much every modern game engine you see will buffer frames, and most of which run at 30Hz.

The second aspect relates to latency as a result of your simulation. Imagine a character jump. The user presses the jump button at time 0. If the visual feedback for jumping was just that the entire screen flashed yellow, then the latency would be purely based on your display chain (input -> processing -> rendering -> presenting -> displaying). With minimal processing, at 60Hz, on a CRT with minimal display lag, you could in theory see the yellow screen in about 30-40ms after your button press (less than one 16ms frame for input -> processing -> render, present on the first VSync at 16ms sharp, then the CRT displays some time after that).

Now imagine more typical visual feedback: the character animates - winds up and jumps. How many frames of animation does the character go through before they are obviously jumping? If it's more than 2 or 3, the simulation will feel 'laggy', not because the input isn't being processed immediately, but because the results of the input take some time to become obvious in the visual feedback.

This leads us to one of the better ways to make your game feel more responsive: run your simulation at 60Hz (or higher if you can). Even if you can't simulate and render at 60Hz, simulate (and sample input) at 60Hz anyway, and render based on the interpolated game state at any given point. You cannot avoid display latency, it will always be there, even if you try to minimise it. By decoupling your input / simulation loop from the rendering, you can sample input more frequently, and get more responsiveness in your physics, etc. As to why this is better? Read Mick's final paragraph in the original article on responsiveness: it's not so much about the player's reaction to what they see, as it is the games speed of reaction to what the player is doing. At a higher simulation speed, the game will react to the player more quickly. But there are other reasons to like a higher frequency simulation as well. Physics especially likes a smaller time-step, because there are fewer collisions and other discrete events per time-step that need resolved.

One of the nice things about that is if you do have a render-heavy system, you can actually drop the render rate to 20Hz and make use of that time, without the simulation part having problems because of the long slow time-steps. Of course, a 20Hz rendering will only make the display latency problem worse, I just throw it out there as a possibility once you've shifted to a decoupled simulation/render system.

share|improve this answer
    
Is there anybody running a simulation at 60Hz? Most people seem to be running their simulation significantly less frequently than their rendering. –  Kylotan Oct 30 '11 at 21:02
    
@Kylotan, I actually run my physics loop at 200hz while rendering at 100hz. It makes a difference for high speed objects that cannot be interpolated between frames such as key framed animation of polygon objects that interact with the world. Using latest Bullet Physics. To my knowledge there is no downside to simulating faster than your rendering. –  NtscCobalt Oct 31 '11 at 5:27
    
@Kylotan I worked on a PS2 game where I had a flight simulation running at about 2000hz, because with the silly forces I was subjecting it to (ridiculous speeds, changing gravity fields, etc), it would go unstable at anything lower than that. But it was in a dedicated level where almost no other processing was going on, so we could afford it. Of course, the results of that processing was then fed down into our regular 30fps collision system, and then interpolated back up into 60fps for rendering. Complicated! –  Trevor Powell Oct 31 '11 at 9:48
    
@NtscCobalt, the only downside to simulating at that frequency I anticipated was the CPU cost because physics is often very expensive, even relative to rendering. I'm surprised people have the CPU time to do 200 or even 2000 physics updates a second when devs often begrudge having to spare more then 1% or 2% for audio or AI. –  Kylotan Oct 31 '11 at 11:19
    
@Kylotan, it really depends on the physics library and what you are looking for. With multi-core systems and multithreaded physics libraries you aren't using your full potential if you are only running on 1 thread. Most video sdks can't render from more than a single thread so you might as well be doing something with those additional cores. If you are aiming at desktop you can almost guarantee there is at least 2 cores if the machine is within a few years old. –  NtscCobalt Nov 2 '11 at 2:09
add comment

The most obvious thing to do is to make sure that you process input before doing rendering, and that it actually has an effect in the next rendered frame. If you're not careful you can get things in the wrong order in the game loop and delay the result by a frame or more, especially when there's a long chain of processing between cause and effect (e.g. key press->physics system->animation system->renderer).

That is generally easy to test for and fix. Breakpoint the game at the beginning of the render loop, hold down an input then resume the game in the debugger so it runs one frame. If you can't see any effect then something is probably not right.

The other thing to watch out for is that when you're GPU bound, D3D will buffer three frames worth of rendering. This enables for example two graphics cards to work on separate frames simultaneously, however if you've only got one card it's just adding latency. You can use queries to limit this latency, but you need to use a variable number to avoid SLI issues - see page 6 of this Nvidia pdf.

There are also other sources of latency that you can't control like delays caused by the Monitor / TV. CRTs generally have a frame or two less lag than LCDs for example. You might find http://www.anandtech.com/show/2803/7 interesting.

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.