What is a sprite? Sprites are a concept in computer programming, primarily gaming, or at least primarily thought of as gaming related. But if you are reading this on a desktop or laptop computer, you just used a sprite to click on this link.
A sprite is a two-dimensional graphical object that can move around independently of the rest of the screen, including moving in front of or behind other graphical elements.
Today the most common example of the use of a sprite is the mouse pointer or mouse cursor. The mouse cursor isn’t something we traditionally think of as a sprite, but in early graphical user interfaces, on systems that had hardware sprites, such as a commodore 64 or Amiga, The mouse pointer used the hardware sprite functionality.
In the mid-1990s, when hardware acceleration for Windows started becoming a common feature in graphics cards, one of the things those cards added was what they call a hardware mouse cursor. Essentially, that’s a sprite in hardware.
Conceptually, the mouse cursor is a great example of a sprite. You move it around, and it moves in front of any icons, menus, and any other objects on the screen, and when you move it away, whatever it was covering comes back into view without any delay, or at least any visible delay.
But that is probably an unorthodox definition. Let’s talk about sprites in the more traditional sense.
What is a sprite in gaming?
Sprites are a common concept in 2D gaming, especially platform type games. Every popular 1980s platform game made extensive use of sprites. For that matter, so did the games that came before platform games, but these days, platform games are probably more universally known.
Take the early 2D Super Mario Bros games. In those games, Mario and Luigi and the enemies were all sprites. So were the things they threw at each other.
Moving the characters and their projectiles around on the screen was largely hardware assisted. You defined what the object looked like in memory, then essentially just had to tell the video hardware where the sprite existed in memory and where you wanted to put it on screen. The video hardware took care of the problem of redrawing the background as all those sprites moved around.
Limitations and getting around them
These systems generally had a limit of how many sprites the video chip could handle, but with some software tricks, it was usually possible to get more. Technically the screen gets drawn a single line at a time, so a limit of eight sprites is really more like a limit of eight sprites per line. And if you really wanted to push the limits of the hardware, you could keep track of how far along the chip was in drawing the current line and changed things in the middle of the line. This was one of the ways Atari 2600 developers got around that console’s limits.
The implementation of Pac-Man on the Atari 2600 wasn’t exactly beloved. But it wasn’t supposed to be possible given the limitations of the hardware.
Hardware sprites frequently have certain limitations besides the quantity. Other limitations include dimensions and number of colors. If programmers had any sprites to spare, they would work around those limitations by stacking or layering sprites to get larger characters, more colors, or both. Mike Tyson’s Punch Out on the NES was an example of a game that used all of these techniques. On the original NES, a sprite could be 8×16 pixels, and you could have 64 of them. Punch Out stacked and layered all 64 of them to make the two boxers.
Why 2D games sometimes flicker on old consoles
One of the reasons parts of the screen flicker in old games that have a lot of action going on is because the developers ran out of sprites and are using tricks to get more of them on screen. Sometimes the flicker is on avoidable, depending on how many CPU cycles they have to work with. Sometimes it is possible to minimize the flicker. But ultimately when you are pushing the limits of a system, a developer may have to choose between flicker or just having less going on on screen.
What is a sprite in software?
This is probably two questions rather than a single question. In software development, the concept of a sprite is exactly the same as it is in gaming. It is an object that moves around on a 2D screen and moves independently of the background.
The question is whether the implementation happens in hardware or in software.
Even in the 1980s, not all computer systems had sprites in hardware. The Apple II did not. Neither did the IBM PC. This was one reason why you saw larger numbers of arcade style games on the Commodore 64 and Atari 800, because those systems did have sprites. They lended themselves to that type of game more readily.
Programmers figured out how to implement sprites in software. Atarisoft titles were a notable early example. It became more doable as CPU speeds increased over the course of the 1980s and 1990s. Commander Keen is an example of a PC game that had a console like scrolling background and lots of fast moving sprites, all accomplished in software.
And in a modern programming environment, conceptually there isn’t a ton of difference anymore. You call a routine to create a sprite and move it around either way. The library handles the details.
Advantages of doing it in software
Today, the advantage of software sprites is flexibility. On older systems that did it in hardware, there were limits on the size and the number of colors. Those limits were based on how much silicon they had available. In software, the major limitation is CPU cycles. We put up with those limits in the 80s because CPU cycles were scarce. Today, CPU cycles are plentiful.
The other advantage is compatibility. Using software basically abstracts away any compatibility issues. There was a time when games would have to be coded specifically for a type of video chip, or a family of chips at the very least. Imagine having to write one version of a game for Nvidia GPUs and another version for AMD GPUs.
Relying on software eliminates that need. It also introduces overhead, but personal computers have enough CPU power to deal with that overhead now. For that matter, so do tablets and smartphones.
So the concept of a sprite is essentially unchanged since the 1970s. When you play Pong, the ball and the two paddles are sprites. When you play a game like Angry Birds, the birds and the pigs are sprites. The major difference is implementation.