Delta time is garbage when applied to the game sim

I hate the idea of using delta time for anything but the rendered view. The game sim should always remain at a fixed rate. There are too many games now that sacrifice deterministic behavior. The way Doom source ports handle it is the best method: accept the tiniest bit of lag to ensure that the game sim stays 100% predictable, that the game states remain objectively quantifiable.

The lag isn't even an issue if the player's input updates at the refresh rate instead of the game rate. See GZDoom: mouse position always updates at the highest rate possible, only syncing the game state with it every new tic. The end result is that there is no perceptible lag, and the game stays deterministic.

I prefer alpha time, to be honest. Let me guess, you like the idea of beta time, don't you?

I have no idea what this is, but might it be why I feel the tiniest bit of input lag on uncapped fps whereas I detect none at the 35 cap?

Never heard of delta time before this, though. Will have to find out what that means on my break..

Delta time = 1 second of game takes 1 second of time to play out, regardless of whether that's 60 frames in that second or 6.

One caveat with such a method is that collisions and things can 'skip' (unless there are measures to compensate) at low frame-rates as more distance is travelled between one frame to the next.

Yeah go with a fixed time even if people complain about only being 60 fps when other games have 200 fps. Its better for the processor. Especially when some computers and OS have pop ups can happen warning you about excessive processor usage.

Others complain about 30 fps in a 60 fps era... well if the game can dip to 55 fps you can feel it even if you can't see it.

Someone explain this to me.

1 minute ago, Memfis said:

Someone explain this to me.

11 hours ago, Jayextee said:

Delta time = 1 second of game takes 1 second of time to play out, regardless of whether that's 60 frames in that second or 6.

Or, how about Wikipedia's explanation?

The nice thing about Delta Time is that older games with it can be hacked/modified to run at higher framerates without too many hitches, compared to the alternative where the timings can get screwy. I think the Ty devs ran into this problem with the Steam port of the first game, but not the second.

20 hours ago, Blastfrog said:

I hate the idea of using delta time for anything but the rendered view. The game sim should always remain at a fixed rate. [...] the game sim stays 100% predictable, that the game states remain objectively quantifiable.

I can understand the advantages of the game sim staying 100% predictable and the game states remaining objectively quantifiable, but what exactly does make the alternative approach so bad that makes you condemn it so absolutely?

It's easier to deal with, and kills any possibility of timing related behavior bugs. It also ensures demo playback.

No, it ensures demo playback if all you store is player movement. Even Doom C/S ports use deltas and store the entire game state in demos. That inflates their size considerably, but playback sync is not a problem. Once netplay is considered, that "tiniest bit of lag" you mention becomes a torturous nightmare. You did consider netplay when you said "anything but the rendered view", right?

It's easier to achieve certain things with fixed time than delta time, I get that. Such arguments just don't suffice to make me reject delta time out of principle. Putting more work into making sure there won't be timing bugs, and either rejecting the concept of demo recording or introducing a demo format that stores milisecond delays between every 2 consequent refreshes, are viable options that achieve the same results as the abovementioned ones at least in some cases (depending on goals trying to be achieved), but also work with delta time. A definitive argument against delta time would have to make the concept itself superseded by another concept from all standpoints. Delta time has an obvious advantage over fixed time from the "timing flexibility" standpoint (for lack of a better term), so either an argument for delta time being superseded from this standpoint, or an argument for the standpoint itself being somehow wrong to be considered in all possible cases, would be a necessity for arguing that delta time is always bad.

A better argument against delta-time game sims are that they can result in frame rate dependent behavior. One of the most famous examples was Quake 3, where because values were rounded off to the nearest integer, you could jump sliiightly further if you had a very specific framerate.

I feel like there's something baffling about condemning an entire method of programming and game design when your perspective is blatantly based around one type of game.

Like, sure, yeah, the drawbacks of delta time can be pretty blatant for something like a mobility-based FPS or platformer, but are you really going to tell me that some games don't really care or flat-out benefit from it, like RTSs, MMOs, or sports games?

1 hour ago, dew said:

Even Doom C/S ports use deltas and store the entire game state in demos. That inflates their size considerably, but playback sync is not a problem.

I'm not sure what you are referring to here as not a single Doom source port, even the C/S ones, use delta timing in the playsim.

The main advantage of fixed rate game ticking is that physics simulation is always predictable and that network synchronization is easier as you only need to decide which tick a received net message arrives in (to hide jitter). You could even make a net game where everyone has an exact ping of say 50 ms for predictable competitive purposes online, although I'm sure lots of FPS players would oppose that.

