next »

[Hajo]

Yeah you definitely need a max timestep no matter what. For example in OS X, when you hold down the minimize button, it pauses all updates to the app, so when you release it, your timestamp will be whatever the time you held the minimize button for. Not saying its a big use case, but if you dont limit your time step, it can be used to completely break your game and/or cheat in it.

I once got a problem report, that lead to a very curious discovery: At times, the time on the players computer ran backwards. This caused a negative delta time, and my code did not like negative delta times.

It turned out that the player had a radio-realtime-clock that every few minutes re-set the computers internal clock - and the internal clock ran too fast, so at the reset point, there was a negative time delta.

Sometimes it's just crazy what a programmer has to take care of. Time running backwards

[Triplefox]

I know of three kinds of valid timestep modes:

Render-locked and fixed timestep
Variable timestep based on framerate
Independently variable framerate and timestep

Render-locked and fixed is old school and is the "cleanest" way to do things in terms of computation and reproducibility, but it can't adapt to varied situations well. That said I would recommend it unless you have a compelling reason to do the others because they're more complex and still have flaws of their own.

Variable timestep based on framerate is what most of this thread is discussing: faster rendering = smaller timesteps. It's great except for the floating point error, which can add up to things like some players moving faster than others in online play. You will also have to cap the timestep, or risk unplayability on slow systems or bugs resulting from a "rare outlier" giant timestep. And because you're updating the game as fast as possible, computers will burn through their CPU unless you also cap updates with a lower bound too. Burning through the CPU is expected if you're running a console, but it's not so nice to someone's laptop or phone batteries. But on the other hand, you get to play with timing more readily, which is great for games that need to do that.

Independently variable framerate and timestep is the modern AAA method. This method involves multiple subsystems (render, animation, physics, AI, scripted events, etc.) parallelizing their processing; the resulting timestep comes from the synchronization of all subsystems, which may use a timing totally independent of whatever is going on in the render code. You can solve numeric drift in this way by locking down all the simulation-dependent code to use fixed increments and timings, while letting the other stuff run freely.

Sounds great, right? We should all go for fully variable systems, shouldn't we? Except that doing this parallelization and synchronization can exact a penalty on input responsiveness: render may keep going steadily, but the other systems have to catch up with each other before something visibly happens onscreen. Hence you may introduce delays of several frames, depending on how much needs to be synchronized and the lagginess of the display. In a 30fps game, a 1 frame delay is a ~15ms penalty. If you're delayed by five or six frames, players may not be able to tell exactly what's wrong with your controls, but they aren't going to FEEL very good. And if the framerate drifts, the responsiveness will drift too, screwing up precise timing.

Glaiel-Gamer's strategy of fixed timesteps with occasional skipped renders is a form of this parallelization, done only in the worst-case scenario where a tradeoff has to be made between render and simulation. Does it add response lag? Yes, when frames are skipped, because now the simulation is doing things the player can't see. It's a little bit "driftier" than if he had locked to the render rate. But it will look smoother, and if it happens infrequently, it's probably a good tradeoff, since people will notice jerky movement more readily than a few dozen ms of variable responsiveness.

In summary: This stuff sure is complicated! And no one solution is really "best."

For more:
http://www.gamasutra.com/view/feature/1942/programming_responsiveness.php
http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article

[Akari]

And because you're updating the game as fast as possible, computers will burn through their CPU unless you also cap updates with a lower bound too. Burning through the CPU is expected if you're running a console, but it's not so nice to someone's laptop or phone batteries. But on the other hand, you get to play with timing more readily, which is great for games that need to do that.

Running on unlimited FPS would be extremely stupid, except for performance test purposes. If you have a delta-time'd game, the most optimal solution would be to run it in VSync, which would lead to FPSes in the range of 60-120 for most people.

[mewse]

Running on unlimited FPS would be extremely stupid, except for performance test purposes. If you have a delta-time'd game, the most optimal solution would be to run it in VSync, which would lead to FPSes in the range of 60-120 for most people.

Problem is that many (most?) PC users set their video drivers to force vsync off;  it'll tell your game that it's obeying vsync, but then won't actually do it.

I need to keep extra code in my games to detect when a driver claims to be obeying vsync, but actually isn't, so that I can put my games to sleep for a few milliseconds, and clamp to 60 fps (or whatever) manually.

[ThemsAllTook]

I once got a problem report, that lead to a very curious discovery: At times, the time on the players computer ran backwards. This caused a negative delta time, and my code did not like negative delta times.

It turned out that the player had a radio-realtime-clock that every few minutes re-set the computers internal clock - and the internal clock ran too fast, so at the reset point, there was a negative time delta.

Sometimes it's just crazy what a programmer has to take care of. Time running backwards

That's a good one to watch out for. Rather than measuring wall time, which can change based on clock settings, you'd ideally want to be measuring monotonic time, which can never run backward. If you're writing in C, you can use QueryPerformanceCounter/mach_absolute_time/clock_gettime(CLOCK_MONOTONIC) (Windows/Mac/Linux) to get monotonic time measurements. However, some APIs only expose functions for measuring wall time. 

[deadeye]

I guess an easy approach would be this:

TimeDelta > 1/25 -> Set timescale to lerp(1,0.1,TimeDelta/TimeScale)

Or something along the lines of that, it would start to slow down a bit at 25fps and gradually slows down if the game runs even slower. It'd start at 3.6% slowdown at 25fps and slow down to 10% of original speed at 1fps.

EDIT: Forgot that timescale affects timedelta values in Construct, so added /TimeScale to the formula above.

I'll have to give that a try.  But it seems to me that the TimeDelta expression the system is returning is a measure between the last to cycles, so by the time the current cycle comes up it's obsolete info.  I ran into that problem when I did my own test with a different method, but I'll give yours a shot