Jump to content

Sprite (computer graphics): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Eep² (talk | contribs)
Hardware sprites: made table sortable and use proper headers, fixed capitalization, links, etc
Eep² (talk | contribs)
m Hardware sprites: more capitalization/dupe link fixes, unnecessary bold removal
Line 36: Line 36:
In early [[video game|video gaming]], sprites were a method of integrating unrelated [[Windows and OS/2 bitmap|bitmap]]s so that they appear to be part of a single bitmap on a [[computer display|screen]].
In early [[video game|video gaming]], sprites were a method of integrating unrelated [[Windows and OS/2 bitmap|bitmap]]s so that they appear to be part of a single bitmap on a [[computer display|screen]].


The [[Blitter]] is a hardware implentation of the [[Painter's algorithm]]. For each frame the sprites are first [[bit blit]]ed (short for "bit block transfer") into the fast, large, double, and costly [[frame buffer]] and then the [[frame buffer]] is sent to the screen. The '''Blitter''' was renamed to [[graphics processing unit|graphics accelerators]] as more complicated rendering algorithms are used. The '''Blitter''' has a high initial cost for simple scenes.
The '''[[blitter]]''' is a hardware implentation of the [[painter's algorithm]]. For each frame the sprites are first [[bit blit]]ed (short for "bit block transfer") into the fast, large, double, and costly [[frame buffer]] and then the frame buffer is sent to the screen. The blitter was renamed to [[graphics processing unit|graphics accelerators]] as more complicated rendering algorithms are used. The blitter has a high initial cost for simple scenes.


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 texels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the # of sprites on a line), and costly [[cache]]s (the size of which limit the horizontal width) and as the [[pixel]]s are [[Genlock|sent to the]] [[screen]], these [[cache]]s are combined with each other and the [[background]]. It may be larger than the screen and is usually [[Tile-based game#Video games|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 (computing)|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 (computing)|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 penality for doing unaligned reads needed for rotation. This leads to the limitations of the known implementations:
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 texels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the # of sprites on a line), and costly [[cache]]s (the size of which limit the horizontal width) and as the [[pixel]]s are [[Genlock|sent to the]] [[screen]], these [[cache]]s are combined with each other and the [[background]]. It may be larger than the screen and is usually [[Tile-based game#Video games|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 (computing)|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 (computing)|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 penality for doing unaligned reads needed for rotation. This leads to the limitations of the known implementations:


{| class="wikitable sortable"
{| class="wikitable sortable"
Line 47: Line 47:
| [[Atari 8-bit family|Atari]], [[ANTIC]] || display list || || || 2,8 || 128, 256 || 1,3 || || || || || color key ||[http://www.atarihq.com/5200/5200faq/04_02.html]
| [[Atari 8-bit family|Atari]], [[ANTIC]] || display list || || || 2,8 || 128, 256 || 1,3 || || || || || color key ||[http://www.atarihq.com/5200/5200faq/04_02.html]
|- align=center
|- align=center
| [[C64]], [[MOS Technology VIC-II|VIC-II]] || display list run by [[CPU]] || 8 || || 12,24 || 21 || 1,3 || 1,2 || no || 1 tile layer || yes || color key || [http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_1.htm]
| [[C64]], [[MOS Technology VIC-II|VIC-II]] || display list run by CPU || 8 || || 12,24 || 21 || 1,3 || 1,2 || no || 1 tile layer || yes || color key || [http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_1.htm]
|- align=center
|- align=center
| [[Game Boy line|Game Boy]] || 40 || 10 || 80 || 8 || 8,16 || 3 || no || no || || || color key ||[http://www.at-mix.de/gameboy.htm]
| [[Game Boy line|Game Boy]] || 40 || 10 || 80 || 8 || 8,16 || 3 || no || no || || || color key ||[http://www.at-mix.de/gameboy.htm]
Line 70: Line 70:
|}
|}


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.
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.


=== Background ===
=== Background ===

Revision as of 02:17, 9 July 2007

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.

Development

Sprites were originally invented as a method of quickly compositing several images together in two-dimensional video games using special hardware. As computer performance improved, this optimization became unnecessary and the term evolved to refer specifically to the two dimensional images themselves that were integrated into a scene. That is, figures generated by either custom hardware or by software alone were all referred to as sprites. As three-dimensional graphics became more prevalent, the term was used to describe a technique whereby flat images are seamlessly integrated into complicated three-dimensional scenes.

Examples

File:SpriteExamplefromZeldaWindwalker.jpg
An example of sprite animation from the popular game The Legend of Zelda: The Wind Waker. In this frame the sprouts of grass and brown puffs of smoke are integrated into the scene using sprites. Other objects in the frame such as the character (Link), the flower just behind his feet, and the rock walls and ground are more complicated three dimensional objects that employ texture mapping.
File:SpriteExampleRevealed.jpg
A closer look at the graphic can help reveal imperfections of this rendering technique. Take a look at the puffs of smoke about the character and to the left. Notice that one sprite at the bottom of the largest puff of smoke is cutting into the ground, revealing its actual geometry is not an amorphous puff but a flat plane. Also notice that the grass near his feet is interacting with the flower near his feet in a strange way. The base of the grass is closer to the camera than the flower yet the blades appear to be behind. For this to be a correct perspective the grass would have to be leaning toward the ground away from the camera at an obtuse angle. Even though the original image that created the grass sprite was clearly created using textured polygons, it is being added to this scene as a sprite. These imperfections escape the notice of most viewers because they are rare, and often do not last very long as they and the camera move.

More often sprite now refers to a partially transparent two dimensional animation that is mapped onto a special plane in a three dimensional scene. Unlike a texture map, the sprite plane is always perpendicular to the axis emanating from the camera. The image can be scaled to simulate perspective, it can be rotated two dimensionally, it can overlap other objects and be occluded, but it can only be viewed from the same angle. This rendering method is also referred to as billboarding.

Sprites create an effective illusion when:

  • the image inside the sprite already depicts a three dimensional object
  • the animation is constantly changing or depicts rotation
  • the sprite exists only for a short period of time
  • the depicted object has a similar appearance from many common viewing angles (such as something spherical)
  • the viewer accepts that the depicted object only has one perspective. (such as small plants or leaves)

When the illusion works viewers will not notice that the sprite is flat and always faces them. Often sprites are used to depict phenomena such as fire, smoke, small objects, small plants (like blades of grass), or special symbols (like "1-Up"). The sprite illusion can be exposed in video games by quickly changing the position of the camera while keeping the sprite in the center of the view.

Sprites have also occasionally been used as a special-effects tool in movies. One such example is the fire breathing Balrog in The Lord of the Rings: The Fellowship of the Ring; the effects designers utilized sprites to simulate fire emanating from the surface of the demon. Small bursts of fire were filmed in front of a black background and made transparent using a luma key. Many bursts were then attached to the surface of the animated Balrog model and mixed with simulated smoke and heat waves to create the illusion of a monster made from fire.

The term "sprite" is often confused with low resolution 2D graphics drawn on a computer, also known as pixel art. However, in addition to pixel art, sprites can be created from prerendered CGI, dynamic 3D graphics, vector art, and even text. Likewise, pixel art is created for many purposes other than as a sprite, such as video game backgrounds, textures, icons, websites, display art, comics, and t-shirts. With the advancement in computer graphics and improved power and resolution, actual pixel art sprites are becoming increasingly infrequent outside of handheld game systems and cell phones.

Billboarding

Billboarding is one term used to describe the use of sprites in a 3D environment. In the same way that a billboard is positioned to face drivers on a highway, the 3D sprite always faces the camera.

Rationale

There is both a performance advantage and an aesthetic advantage to using billboarding. Most 3D rendering engines can process "3D sprites" much faster than other types of 3D objects. So it is possible to gain an overall performance improvement by substituting sprites for some objects that might normally be modeled using texture mapped polygons. Aesthetically sprites are sometimes desirable because it can be difficult for polygons to realistically reproduce phenomena such as fire. In such situations, sprites provide a more attractive illusion.

Alternative terms

  • 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.

Hardware sprites

In early video gaming, sprites were a method of integrating unrelated bitmaps so that they appear to be part of a single bitmap on a screen.

The blitter is a hardware implentation of the painter's algorithm. For each frame the sprites are first bit blited (short for "bit block transfer") into the fast, large, double, and costly frame buffer and then the frame buffer is sent to the screen. The blitter was renamed to graphics accelerators as more complicated rendering algorithms are used. The blitter has a high initial cost for simple scenes.

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 texels is limited by the memory bandwidth and the length of the horizontal retrace) into very fast, small, multiple (limiting the # 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 penality for doing unaligned reads needed for rotation. This leads to the limitations of the known implementations:

Computer, chip Sprites on screen Sprites on line Max texels on line Texture width Texture height Colors Anisotropic zoom Rotation Background Collision detection Transparency Source
Amiga, Denise display list 8 16 arbitrary 3,15 no no bitmap yes color key
Atari, ANTIC display list 2,8 128, 256 1,3 color key [1]
C64, VIC-II display list run by CPU 8 12,24 21 1,3 1,2 no 1 tile layer yes color key [2]
Game Boy 40 10 80 8 8,16 3 no no color key [3]
GBA 128 32 256 8 8 yes yes affine mapped tile layer alpha
NES, RP2C0x 64 8 64 8 8,16 3 no no 1 tile layer partial color key [4]
Out Run, dedicated hardware 128 32 8 8 yes no 3 tile layers alpha [5], [6]
PC Engine, HuC6270A 64 8 16,32 16,32,64 15 no no color key
Sega Master System
Sega Game Gear
64 8 8 8,16 color key [7]
Sega Mega Drive 80 20 320 8,16,24,32 8,16,24,32 15 no no 2 tile layers yes color key [8]
SNES 128 32 256 8 8 16 yes yes affine mapped tiles color key, averaging
Texas Instruments TMS9918 32 4 64 8,16 8,16 1 1,2 no 1 tile layer yes color key
Computer, chip Sprites on screen Sprites on line Max texels on line Texture width Texture height Colors Anisotropic zoom Rotation Background Collision detection Transparency Source

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.

Background

No sprite engine was implemented which would not cache the sprites texels, but use a FIFO at the pixel-output instead. This would allow sprites of arbitrary width. So while blitter based hardware uses a unified model for foreground and background and a fixed flat frame-buffer, sprites need a special background engine. It has to provide scrolling backgrounds for tile-based games and pseudo-3D (mode 7) backgrounds.

A similar discrimination is known from software rendering. A technique called "dirty rectangles" is used to redraw only those parts that have changed since the last repainted and a scrolling frame buffer is used. On more powerful CPUs the whole frame-buffer is flat and redrawn completely.

History

In the mid-1970s, Texas Instruments devised the first video/graphics processors capable of generating sprite graphics. The TMS 9918 video processors were first used in the 1979 TI-99/4.

The Atari 400 and Atari 800 systems were among the first PCs capable of generating sprite graphics, which Atari referred to as player/missile graphics (PMGs).

During most of the 1980s, hardware speed was in the low, single-digit megahertz and memory was measured in mere kilobytes. Beside CISC processors, all chips are hardwired. Sprites are rare in most video hardware today.

The CPU can 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 is not occupied by the simple task of transferring data from one place to another, software can run faster; and because the hardware provided certain innate abilities, programs that use CISC or BIOS were also smaller.

Separate locations in memory were used to hold the main display and the sprites. Some sprite engines could only store a small amount of positions in their registers and the unchallenged CPU was programmed to update them several times per frame. Software blitting was complicated by some very strange addressing modes into video ram.

Application

Sprites are typically used for characters and other moving objects in video games. They have also been used for mouse pointers and for writing letters to the screen. For on-screen moving objects larger than one sprite's extent, sprites may sometimes be scaled and/or combined.

Synonyms

Sprites have been known by several alternative names:

  • Player-Missile Graphics was used on the Atari 400/800 and Early Atari Coin Op games to refer to hardware-generated sprites. The term reflected the usage for both characters ("players") and other objects ("missiles"). They had restricted horizontal resolution (8 or 2 pixels, albeit with scalability, and a potential 192 lines of vertical resolution), limiting their use somewhat.
  • 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".
  • On the Nintendo Entertainment System, Super Nintendo Entertainment System, and Game Boy, sprites were referred to 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.
  • BOB's or 'Blitter Objects', 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.

Move to 3D

Prior to the popularizing of true 3D graphics in the late 1990s, many 2D games attempted to imitate the look of three-dimensionality with a variety of sprite production methods. These included...

  • Live Actors - The filmed performances of live-actors were sometimes used for creating sprites, most famously in the case of Mortal Kombat which added a relative element of realism to a gruesome fighting game. The method was used in a number of other fighting games, mostly in the mid 90s.
  • Claymation or the use of posable models which were used for characters that could not be portrayed by actors. Famous early examples include Goro of Mortal Kombat and various enemies from Doom. Used to a greater extent in games like Clay Fighter.
  • Pre-rendered CGI models - First seen in Nintendo's Donkey Kong Country and later used to a great extent in PC Real-time Strategy and RPG games prior to the move to true 3D. Since computers of the day could not run complex 3D graphics, footage of pre-rendered three-dimensional character models were often used which created (a relative) illusion of 3D.

Sprite culture

"Spriters" mostly use them to become sprite comic artists, for the purpose of creating a comic. It has been continued by Macromedia Flash animators who create sprite cartoons. In these communities, spriting has been made into small sections; recoloring, edits, customs, etc. Sprites can be alternated by using techniques such as the ones above. By doing this, Spriters can create their very own "Sprite character" to use in "Sprite sheets" to show that the sheet was made by that spriter but the spriter must put a "sprite tag" on the sheet saying something like "Please do not steal" or "give credit" or "If you wish to put this on your site, do not remove this tag", etc. Sprites can be edited from any game where sprites are available. Making pictures with sprites is called a "Hoax" which is the sprites in a group or doing certain actions but a "Hoax" is not a true image from a game.