The first time I learned about "frames" was in talk about how Street Fighter 2 works. Keep in mind this game is ancient by today's standards. With the Street Fighter 2 cabinet, the hardware there focused on exactly one thing: Running Street Fighter 2. This meant the game could make some assumptions about its operation, namely its timing. Street Fighter 2 plays at 30 frames per second, meaning the screen redraws itself 30 times a second. Each cycle between the redraw is a "frame". During this time, the game does all of its computations. It copies pixels around, computes distances, does hit box checks, etc all in this tight little loop. Since frames in Street Fighter 2 are fixed to this 30 times per second, that means you have about 33 milliseconds to do all of your computations. Any smarts that are in the game have to fit in this time period. If that's the case, you can count on each frame being 33 milliseconds long, and you can derive timing in the animation system, what your grace period is to throw a fireball, or chain together some combo, or whatever. But the problem is this is a lie. It's just an infrequent one for Street Fighter.

Remember Solitaire? That game that came built into Windows 3.x back when you had to clean mouse balls? Yeah that one. I think it's still in Windows today. If you beat Solitaire, you were given a wonderful little animation of the cards cascading out of their slots, kind of undoing everything you just did. You could easily go use the bathroom and come back to see it still going. This thing took a while. At the time if you were on Windows 3.x and you had a 66 Mhz computer, this would go pretty slow. Once you got a Pentium, you'd notice the animation completed in about a second or two. In both situations, the game was doing the animation as fast as possible, but one computer was significantly faster than the other. Computers back then often had a turbo button. You could use this button to slow your computer down and run older applications that had this kind of timing problem. Street Fighter would be one of those applications.

The lie about frame counting is that sometimes the computations can't complete in the time period they have. This happens a lot in Chun Li's level: There's so many animations and other things going on that if the players add a little bit more and maybe step away from each other, the hardware sudden has way too much to do to cram into that 33 millisecond time slice, so it just takes longer, and as a result the game enters a strange kind of slow motion.

Back in the day of Street Fighter 2, and most gaming consoles for that matter, the game you were running was the program the hardware ran. Today even the XBox and PSX consoles run an operating system (OS). When you boot up your mac and run Photoshop or whatever, you're not running Photoshop. You're running MacOS. The operating system is a very intricate program that makes it look like you're running other programs. In reality the OS grants programs the ability to execute a few instructions at a time before the OS interrupts and then gives another program a chance to run on the processor. When it does a good job about switching around really fast, it makes it look like you're running multiple programs at once. Your games are one of these programs. This makes it really hard to promise that you have exactly 33 milliseconds to complete your operations. In the middle of the frame, the OS could easily have let several dozen other programs run a little bit too, each eating into that precious slice of time.

As an example, there's a small program running in this post that loops and prints the time since the last tick in milliseconds. Notice the variance.

Here's the code that does this, if you want to follow along:

var lastTime = Date.now()
var el = document.querySelector('[data-id="millisecond-monitor"]')
function printMillis() {
  var delta = Date.now() - lastTime
  el.innerHTML = delta
  lastTime = Date.now()
  window.requestAnimationFrame(printMillis)
}

window.requestAnimationFrame(printMillis)

So how do games not stutter every time your browser takes a bunch of time to inefficiently render a gif you're not even looking at because you're playing a game? Games multiply a time delta.

Take this psuedo-code as an example:

if player1HoldingRight
  player1Position.x = player1Position.x + player1Speed

Here player1Speed is a simple fixed number. The speed is tuned to you playing the game at 30 FPS. The new x is the old x plus that speed. Simple! But a lie. To get around it, we use the delta since our last frame.

if player1HoldingRight
  player1Position.x = player1Position.x + (player1Speed * timeSinceLastTick)

Sometimes we call this a tick. Here we do multiplication. If the delta was high, then the amount we move the player is high. If it's low, the amount we move the player is low. Mathematically it scales perfectly. There's some complications with this approach, but rest assured this is what everyone uses today. Unity games are no exception.

Here's an example of the timing scaling to your machine's speed:

I managed to get my hands on the up-until-now rumored purple queen sprites. Many berry runners died to bring us this sprite from KQ 4 Turbo X Championship Legendary Edition. You can see the queens moving horizontally in separate "swim lanes". We have exaggerated artificial delays we're adding to demonstrate how the varied methods work.