The disadvantage is that the ticking doesn't happen every rendered frame. You need to interpolate between ticks - not that bad, but some players are able to notice it. More importantly, if the ticking is part of the reason the frame rate is low, then you'll get frames that take longer time to render than other frames. For example, let's say that scene rendering takes 14 ms and playsim takes 3 ms. At 60 ticks per second, that gives you first a frame that takes 17 ms, then 14 ms, then 17 ms, then 14 ms and at some point 20 ms. With delta time you avoid this problem because the playsim ticks every rendered frame, keeping the frame rate more stable.

2 hours ago, dpJudas said:

if the ticking is part of the reason the frame rate is low, then you'll get frames that take longer time to render than other frames. For example, let's say that scene rendering takes 14 ms and playsim takes 3 ms. At 60 ticks per second, that gives you first a frame that takes 17 ms, then 14 ms, then 17 ms, then 14 ms and at some point 20 ms. With delta time you avoid this problem because the playsim ticks every rendered frame, keeping the frame rate more stable.

As far as I'm concerned, a game should always (or as close to always as possible) be at max performance*. If it isn't, either the game is unoptimized and/or the user's hardware sucks and they should either upgrade or tune down the settings. Because of this, I don't see this as an issue, because it's only an issue when circumstances are that should not be.

*When I say max performance, I only mean what the game was designed for. This can mean 30fps, or even 15fps (in the case of Jaguar Doom). Don't think I'm some kind of harware elitist, my computer is five years old!

2 hours ago, dpJudas said:

The disadvantage is that the ticking doesn't happen every rendered frame. You need to interpolate between ticks - not that bad, but some players are able to notice it.

Nobody would be able to notice if:

1. The internal ticrate is high enough (let's say 60, though 100 or 120 would be great)

2. 1:1 inputs (such as mouse control for aiming) are accepted and the results rendered independent of ticrate.

IIRC, GZDoom does this with the mouse. Try turning really fast, and hit the pause key as your mouse is still sliding. You'll see your view jolt right back to where it "actually is" in the game-state because it pauses on the most recent tic update, even if frames have been rendered afterward.

43 minutes ago, Blastfrog said:

Nobody would be able to notice if:

1. The internal ticrate is high enough (let's say 60, though 100 or 120 would be great)

2. 1:1 inputs (such as mouse control for aiming) are accepted and the results rendered independent of ticrate.

The catch with increasing tick rate is that it means slower machines must also spend more time doing playsim stuff (as opposed to delta where low frame rate also means fewer ticks). As for noticing, I personally don't even notice it with Doom (35hz), but a friend of mine noticed I was interpolating in my own hobby shooter game that used 60hz. It isn't the mouse aiming they notice - its the delay from when they change move direction until the character reacts.

Overall I agree with you that fixed rate ticking is much better, though. I think the true reason why most games use delta is that its easier to implement and understand - you don't have to make the distinction between what is playsim and what is per-frame stuff (UI animations, camera/mouse movement, etc.).

is delta time that common these days? I mostly ask because the fact that there's a fair amount of games that only run at the right speed when there's a specific framerate cap seems to suggest otherwise. Though granted that's not as many games doing this as I was imagining at first.

I'm now kinda curious what the really popular engines like Unity and UE4 do, since I sort of imagine this is the kind of system stuff that you're not really able to prod at in these engines (well, I guess in the case of UE4 you have the full source code at your disposal, but working on that alone would probably be not fun)

Unity appears to have a flat delta time, judging by its scripting system.

UE4 however uses a more modern variant known as a semi-fixed timestep. Put simply, various simple actions are processed on the delta time, however scripts (and I suspect player input?) is run on a fixed time loop. Sort of like How Doom ports do interpolation, except the interpolation is done by the playsim, not the renderer.

Using a full unlocked delta timed playsim is still common, but developers are starting to lock it to a specific time (i.e the engine uses delta times, but at a fixed unit of speed). This is because the framerate has a direct effect on physics precision with a fully unlocked delta time, and can produce some rather erratic results (Doom'16 and its super bouncing at 200FPS, for example, and IIRC 200FPS is the maximum speed). From experience, with Turok2 we locked the delta to at 60Hz because the N64 had a hard time reaching that (if ever?), and so a lot of the physics engine was untested at speeds beyond.