for maximum responsiveness, it seems you must render after every update, and before each input.

can anyone think of an example that doesn't do this without being less responsive?

you have to render before each input, so the user knows whats going on, so they can respond to the situation.

you have to get input before or during each update, to update the player entity.

and you have to render after each update to display the results of user input (and update in general) in as timely a manner as possible.

so for maximum responsiveness, i don't see how this could be avoided.

can anybody think of anything that would/could be different, but not less responsive?

i can't think of anything that would not be less responsive.

You're overthinking this.

>> You're overthinking this.

Let me analogize this: You're suddenly asking if it's possible to make a car more efficient by removing the wheels.

You can play around with the loop, but there's no reason to. It's already possible to surpass human limitations for responsiveness. If you're handling input sanely and your frame rate is high enough that the player can see what's happening then the only really good way to screw up responsiveness is to render several frames behind or possibly to just have a crappy control layout. Control issues are usually related to poor game design or implementation issues with things like colliders not matching models or sprites. Networking tricks can also cause trouble if they're implemented incorrectly, but these are all cases where the output is not correctly representing the game state rather than cases where the rendering or input is not being handled fast enough.

At 60 FPS the game is presenting you information every 16ms or so.

Measure your reaction time here:

http://www.humanbenchmark.com/tests/reactiontime

Even if you float a frame (so that the CPU and GPU can work better in tandem) you only lose a little temporal fidelity. Stretching beyond one frame becomes a timing issue, but 0.016 seconds is barely even detectable, especially for fast moving objects.

Moreover, you're talking about a 3-stage process that loops. Your options are limited here:

A input

B update

C render

Naively:

ABC

ACB

BAC

BCA

CAB

CBA

But then when you consider that they're looping:

ABC == BCA == CAB

ACB == CBA == BAC

You've only got two options. Treating rendering as the divider you have input-update or update-input.

If you're polling then default to polling before updating because it makes sense to respond to input when you have it. If you're on an architecture that will delay on polling then you may consider moving it to after updating depending on how much time your GPU is taking compared to how much time the CPU takes.

On the other hand, if your input is handled by something similar to messaging then you don't even have to mess with it as updating includes processing queued inputs.

Regardless, even if you poll in the 'wrong' order you shouldn't be able to detect the difference without instrumentation.

tl;dr - If you want your game to feel responsive focus on precise collision and well designed character reactions instead.

My monitor can only display images at 60Hz, but I can run my sim loop at 600Hz. That means I can render once for every 10 updates, and the user is still getting an uber-responsive experience.

If I poll input once per 10 updates, the user probably won't know - it will still feel good... but if I poll input for every update, it will reduce the input latency by approx 0ms to 16ms, making it feel very slightly more responsive.

>>>> can anyone think of an example that doesn't do this without being less responsive?

>> A game running at 144hz with a 2 frame render lag (~7 ms per frame, or 14ms latency with lag) is still more responsive than a 60hz game (~16ms latency).

that sounds like one right there to me.

thanks all!

In your other thread you brought up destiny and their simultaneous update/drawing routines and how this will increase latency. This isn't necessarily true and becomes obvious once we draw some timelines.

Let's say we've got three CPU tasks in a frame, with these costs, which must occur in this serial order:
Poll Inputs: 1ms
Update Simulation: 15ms
Draw Scene: 17ms

Single threaded:

        0ms      1ms        16ms     33ms     34ms       49ms     66ms
Core1:  | Poll#1 | Update#1 | Draw#1 | Poll#2 | Update#2 | Draw#2 |

Dual threaded, no buffering / pipelining:

        0ms      1ms        16ms     33ms     34ms       49ms     66ms
Core1:  | Poll#1 | Update#1 | Idle   | Poll#2 | Update#2 | Idle   |
Core2:  | Idle              | Draw#1 | Idle              | Draw#2 |

Dual threaded, pipelined:

        0ms      1ms        16ms     17ms       32ms   33ms
Core1:  | Poll#1 | Update#1 | Poll#2 | Update#2 | Idle | Poll#3...
        0ms                 16ms                       33ms       50ms
Core2:  | Idle              | Draw#1                   | Draw#2   |

Single-threaded, this takes 66ms for two frames.
Putting draw and update onto their own threads, but enforcing mutual exclusion still takes 66ms for two frames.
Running Update and Draw in parallel, by pipelining two frames together, reduces the critical path to 50ms for two frames if you include the pipeline warmup time. Once the pipeline is warmed up, it's actually just 34ms per two frames from that point onwards!

There's still no extra latency for the user -- the path from input polling to finished drawing is 33ms in all three situations.

The only difference is that first two options pump frames at ~30Hz, while the third option pumps frames at ~59Hz - so it's increased framerate while leaving input latency exactly the same as it was before.

Now, extending this. Let's say that your Draw cost is still 17ms, but your Update cost is only 2ms. If we pipeline this as above, then the critical path goes through the Draw tasks, so the best framerate we can achieve is still ~59Hz as above.

So, seeing that our user is only able to perceive the game world at 59Hz... you could argue that polling any faster than this is not required. We can then use the exact same timeline as above, but replace the |Update#N| block with |Update[#N - #N+8)| , and replace Draw#1/Draw#2 with Draw#8/Draw#16 - i.e. we do 8 updates per poll/draw.

If you accept the argument that there's no need to poll faster than the drawing rate, then this will be just as responsive as before, even though we're "dropping" seven out of eight frames :)

>> If you accept the argument that there's no need to poll faster than the drawing rate

assuming you update no faster than you poll or render.

just cause you can only draw the screen once every 8 games turns doesn't mean you should let the computer move every turn and only let the user move every 8 game turns.

you have to preserve the fair play of "its my turn, ok, now its your turn, ok now its my turn again."

"i cant draw fast enough to show you whats going on - so you don't get a turn until i can" - that's just silly.

yet from what you say, it seems folks actually do this. no wonder games are such piles of crap these days.