Part of a series on:
Video game graphics
Types 2.5D & 3/4 perspective First person (video games) Fixed 3D Full motion video based game Stereoscopic video game Graphic adventure game Graphical video game Isometric graphics in video games and pixel art Side-scrolling video game Text-based game Third-person view Tile-based video game Top-down perspective Vector game
Topics 2D computer graphics Parallax scrolling Pixel art Sprite Tile set 3D computer graphics 3D rendering Polygon Pre-rendering Animation Cel-shaded animation Digitizing Rotoscoping Computer graphics Real-time graphics Game art design Graphics engine First-person shooter engine Tile engine Skybox Virtual camera system Voxel
Lists List of FMV-based games List of FPS engines List of stereoscopic video games List of text-based computer games Category:Video game graphics

In computer graphics, a sprite (also known by other names; see synonyms below) is a two-dimensional image or animation that is integrated into a larger scene. Initially including just graphical objects handled separately from the memory bitmap of a video display, this now includes various manners of graphical overlays.

Originally, sprites were a method of integrating unrelated bitmaps so that they appeared to be part of the normal bitmap on a screen, such as creating an animated character that can be moved on a screen without altering the data defining the overall screen. Such sprites can be created by either electronic circuitry or software. In circuitry, a hardware sprite is a hardware construct that employs custom DMA channels to integrate visual elements with the main screen in that it super-imposes two discrete video sources. Software can simulate this through specialized rendering methods.

As three-dimensional graphics became more prevalent, sprites came to include flat images seamlessly integrated into complicated three-dimensional scenes.

History

In the mid-1970s, Signetics devised the first video/graphics processors capable of generating sprite graphics. The Signetics 2636 video processors were first used in the 1976 Radofin 1292 Advanced Programmable Video System.

The Atari VCS, released in 1977, features a hardware sprite implementation wherein five graphical objects can be moved independently of the game playfield. The VCS's sprites, called players and missiles, are constructed from a single row of pixels that displayed on a scan line; to produce a two-dimensional shape, the sprite's single-row bitmap is altered by software from one scanline to the next.

The Atari 400 and 800 home computers of 1979 feature similar, but more elaborate circuitry, capable of moving eight Player/Missile objects per scanline - four 8-bit wide players, and four 2-bit wide missiles. This more advanced version allows operation like the VCS where the CPU modifies the graphics pattern register for each scan line, or an automatic mode where the display chip performs DMA from a table in memory populating the graphics pattern registers for each scan line. In the automatic DMA mode vertical motion is simulated by moving the sprites up and down incrementally in memory. The hardware produces a two-dimensional bitmap several pixels wide, and as tall as the screen. The width of pixels can also vary from 1, 2, or 4 color clocks. Multiple Player objects can be merged to produce a multi-color player. The four missile objects can be grouped together as a fifth Player and colored independently from the Players.

The Elektor TV Games Computer was an early microcomputer capable of generating sprite graphics, which Signetics referred to as "objects".

The term sprite was first used in the graphic sense by one of the definers of the Texas Instruments 9918(A) video display processor (VDP).^[1] The term was derived from the fact that sprites, rather than being part of the bitmap data in the framebuffer, instead "floated" around on top without affecting the data in the framebuffer below, much like a ghost or "sprite". By this time, sprites had advanced to the point where complete two-dimensional shapes could be moved around the screen horizontally and vertically with minimal software overhead.

The CPU would instruct the external chips to fetch source images and integrate them into the main screen using direct memory access channels. Calling up external hardware, instead of using the processor alone, greatly improved graphics performance. Because the processor was not occupied by the simple task of transferring data from one place to another, software could run faster; and because the hardware provided certain innate abilities, programs were also smaller.

Hardware sprites

In early video gaming, hardware sprites were a method of compositing separate bitmaps so that they appear to be part of a single image on a screen.

A simple C64 game with few sprites (hardware sprites)

Many early graphics chips had true spriting use capabilities in which the sprite images were integrated into the screen, often with priority control with respect to the background graphics, at the time the video signal was being generated by the graphics chip.

These contrasted with software and blitter methods of 2D animation which modify a framebuffer held in RAM, which required more memory cycles to load and store the pixels, sometimes with an additional mask, and refresh backgrounds behind moving objects. These methods frequently required double buffering to avoid flickering and tearing, but placed fewer restrictions on the size and number of moving objects.

The sprite engine is a hardware implementation of scanline rendering. For each scanline the appropriate scanlines of the sprites are first copied (the number of pixels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the number of sprites on a line), and costly caches (the size of which limit the horizontal width) and as the pixels are sent to the screen, these caches are combined with each other and the background. It may be larger than the screen and is usually tiled, where the tile map is cached, but the tile set is not. For every pixel, every sprite unit signals its presence onto its line on a bus, so every other unit can notice a collision with it. Some sprite engines can automatically reload their "sprite units" from a display list. The sprite engine has synergy with the palette. To save registers, the height of the sprite, the location of the texture, and the zoom factors are often limited. On systems where the word size is the same as the texel there is no penalty for doing unaligned reads needed for rotation. This leads to the limitations of the known implementations:

