We're talking about some pretty small time slices here. In my example, the sim is running at 480Hz and the user is seeing it at 60Hz, which is the limit of most people's monitors. It's literally drawing as fast as possible. Human high-level conscious thought, by latest research, only updates at approx 5Hz :lol: The simulation rate being higher than the display rate simply results in more fidelity -- e.g. integration of physics can be more accurate, not unfairness...>> [background=#fafbfc]If you accept the argument that there's no need to poll faster than the drawing rate[/background]
[background=#fafbfc]assuming you update no faster than you poll or render.[/background]
[background=#fafbfc]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.[/background]
[background=#fafbfc]you have to preserve the fair play of "its my turn, ok, now its your turn, ok now its my turn again."[/background]
[background=#fafbfc]"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.[/background]
[background=#fafbfc]yet from what you say, it seems folks actually do this. no wonder games are such piles of crap these days.[/background]
For example, in my racing sim, I can run the tire logic at 6000Hz to ensure that they behave realistically when cornering at 300MPH -- but I can also only allow the AI drivers to output new steering/acceleration/braking commands at 10Hz if I want them to appear human. My choice of tire simulation fidelity means nothing to AI vs Human fairness...
Moreover, a world-champion starcraft player, a professional athlete who trains full time, can manage about 400 actions per minute, which is impossibly high for us mortals. That's ~6.7 actions per second... or at 60Hz, that's one action every 9 frames, on average. So the best video game players in the world are already only getting approx one turn in eight, and can only manage to keep up with a computer "turn for turn" in a ~7Hz simulation... meaning that if you're running your update loop even at 15Hz, the computer is still getting twice as many "turns" as the player, which by your logic is grossly unfair???
No one would play a 7Hz action game these days, so obviously rendering at the user's input rate is not a good idea. Rendering as fast as possible makes the game more responsive for the user as the game-event->photon->cognition->motion->keyboard loop becomes shorter. At lower framerates, this whole loop gets longer, so the user is given a disadvantage -- even if they react as fast as humanly possible (about 200ms), they're given the handicap of the photons informing them of the event later than possible.
In my example I chose to poll at the rendering rate, but that's not required either. You could poll once per update, and still render once every N updates -- this would allow the user to input commands at the simulation rate, but only be able to see the results of them at the display rate. Note though that audio devices have pretty high output rates (e.g. in KHz instead of Hz :) ) so audio cues could still be output at the simulation rate.
Fact is that in general, a high framerate game will be more responsive than a low-framerate one, decoupling the simulation and rendering rates doesn't necessarily impact responsiveness, and decoupling rates doesn't have to impact the fairness of the game.
Anyway, in the OP you asked if it's possible to update faster than render, without harming responsiveness. And yes, you can, as long as you're ok with the sim having higher temporal fidelity than the user's monitor... In any case, responsiveness does not have to decrease- it can be the same as before.
In fact, responsiveness can actually improve in a decoupled simulation!
In a traditional loop running at 30Hz, the delay between a key-press occuring and being picked up by the poll is between 0 and 1 frames, or on average, 0.5 frames, or 16.7ms. There's then 33.3ms between the poll and when until the CPU finishes the next frame (which consumes that input), for 50ms average delay between a keypress, and the draw commands resulting from it being sent to the GPU:
0ms 33.3ms 66.6ms
| Frame 1 | Frame 2 |
Key press | Poll,Update,Render |
In a decoupled loop where there's 3x Poll/Update pairs per draw, there's also less time between polling, so now we're polling every ~5.6ms, so a key-input waits an average of ~2.8ms before being picked up by a poll.Events picked up by a poll now wait either 16.7ms, 11.1ms or 5.6ms (average 11.1ms) before the next draw starts, and 16.7ms until that draw completes, for 30.5ms average delay between a keypress, and the draw commands resulting from it being sent to the GPU:
0ms 16.6ms 33.3ms
| Key Press | |
| Frame 1 Sim | Frame 2 Sim |
| P,U | P,U | P,U | P,U | P,U | P,U |
| Frame 0 Draw | Frame 1 Draw |
| Draw | Draw |
So in a traditional loop, the input latency is one and a half frames on average, while in this particular decoupled loop it's actually less than one frame on average!Of course, I have cheated by making the Update portion 3x faster in one example and not the other :lol: but the general idea is that: if you're bottlenecked by rendering, you might be able to increase your simulation rate to no ill effect (or even to positive effect).
There's also the opposite situation -- when you're bottlenecked by the simulation. e.g. in RTS games, it's common for the simulation to advance at something pitiful like 10Hz, while the renderer pumps out responsive 60Hz frames.
In this case, rendering at 10Hz would simply be unacceptable -- things like camera scrolling would be unnecessarily choppy and unresponsive. By increasing the display rate, not only do you keep the user happy with smooth animation, but you make all of the user interface elements much more responsive (as they don't have to be tied to the simulation rate). If the user clicks on a button, the UI code can start playing an audio response and changing the color of that button in around 25ms, whereas if it was tied to the simulation rate, the average response would be 150ms.
So again, in that different situation, decoupling the simulation/rendering rates can actually improve the user's feeling of responsiveness.