Game Timers: Issues and Solutions (2012)

The last time I implemented a timing loop I came up with an approach that would mitigate jitter and oscillation artifacts occurring due to OS overhead (though not solving the aspect of video refresh itself being misaligned). One of my major assumptions was that I could run the game at higher frequency than refresh and therefore rely on downsampling my output, vs the norm of many higher-end games where the base tick is interpolated up to refresh rate.

1. Derive ideal number of elapsed frames using elapsed time from start divided by framerate.

2. Run updates to "catch up" to ideal frames.

3. Observe "rubberbanding" artifact as game oscillates between too slow and too fast.

4. Add limits to how many catchup frames are allowed per render frame to stop the rubberbanding. Implement a notion of "dropped frames" instead, so that our ideal time accounting has a release valve when too much catchup is needed.

5. Now apply a low-pass filter to the amount of catchup frames over time, e.g. if you have a tick of 120hz but your monitor is at 60hz you are likely to see an occasional high frequency oscillation in how many tick frames are supplied per render frame, like [2,3,2,3,2,3]. Filtering can make this [2,2,2,3,3,3]. (It's been a while since I did this, so I don't recall my exact algorithm)

The end result of this effort is that wall-clock time is obeyed over the long-run(minus dropped frames) but the supplied frames are also able to maintain the same pacing for longer periods, which makes the moment-to-moment experience very predictable, hence smooth.

While I haven't tried it, I think the equivalent thing when interpolating would be to freeze a certain issued delta time pace for some number of frames.

> In the 80's we took perfectly smooth scrolling and animations for granted, because most 80's home computers and game consoles were proper hard-realtime systems.

Proper hard realtime means the software is designed to meet stringent time deadlines. If a deadline is missed then the system has failed.

Soft real time means you tolerate missing one or more deadlines if the system is designed to handle it.

The 80's hardware only ran the game code so there was never any CPU contention. There was no kernel, scheduler, threads or processes. The programmers could wrap their heads round the simpler hardware and use all available tricks to optimize every clock tick to do useful work.

Nowadays we have stupid cheap multicore GHz CPU's for a few dollars with GB of RAM so you brute force your way through everything on a general purpose OS like Linux.

What's preventing PC's from having some realtime clock hardware component that could be used by software?

> Consider these ideas at broader scale too - What if you could amortize the cost of that power-hungry timer thread for thousands of gamers instead of just 1? Are there maybe some additional benefits to moving 100% of the game state to the server and shipping x265 frames to the end users?

I don't know of any online game that doesn't track the official game state on the server. This is required for anti-cheat reasons, if nothing else. However, networking would typically be optimized to send small packets of information, and typically over UDP. If a packet is missed, the next packet will just be overwriting it anyway, so no big deal. Clients would basically just locally simulate game state and then reconcile that against the game state being received from the server.

Also, rendering has to be done per-client anyway, since each one has a different camera state. So there's no economy of scale for doing that on the server rather than the client. In fact, there's probably anti-economy: Servers that aren't rendering don't need expensive video cards unless they're using them for physics.

I have the understanding that more modern games do sometimes use TCP sockets. And obviously modern bandwidth has made streaming frames realistically possible. Hence the recent emergence of streaming game services.

Yup it is well known since a long time. Fun fact: I discovered that technique myself around 1991 (and still have the ASM + C source code for the DOS game using it). The first time I remember it publicly described was on the GamaSutra website in a post-mortem for the first "Age of Empire" game. GamaSutra was/is a big deal among game devs so the technique became "famous" when that post-mortem was made.

I wrote about it in a thread here called: "Why bugs might feel “impossible”" about two months ago and someone commented that the game TerraNova (from 1996) had a fully deterministic engine.

BTW TFA say StarCraft 2 (2007) used the technique but Warcraft 3 (2003) was already using a deterministic engine. Save files for Warcraft 3 games (including multiplayer ones over the Internet) consisted in only recording the player inputs and the "tick" at which they happened. This make for tiny savefiles, even for very long games.

So basically: several of us independently discovered that technique in the nineties. There may have been games in the eighties already using such a technique but I don't know any.

https://news.ycombinator.com/item?id=27517074

Yeah extremely well known. Doesn’t mean everyone uses fixed time steps though or talks about it a lot when they do. But you’ll find the concept creeps up a lot in physic engines, deterministic networking/gameplay and in discussions of engine architecture amongst other places.

    while (running)
    {
        static std::uint32_t simulation_time{0U};
        std::uint32_t const real_time = SDL_GetTicks();

        process_input();

        while (simulation_time < real_time)
        {
            simulation_time += 16U;
            update(16U);
        }

        render();
    }

Please note that non-60Hz displays are surprisingly common (not just "gamer monitors" with 120, 240Hz etc..., but also odd refresh rates like 72, 75, 85, 90 and 100Hz)

Ideally the 'render clock' would query the display refresh rate from the operating system, but this is harder than it sounds. The next best option is to measure the frame time, and then round to the next "common" refresh rate (AFAIK that's the only way it works on the web for instance).

Before you can back track, you need to first recognize that you missed a collision

  t=0
    cube1 p=5,0 v=0,0 m/s
    cube2 p=1,0 v=2,0 m/s
    // Game knows cube1 and 2 will collide at t=2
  t=1
    cube1 p=0,0 v=0,0 m/s
    cube2 p=3,0 v=2,0 m/s
    cube3 p=0,0 v=5,0 m/s
    // Game knows cube1 and 2 AND 3 will collide at t=2
  t=2
    all cubes hit at 5,0

Tick rate usually means how many times a server calculates the state of the world in an online game. So a client can have 300fps, but the server might only calculate 128 ticks per second. If your computer's FPS dips below that of the server's tick rate (or your internet is bad) you start missing information. The client usually calculates things as if it has perfect information, and then when a tick comes in an tells your computer it is wrong, the client corrects itself. So the lower the tick rate on the server, the more times this happens (since your computer has made hundreds of calculations since the last tick came in) and it seems slower / choppier.

Yes!