We cannot assume all frames are created equal. Frames are not fixed slices of time but instead highly varied slices of time.

Imagine the kind of work it takes to make a stop motion movie. You meticulously position all of the objects in the scene, setup your lights, focus the camera (pray that you didn't nudge it), and take that picture. Okay great. Computers do this too, but they can't spend minutes doing it. Try 33 milliseconds at worst case.

There's a two dimensional section of memory called a buffer, and the game's job is to translate the game's state into a bunch of colors. These colors are destined to populate pixels on the screen, and this is how you see all the pretty things in the game. The monitor that displays this information is a simplistic device though. It redraws itself at some fixed rate (60 Hz to 75 Hz, depending on the hardware). CRTs are closer to 30 Hz if I recall. The monitor shows stuff at its own rate, not the video card's. So what winds up happening is the screen can start redrawing the screen using the buffer as the game is also writing to that buffer. What this means is you wind up seeing part of the last frame and part of the current frame at the same time, but there will be a seam (horizontal due to how the hardware works).

vsync is a feature that's really easy to use on a game engine. It's a simple toggle that tells the game it has to wait until that buffer is ready and then it can draw to that buffer. The monitor won't see the buffer until after the game has finished writing to it. The tradeoff is the game has to sit on its hands when it could be calculating smoke trajectories of bong stacks in weed-em-up games. It slows the game down, sometimes in a noticeably adverse way.

It's worth noting there's other ways to combat tearing such as double or triple buffering, but these are mitigation strategies. At the moment there's not an actual fix. There's been development on gaming monitors that can communicate with the video card and sync up in a less primitive way.

From staring too long at the background on the game, it would seem like Killer Queen does indeed not use vsync currently. When the background scrolls upwards, you can see the tear. That said, I've noticed that cabinets can perform a little differently when they get hooked up to streaming equipment. The streaming equipment influences the frame rate of displays. So it's hard to say one way or another with much certainty.

Display sizes vary all over the place. The result is game engines don't use pixels directly anymore. Even 2D games are rendered using 3D libraries. In Unity's case 2D things will be rectangles that face the camera. The coordinate system Unity uses is arbitrary. You could change the size of your camera and be able to see further, for example. All of the coordinates used in Unity are floating point numbers. Floating point numbers are the poor man's numbers that allow for decimals. Floating point numbers are "lossy", meaning they aren't exact and even though it might look like the numbers are correct they actually aren't the same thing. This doesn't mean Unity is doing anything poorly. The world of 3D gaming is dominated by floating point numbers. The only things that become hard with floating point numbers are when you want to do exact comparisons and a large scaling distance.

Generally what happens with pixel graphics is someone will build the images using fixed pixels, and then assign that image to a rectangle that'll show up on the screen. Most of the time there's a filter applied to the images in real-time that blurs and distorts the image. You want this in a vast majority of 3D games, as it addresses graininess and a number of other visual artifacts. In the case of retro graphics games, the filter is disabled so you see the raw pixels. They are still stretched though.

In Unity, the CharacterController is a component you add to a game object that makes it really easy to control as a player. It's not "physics", similar to how Mario has never jumped around with physics. Yeah, Mario is influenced by a kind of gravity, but he's propelled by you holding the jump button longer (meaning more "thrust" would be applied after he left the ground), and steering in the air is possible in many platformers, but on the scale any of us could jump is not possible, even if we could jump 10x higher than we can now. So it's not physics. It's a weird kind of game physics and the CharacterController scratches this itch rather well. It has all kinds of knobs to turn for things like gravity, max falling speed, air speed and control, etc. It also is really nice because it knows how to move "around" small obstacles - very small like a single stair step.

The CharacterController uses a 3D capsule (pill shape) as its volume for knowing when it's running into things. It works really well for most "human" shaped things. If you need to, you can reduce the height to get something closer to a sphere. Effectively, it's a tube with two hemispheres at the top and bottom. This has interesting interaction with a rectangular volume though.

If you could draw the character controller over a character, this is what it would look like:

Cosmetic pieces will totally fall out of the bounding area, and that's okay. This kind of approximation is totally fine for the kind of game KQ is, and a majority of others as well. Keep in mind, this specifically for movement and bumping into inert objects such as terrain. The CharacterController itself is not a collider. We'll cover that more in another section.