Many third party graphics cards offered sprite capabilities. Sprite engines often scale badly, starting to flicker as the number of sprites increases above the number of sprite units, or uses more and more silicon as the designer of the chip implements more units and bigger caches.

Sprites by software

A sprite of a fencer unit from Wesnoth

Many popular home computers of the 1980s lack any support for sprites by hardware. The animated characters, bullets, pointing cursors, etc. for videogames (mainly) were rendered exclusively with the CPU by software, as part of the screen video memory in itself. Hence the term software sprites.

Mainly, two distinct techniques were used to render the sprites by software, depending on the display hardware characteristics:

• Binary image masks, mainly for systems with bitmapped video frame buffers. It employs the use of an additional binary mask for every sprite displayed to create transparent areas within a sprite.
• Transparent color, mainly for systems with indexed color displays. This method defines a particular color index (typically index '0' or index '255') with a palletted display mode as a 'transparent color' which the blitter ignores when blitting the sprite to video memory or the screen.

Return of sprites in casual games and mobile devices

With mobile devices and casual gaming becoming more and more popular the classic 2D games return. The modern devices lack support for hardware sprites but come with powerful 3D hardware. On these devices sprites are simulated using textures on rectangular shapes. Perspective is disabled for these games. Since the hardware often comes with constraints - e.g. that it can only use power-of-two sized textures (that is a width or height of 64, 128, 256, ...) sprite sheets are used to reduce memory consumption. This is done by packing many sprites into one texture which, as a whole, has to meet the hardware constraints. Apart from the memory usage this technique can also be used to reduce the number of draw calls to the graphics subsystem and speed up rendering.^[27]

There are several programs that still use 2D sprites in their construction. RPG Maker VX and Wolf RPG Maker are just a couple of examples. As well as the programs that can create said indie games, there are several mainstream games as well. These famous game series like Fire Emblem, Pokémon, and other handheld system games tend to use these more for the same reasons that mobile devices such as tablets and cell phones do. It saves on memory so it allows for more content, effects, music, and story to be added into the chip or cartridge. As such, for first time indie game developers, sprites offer an easy but effective way to introduce themselves into game design as a whole.

Synonyms

Major video game companies rarely (if at all) use the term "sprite" in the general public. Some other alternatives that have been used are:

• Player-Missile Graphics was a term used by Atari, Inc. for hardware-generated sprites in the company's early coin-op games, the Atari 2600 and 5200 consoles and the Atari 8-bit computers. The term reflected the usage for both characters ("players") and other objects ("missiles"). They had restricted horizontal size (8 or 2 pixels, albeit with scalability) and vertical size equal to height of the entire screen.
• Movable Object Block, or MOB, was used in MOS Technology's graphics chip literature (data sheets, etc.) However, Commodore, the main user of MOS chips and the owner of MOS for most of the chip maker's lifetime, applied the common term "sprite", except for Amiga line of home computers, where MOB was the preferred term.
• The developer manuals for the Nintendo Entertainment System, Super NES, and Game Boy referred to sprites as OBJs (short for "objects"), and the region of RAM used to store sprite attributes and coordinates was known as OAM (Object Attribute Memory). This still applies today on the Game Boy Advance and Nintendo DS handheld systems. However, Nintendo Power referred to them as sprites in articles about the NES architecture in the magazine's third year.
• BOB, more often BLOB or 'Blitter Object', popular name for graphics objects drawn with the dedicated graphics blitter in the Amiga series of computers, which was available in addition to its true hardware sprites.
• Software sprites were used to refer to subroutines that used bit blitting to accomplish the same goal on systems such as the Atari ST and the Apple II whose graphics hardware had no sprite capability.
• The computer programming language DarkBASIC used the term Bob (for "blitter object") to refer to its software-sprite functions, before switching to the more conventionally used "sprite" term.
• Billboard or 3D Sprite is a term often used to refer to sprites that are essentially texture mapped 3D facets that always have their surface normal facing into the camera.
• Z-Sprite is a term often used for 3D environments that contain only sprites. The Z-parameter provides a scaling effect that creates an illusion of depth. For example, in adventure games such as King's Quest VI where the camera never moves, normal 2D sprites might suffice, but Z-sprites provide an extra touch.
• Impostor is a term used instead of billboard if the billboard is meant to subtly replace a real 3D object.

See also

• 2.5D
• Video games with isometric graphics
• Texture mapping

References