| Sprite (computer Graphics) |
Article Index for Sprite |
Information AboutSprite (computer Graphics) |
|
Sprites were originally invented as a method of quickly compositing several images together in two-dimensional Video Game s 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. 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. Hardware sprites In early Video Gaming , sprites were a method of integrating unrelated Bitmap s so that they appear to be part of a single bitmap on a Screen . The Blitter is a hardware implementation 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 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 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 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: 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 CPU s the whole frame-buffer is flat and redrawn completely. Move to 3D ''. 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 .]] |
|
|