Jump to content

Blitter object: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
added other computers' blitters, and the fact that bobs are no longer used
Line 1: Line 1:
A '''Bob''', for ''BLitter OBject'', was a graphical element (GEL) on an [[Amiga]] computer. Bobs were [[sprite (computer graphics)|hardware sprite]]-like objects, movable on the screen with the help of the [[blitter]] [[co-processor]].
A '''Bob''', for ''BLitter OBject'', was a graphical element (GEL) first used by the [[Amiga]] computer. Bobs were [[sprite (computer graphics)|hardware sprite]]-like objects, movable on the screen with the help of the [[blitter]] [[co-processor]].


The Amiga GEL system consisted of VSprites, Bobs, AnimComps (''animation components'') and AnimObs (''animation objects''), each extending the preceding with additional functionality. While VSprites were a virtualization of hardware sprites Bobs were drawn into a playfield by the blitter, saving and restoring the background of the GEL as required. The Bob with the highest video priority was the last one to be drawn, which made it appear to be in front of all other Bobs.
The [[AmigaOS]] GEL system consisted of VSprites, Bobs, AnimComps (''animation components'') and AnimObs (''animation objects''), each extending the preceding with additional functionality. While VSprites were a virtualization of hardware sprites Bobs were drawn into a playfield by the blitter, saving and restoring the background of the GEL as required. The Bob with the highest video priority was the last one to be drawn, which made it appear to be in front of all other Bobs.


In contrast to hardware sprites Bobs were not limited in size and number. Bobs required more processing power than sprites, because they required at least one [[Direct_memory_access|DMA]] memory copy operation to draw them on the screen. Sometimes three distinct memory copy operations were needed: one to save the screen area where the Bob would be drawn, one to actually draw the Bob, and one later to restore the screen background when the Bob moved away.
In contrast to hardware sprites Bobs were not limited in size and number. Bobs required more processing power than sprites, because they required at least one [[Direct_memory_access|DMA]] memory copy operation to draw them on the screen. Sometimes three distinct memory copy operations were needed: one to save the screen area where the Bob would be drawn, one to actually draw the Bob, and one later to restore the screen background when the Bob moved away.


An AnimComp added animation to a Bob and an AnimOb grouped AnimComps together and assigned them velocity and acceleration.
An AnimComp added animation to a Bob and an AnimOb grouped AnimComps together and assigned them velocity and acceleration.

Later models of the [[Atari ST]] featured a blitter that was similar to the Amiga's, but it was introduced well into the ST's life cycle and was not in widespread use. The [[Atari Lynx]] also featured a blitter.

Modern graphics hardware has progressed to a point where the 'blitter object' concept is redundant. After describing a graphics layer, to render it, save part of its contents, then restore it every refresh would be profoundly inefficient. Instead, modern hardware is designed to simply redraw the entire screen (containing perhaps thousands of objects) every frame. In modern graphics theory, a 'texture' replaces all the functions of a Bob.


== References ==
== References ==

Revision as of 09:15, 10 March 2006

A Bob, for BLitter OBject, was a graphical element (GEL) first used by the Amiga computer. Bobs were hardware sprite-like objects, movable on the screen with the help of the blitter co-processor.

The AmigaOS GEL system consisted of VSprites, Bobs, AnimComps (animation components) and AnimObs (animation objects), each extending the preceding with additional functionality. While VSprites were a virtualization of hardware sprites Bobs were drawn into a playfield by the blitter, saving and restoring the background of the GEL as required. The Bob with the highest video priority was the last one to be drawn, which made it appear to be in front of all other Bobs.

In contrast to hardware sprites Bobs were not limited in size and number. Bobs required more processing power than sprites, because they required at least one DMA memory copy operation to draw them on the screen. Sometimes three distinct memory copy operations were needed: one to save the screen area where the Bob would be drawn, one to actually draw the Bob, and one later to restore the screen background when the Bob moved away.

An AnimComp added animation to a Bob and an AnimOb grouped AnimComps together and assigned them velocity and acceleration.

Later models of the Atari ST featured a blitter that was similar to the Amiga's, but it was introduced well into the ST's life cycle and was not in widespread use. The Atari Lynx also featured a blitter.

Modern graphics hardware has progressed to a point where the 'blitter object' concept is redundant. After describing a graphics layer, to render it, save part of its contents, then restore it every refresh would be profoundly inefficient. Instead, modern hardware is designed to simply redraw the entire screen (containing perhaps thousands of objects) every frame. In modern graphics theory, a 'texture' replaces all the functions of a Bob.

References

Rob Peck (1986). ROM Kernel Reference Manual: Libraries and Devices, Addison-Wesley, ISBN 0201110784

See also