random and raster display technologies and the development of videogames

Random and Raster: DisplayTechnologies and the Developmentof Videogames

Nick MontfortMassachusetts Institute of Technology

Ian BogostGeorgia Institute of Technology

Videogame developers have utilized many types of display technology,from oscilloscopes to Teletypes to high-definition LCD displays. Twosignificant early display technologies, raster scan and random scan CRTs,played a significant part in the history and evolution of videogames.A study of these technologies shows how the choice of one or the other,and the need to port games between the two, influenced game designand prompted developers to innovate.

Many forces have shaped the development ofvideogame displays and influenced the designand functionality of games, not just theirappearance. The videogame display technolo-gies that were put to use, and the extentto which they were used, had a great deal todo with convenience and the ability to sourcedisplay components. Since early videogameimplementations, resolutions have increased,bulky video picture tubes have given wayto widescreen flat-panel LCD displays, andincreased computing power has allowedreal-time 3D graphics to replace 80-columntext displays. Conventional wisdommight as-sume that such changes amount to simpletechnological improvements.

Looking back over the history of gaming,however, reveals that different display technol-ogies have exerted creative force on the devel-opment of specific videogames. During thelast half-century, very different display tech-nologies have provided the ‘‘video’’ in video-games. For example, the very early gameTennis for Two used an oscilloscope, and earlytext adventures played on minicomputersoften used a Teletype or other print terminalto print output on paper. Sometimes the dis-play technology was imposed by the gameplay. For example, videogames played in thehome typically can’t rely on expensive or un-usual displays, so an ordinary television is usu-ally the most sensible display choice. But a

programmer writing a game for a PDP-1would have assumed that a text-output videoterminal or Teletype machine would be readyat hand, and a coin-operated (coin-op) arcadegame creator might have some flexibility inchoosing a particular type or orientation ofmonitor in the cabinet.Nomatter the type, dis-play technologies have exerted a strong influ-ence on the evolution of videogames.

From the end of the 1970s through the1980s, two fundamentally different displaytechnologies were in use side by side inarcades. The raster-scan display, which workedsimilarly to the pre-flat-screen TV (an electronbeam swept across and down the screen todraw the image), was used in Space Invaders,Berzerk, Pac-Man, Donkey Kong, Robotron: 2084,and many other coin-ops. Other systems usedrandom-scandisplays (also called vector graph-ics, stroke writing, and calligraphic), which ar-bitrarily pointed an electron gun. Atari usedthis technology, calling it XY graphics, whenit developed Tempest, Battlezone, Asteroids, andLunar Lander. (See the sidebar for more detailsabout specific games.)

In this article, we describe some of the in-teraction between early videogame develop-ment and display technologies, consideringthe influence of XY graphics in contrast tothe more familiar raster-scan system. In the1970s, both random and raster displayswere commonly used in many applications,

34 IEEE Annals of the History of Computing 1058-6180/09/$26.00 �c 2009 IEEEPublished by the IEEE Computer Society

Authorized licensed use limited to: KINGS COLLEGE LONDON. Downloaded on November 30, 2009 at 10:28 from IEEE Xplore. Restrictions apply.

and XY graphics systems presented them-selves as viable candidates for adoption incoin-op games like Asteroids and Star Castle.Often, random-scan types of displays offereda kind of high-resolution graphics unavail-able in raster displays—for example, bysmoothly scaling and rotating graphics in away that would otherwise have been diffi-cult, if not impossible.

Gaming brought both displays to a broadpublic and into contact with one another,along with new constraints. Differences be-tween the two systems meant that developersporting popular random-scan coin-op titleswere forced to deliberately evaluate game ele-ments, sometimes devising entirely newapproaches to similar high-level game con-cepts. When games that originally used vec-tor displays were ported to raster-basedhome systems, the practical differences be-tween the display technologies were revealedin a particularly interesting way—for exam-ple, this is the case with the home versionof Asteroids, developed for the Atari VCS(a.k.a. Atari 2600), and the Atari VCS gameYars’ Revenge, which was inspired by Star Cas-tle. By looking at Yars’ Revenge and Asteroidsin detail, we can see how developers modi-fied the games to account for the differentdisplay systems. Similarly, the home and ar-cade versions of Battlezone and Tempestshow how entirely new ways of depictingthe world on screen came about.

Random and raster displaytechnologies

Although all early arcade games used CRTs,those in vector-graphics games are wireddifferently than the ones in standard TVs.

The electron beam does not sweep across thescreen from left to right, being turned onand off as it makes its way down and thenreturns back to the top 60 times each second.Instead, the electron gun is pointed at a cer-tain location, turned on, and moved fromthat (x, y) coordinate to another point in astraight line, where it is turned off again. Anoscilloscope functions similarly; it just deflectsthe electron beam using electrostatic force. XYmonitors use magnetic force.

Just as a storage device that is arbitrarily ac-cessible offers random access, random scanuses a beam that can be made to move any-where. Such systems directly draw lines inan (x, y) coordinate system. Raster-graphicssystems, on the other hand, draw a grid ofdata representing a pattern of pixels. If thecorrespondence between bits and pixels isone to one, the data is a bitmap; more gener-ally, such data is a pixmap (p. 13).1 As a result,it is possible to render detailed bitmappedimages on a raster system, but a vector systemmakes it much easier to scale, shear, and ro-tate shapes that have been drawn with theprimitives of that system.

In the 1980s, other differences betweenthe two types of displays included the acces-sibility of color and black-and-white rasterdisplays, the better brightness and resolutionof vector displays, and the limited number ofprimitives that could be drawn on a vectordisplay before it began to flicker. Videogamesystems were not the first to explore the usesof either type of display. Both had beenemployed in computer graphics for a whilebefore commercial videogaming came about,and by the mid-1970s, raster graphics had be-come dominant (p. 12).2

Further Reading on Videogame HistoryWe have not individually cited each well-known and

well-documented historical fact (such as the release yearsof popular videogames) because such detail is outside thescope of this article. For general information on videogamehistory, we suggest several books.1�5 There are also helpfulresources easily found online, such as the longstandingKiller List of Videogames (http://www.klov.com) and theproject MobyGames (http://www.mobygames.com).Information about the basic functioning of games can beeasily determined by playing the games themselves.

Although certain information on the history of video-games, both online and in print, might be less than reli-able, basic information about which companies andprogrammers developed popular games is not usuallyin dispute.

References

1. V. Burnham, Supercade: A Visual History of the

Videogame Age 1971�1984, MIT Press, 2003.

2. R. DeMaria and J. Wilson, High Score!: The

Illustrated History of Electronic Games, Osborne/

McGraw-Hill, 2002.

3. W. Forster, The Encyclopedia of Game Machines,

Gameplan, 2005.

4. S.L. Kent, The Ultimate History of Video Games,

Prima, 2001.

5. B. Weiss, Classic Home Video Games, 1972�1984,

McFarland, 2007.

July–September 2009 35


The building blocks of Star CastleProgrammer Howard Scott Warshaw’s first

assignment at Atari was to port the 1980vector-graphics arcade game Star Castle, pro-duced by Cinematronics, to the Atari VCS.He told an interviewer, ‘‘I soon realized thata decent version couldn’t be done, so I tookwhat I thought were the top logical and geo-metric components of Star Castle and reor-ganized them in a way that would bettersuit the machine.’’3

Warshaw’s comment reveals how the plat-form participates in the ecology of gamedevelopment. The design of the resultinggame, Yars’ Revenge (1981), was not entirelydetermined by the Atari VCS, nor was itdropped on the platform by its programmerwith no concern for how the system worked.The original idea was to imitate anothergame, but the capabilities and limitations ofthe Atari VCS led the developer to createsomething different. Specifically, the resultwas a reorganization of Star Castle’s majorcomponents that recognized the differencesbetween vector and raster graphics, exploitedthe abilities of the Atari VCS graphics system,and was well-suited to home play.

The Atari VCS has a graphics system thatwas unusual even for the time. To keepcosts down, the unit lacked a frame buffer,a memory region in which the screen imagecould be set up and blitted across automati-cally. Instead, programmers had to writecode that would set up each individual scanline for the television interface adapter(TIA). The registers for two player sprites,two one-pixel missiles, one one-pixel ball,and the playfield had to be ready on eachline of the screen so the electron beamwould have the appropriate objects ready todraw. For this reason, the challenge of pro-gramming the Atari VCS was sometimes re-ferred to as ‘‘racing the beam.’’

Warshaw explained in another interviewhow radical it was for Atari to drop StarCastle, which the company had alreadyarranged to license:

I did something no one else had ever done, I

went to my boss and said that I had an idea

for an original game that would use the

same basic play principles of Star Castle but

was designed to fit the VCS hardware so it

wouldn’t suck. And to their credit, they let

me go with it. Think about that. They blew

off a license to let me pursue an original con-

cept with the promise of making a better

game for the system. That would never hap-

pen today.4

A hit arcade game would have already had afollowing, one that might have generated en-thusiasm and an initial market. Even in theearly days of videogaming, when the arcadehits were Pong and Tank rather than Pac-Man, an arcade game’s fan following was im-portant when it came to the home consolemarket. Given the differences in platformand the need to rewrite each game fromscratch, a port to the Atari VCS had plentyof room to become a fairly involved adapta-tion rather than a straightforward re-creation.This could leave some arcade game fans dis-appointed, as happened with Pac-Man.

Cinematronics, the developer of Star Cas-tle, was the first company to release an arcadegame that used the XY graphics display tech-nology: Space Wars (1977). Like the first ras-ter arcade game, Nolan Bushnell’s pre-AtariComputer Space, it was a two-player arcade im-plementation of the 1962 PDP-1 programSpacewar.2 Star Castle had significantly differ-ent game play and was developed by a differ-ent person, but the space setting and controlscheme showed a clear connection to SpaceWars.5

Vector-graphics systems have certainadvantages over raster-graphics systems—atleast, they did in the late 1970s and early1980s. Specifically, it is easier to rotate shapesand scale them up or down on a vector sys-tem, as is necessary when zooming in orout. For instance, to resize an object that iscentered on (0, 0) and consists of some setof lines, each endpoint’s coordinates can sim-ply bemultiplied by the scaling factor. It doesnot get much trickier when the object is cen-tered elsewhere or when there should be dif-ferent amounts of scaling in the horizontaland vertical axes. It is also straightforwardto shear a shape, keeping one axis constantwhile shifting the other. Rotation, scaling,and shear are the basic linear transforma-tions, and all can be accomplished by sub-jecting the coordinates of a shape’s pointsto a single matrix multiplication. In combi-nation with translation (the displacement ofthe shape in space, which only requires add-ing the distance to be translated), these allowfor all the possible transformations that keepstraight lines straight.

In a raster-graphics system, the only feasi-ble way to show an object’s rotation is to dis-play a different bitmap—a hard-coded imageof the shape rotated by the desired amount.This is how tanks and planes in the AtariVCS game Combat are rotated, for instance.A simple form of scaling is supported in

History of Computer Games

36 IEEE Annals of the History of Computing


hardware, via the TIA’s specialized number-size registers, but smoother zooming has tobe done with new graphics. Even when XYgraphics hardware is not used, these benefitsof vector graphics can be seen when compar-ing software platforms, such as an earlyversion of the bitmap-based MacromediaDirector and an early version of Macro-media’s vector-graphics Flash environment.

Vector-graphics games used the specialcapabilities of the display system to goodeffect. Battlezone is a classic example of agame that uses the scaling capability tomake tanks larger, so that they appear to beapproaching. Asteroids, on the other hand,makes more prominent use of the rotationfacility.

The smash hit AsteroidsThe original Asteroids arcade game, devel-

oped by Ed Logg and based on a concept byLyle Rains, was released in 1979. Other hitgames that year were Atari’s first vector-graphics game, Lunar Landar, and Namco’shit game Galaxian. The arcade Asteroids is in-teresting to compare to its Atari VCS port,which came out in 1981, the same year thatYars’ Revenge came out for that console.This comparison demonstrates how a gamecan have a different appearance and functionwhen it is created for a raster instead of a vec-tor display.

Although the ship can move freely aboutthe screen in Asteroids, the game is organizedradially around the ship, which must be theplayer’s center of attention and which can ro-tate and fire shots in all directions. With itsspace setting, its rotating and firing ship,and its controls, Asteroids also shares severalfundamental qualities with Spacewar, SpaceWars, and Star Castle.

Brad Stewart, who had earlier portedBreakout to the Atari VCS after winning theright to port the game by besting a fellowprogrammer in the arcade Breakout, went onto develop the VCS Asteroids. Both the VCSgame and the coin-op game purport to beAsteroids, and they feature a rotating ship,rocks breaking up into smaller rocks, and fly-ing saucer enemies. The arcade game uses thecapabilities of the vector display beautifullyand works well in the situation of the arcade,while the cartridge exhibits classic VCS qual-ities that connect to home gaming traditionsand the TIA’s affordances.

Players use five buttons to control the ar-cade Asteroids: a pair for rotating clockwiseor counterclockwise, a pair to control thrust

Asteroids’ arcade

original and Atari VCS

port reveal how

different display

technologies predispose

designers to develop

different sorts of games.

and fire, and a hyperspace button that is setbelow the others—exactly the same five but-tons as on Space Wars. Star Castle had the firstfour controls, but not the hyperspace button.In Asteroids, the monitor is oriented horizon-tally and the playing field’s topology is thatof a torus: objects wrap around verticallyand horizontally. This is the same as in StarCastle and is one option that can be selectedin Space Wars.

One difference between Star Castle and thearcade Asteroids is the color overlays, whichplace the central cannon in a circle of yellowand the protective shield around it in a ringof red. (Color overlays were not used exclu-sively on XY games; Space Invaders cabinetshad them, too.) Asteroids lacked such coloredtransparencies. The game originally used amonochrome monitor, the ElectrohomeG05-801, a 19" monitor made by Wells-Gardner Electronics and previously used inLunar Lander (p. 9).6 Without overlays, animage on this monitor appears as whitelines on black. The asteroids are drawnmore dimly, and move about in arbitrarydirections. The ship and flying saucers aredrawn more brilliantly, and the shots firedfrom either are particularly luminous points.These aspects—along with high contrast,sharp lines, and a fast refresh rate—makeAsteroids visually impressive in a way that ishard to imagine when looking at an emula-tor, screen shot, or diagram.

A player can immediately recognize theVCS Asteroids as a version of the arcadegame. It boasts similar game play, visual ap-pearance, and sound. The minor differencesare telling, however. The asteroids are filled-in and sometimes flickering masses that aredrawn in different colors rather than asmonochrome outlines—assuming that the



Atari VCS is set to color and a color TV is usedas a display. The ship is also solid, and it firesat most two shots at once—not the four thatare possible in the arcade game. Althoughemulators have been able to make the VCSAsteroids conveniently available on computers,they use sharp, blocky pixels that were notseen in the same way by players in the early1980s. CRT televisions blur pixels togetherresulting in something that was clearly differ-ent from a vector-graphics display, but whichis also softer and fuzzier than an LCD display.7

The two versions of Asteroids, the arcadeoriginal and the Atari VCS port, reveal howdifferent display technologies predisposedesigners to develop different sorts of games.Visually, the solid, colored, blocky rocks ofthe VCS version show that the TV is capableof color and that it is at least as easy tomake a bitmapped sprite solid as to make itappear in outline—easier, actually. The differ-ent jags of the arcade Asteroids, defined onlyby lines, reveal what a vector-graphics system

can do in a straightforward way. The motionof the asteroids is also telling. On the ran-dom-scan display, their vectors of movementare random—any direction is possible. Onthe left-to-right sweeping raster display ofthe TV, there is a predisposition to up-or-down motion because the asteroids cannotmove horizontally.

From a port to Yars’ RevengeThe object of Star Castle is to destroy the

rotating cannon in the center of the screenrepeatedly, using a triangular, rotating shipthat looks and moves like the ones in Aste-roids and Space Wars. The enemy cannonappears behind colored overlays and is sur-rounded by three concentric, rotatingshields, each of which is made of line seg-ments. The segments can be destroyed byfire from the player’s ship, but whenever anentire ring is shot away, it regenerates. When-ever the player clears a path to the cannon,creating a chance to shoot at it to destroy it,the cannon fires a large missile toward theplayer’s ship. As the player is trying to breakdown the shield rings, three mines alsomove out and seek the player’s ship. Theycan be avoided or shot, although shootingthem does not increase the score and theysoon reappear. After a central cannon is finallysuccessfully destroyed, another one quicklyappears with three intact rings around it.Star Castle fared well among the several hugearcade hits released in 1980 (including Pac-Man, Defender, Centipede, and Missile Com-mand), though it didn’t attain as much fame.

In the Atari VCS game inspired by Star Cas-tle, Yars’ Revenge, the player’s ‘‘ship’’ is theYar, a ‘‘fly simulator’’ that the player controlswith a joystick. The game replaces the pivot-ing of the ship about a point, which couldeasily be done by Star Castle’s vector-graphicsdisplay system, with movement in the stan-dard eight directions—up, down, left, right,and diagonally. The latter form of movementwas fairly easy for the Atari VCS: translationwhile facing in one of eight directions. TheYar sprite is animated, requiring an additionalframe for each direction, but its appearancefacing right is a reflection of what it lookslike facing left, allowing some savings. Be-cause up/down reflection is not as straightfor-ward as left/right reflection on the Atari VCS,the upward-facing and downward-facing Yarsprites are both laid out in ROM. Switchingbetween the two requires reading a differentbitmap. The insect appearance of the Yar (seeFigure 1) was simply based on what Warshaw


Figure 1. Screens shots from (top) Star Castle and (bottom) Yars’

Revenge. The inset show details of the two ships and qualities of the

different display technologies used.



could draw and animate in an appealing waywithin a player sprite. The name Yar wasdevised by spelling Atari CEO Ray Kassar’sfirst name backwards.

The objective in Yars’ Revenge is the Qotile,which moves up and down along the rightside of the screen and is protected by a shield.All the levels are similar in form, but the firstone (and all the odd-numbered levels) have astationary, rounded shield around the Qotile,while the other levels (all the even-numberedones) feature a block of shield with piecesthat move left to right, down a space, rightto left, down a space, and then right to leftagain through the block. The motion of thepieces mimics that of the CRT’s electrongun as it sweeps across and back while mov-ing down the screen.

Beyond the basic redesign of the gameplay and the graphical advances that weremade, there were a few other innovations—minor, but telling—in Yars’ Revenge. Someof these, such as the addition of a rudimen-tary pause command, show how game soft-ware could allow a fixed hardware platformto evolve and suit the needs of home players.Others demonstrate how some of the lumi-nous effects of a vector display game wereadapted, but not directly translated, into araster-graphics display game.

Yars’ Revenge features a large, four-part dis-play routine that includes one part to drawthe swelling explosion that ends a level; an-other to display the score; another to drawthe shield for half the frames of the mainsequence; and a final one to draw, in alter-nating frames during the main sequence,the multicolored neutral zone. Althoughthe neutral zone and shield bears little resem-blance to Star Castle’s spinning, concentricshapes, they create a striking effect thatmakes use of the console’s different videosystem.

The neutral zone’s random-looking pat-terns are not provided by a pseudorandomnumber generator—an intricate algorithmthat, although deterministic, is complexenough to create a sequence that looks ran-dom. Such an algorithm can be implementedon the Atari VCS and was used in Activision’sPitfall, but this programming solution exactsa price in ROM (the code itself must be storedsomewhere) and in cycles (the code must berun while the game is also carrying out thework of drawing the screen and updatingthe game state). The alternative is to lay outa random-looking pattern in ROM and sim-ply load random-seeming bytes from this

small entropy pool, one adequate to createan appropriately irregular visual display.Such an approach takes fewer cycles, but itrequires that some random-looking pattern,perhaps a fairly large one, be stored inROM. If such a pattern were to be added,something else in the game would have hadto be removed, and there was already lessthan a handful of bytes free in the finishedYars’ Revenge.

Warshaw used the second technique, buthe made use of a random-looking sequenceof bytes that would already be laid out inROM by the time the game was finished—thegame’s code itself—as shown in this 6502 as-sembly code obtained by disassembling thecontents of cartridge ROM:8

EOR (neutralZonePtr),Y

AND neutralZoneMask

STA PF2

AND #$F7

STA COLUPF

In this part of the neutral zone kernel (the firstinstruction is located at $F084), the valuespointed to by neutralZonePtr are broughtinto the accumulator and masked against thecontents of neutralZoneMask. This accumu-lator value is used first as the pattern that isloaded into a playfield register and, after it ismasked again, as the playfield color. Thelabel neutralZonePtrpoints to the same ad-dress as does another label, gameTimer. Atthis location, a count is stored that is continu-ally incremented, once each line, and rangesover the addresses in cartridge ROM. This pro-gressionworks its way through the code of theYars’ Revenge cartridge, with each byte of codebeing loaded, transformed, and displayed onthe screen. The bytes in ROM end up beingused in three contexts: as executable code,playfield graphics, and the playfield color.When theQotile is hit, those bytes also supplythe random-looking arrangement of the full-screen explosion. These effects certainly donot come from Star Castle, and there is noobvious way they could be duplicated on avector-graphics display.

Warshaw has explained that he hadplanned to use this method from the startrather than working it out as a solution to aproblem that came up: ‘‘It was just a cheapway to get the effect I wanted. I didn’t havethe time or space to do it any other way.’’5

Still, bymaking the game’s code into an impor-tant visual component in this raster-specificway,Warshaw showed how a functioning pro-gram could shine aesthetically. When players



Vector art paved the

way for modern 3D

graphics, suggesting a

way to represent solid

objects in 3D space

and animate them

in real time.

look at the neutral zone on the screen, they areliterally looking at the code. Yars’ Revengemay not have had any direct influence onthe movie Tron, which brilliantly playedwithvector- and raster-graphics conventions,but that film was released the summer afterWarsaw’s game and features a multicolored,whirling master control program (MCP) thatis cast in a different light by the neutralzone, actually drawn again and again by itsown image, a code-and-data Janus.

Warshaw’s ‘‘original’’ was a brilliant varia-tion on Star Castle, played in virtuoso style onthe Atari VCS.His skill in creatingYars’ Revengeis not just seen in his programming chops andcreativity, but also in his ability to innovateand improvise while building down from thetop (an already completed vector-graphicscoin-op gamewith a working gamemechanic)and up from the bottom (a platform thatoffered a particular set of affordances and wasused in the context of the home). While Aste-roids shows that even a fairly direct arcadeport encountered differences in display tech-nologies,Warshaw’s work exemplifies anotherway of navigating between display technolo-gies and letting the capabilities of the displaysuggest design directions.

Zooming through BattlezoneEd Rotberg designed Atari’s tank game Bat-

tlezone (1980) while he was working onanother vector-graphics game, Red Baron,which let the player fly a biplane and wasreleased soon after Battlezone. Although theplane game offered more degrees of freedom,it didn’t match Battlezone’s popularity as thefirst 3D game to reach a mass audience. Atthe time, tank games were not new; theearly, raster-graphics arcade hit Tank, pro-duced by Kee Games, offered one-on-one

tank fighting and set a precedent for Battle-zone. It was also the inspiration for Combat,the tank game that came with the Atari VCS.9

Earlier, in 1974, two 3D networked gameshad been developed. Maze was developed byGreg Thompson, Dave Lebling, and othersat MIT and based on work done at NASAAmes. That year, Spasim was also developedby Jim Bowery at the University of IllinoisUrbana-Champaign. The former ran on anImlac terminal with a vector-graphics display,and the latter used the PLATO-IV’s plasmadisplay panel. While impressive, these gamesrequired tremendous computing resourcesand did not reach a large number of players.

Although it had these illustrious ances-tors, Battlezone was revolutionary in manyways. The game brought together 2D tankmotion (along the flat plane of the ground)with a first-person view onto a 3D world. Bat-tlezone not only featured an unusual perspec-tive, it also had an unusual periscope cabinetconfiguration that let players (if they weretall enough) place their heads directly againsta viewport while others could watch from ei-ther side. Besides the essential elements (3Dopponents and sound effects), the landscapedetails included an erupting volcano.

Battlezone found popularity with the mili-tary, which was uncommon for the time. TheUS Army contracted with Atari to develop amodified game to train Bradley Infantry Fight-ing Vehicle gunners. This project was contro-versial inside Atari; apparently only twoprototypes and a few units weremade. Beyondthis application, Battlezone also entranced ageneration of players, some of whom went onto develop other 3D, first-person games. Oneyoung player who particularly enjoyed Battle-zone was John Carmack, who went on to be-come the lead programmer at iD Software,the company that pioneered the first-personshooter genre with Wolfenstein 3-D (1992),Doom (1993), and Quake (1996) (p. 20).10

Adaptations of Battlezone to the Atari VCSagain reveal how game developers used rasteraffordances differently. Atari’s port, also ti-tled Battlezone, is an adequate game, but the3D tank game that was developed by Activi-sion, Robot Tank (1983), added weather, dif-ferent types of partial damage, and day andnight, all of which use raster-specific effects.When the arcade Battlezone tank gets hit, anirregular vector-graphics tree makes it appearas if the glass of the monitor has cracked.When the player’s vehicle is destroyed in ei-ther Atari VCS game, gray, random shiftingmakes the TV screen look like it is losing




reception and starting to display snow. Thevector-graphics visual signal for death is ras-terized in these two tank games into some-thing more suitable for that display andmore easily accomplished with the console’sgraphics system.

The space trading strategy game Elite,released for BBC Micro personal computersin 1984, was notable for using wireframe 3Dgraphics with hidden line removal—the linesbehind surfaces were not drawn so that struc-tures appear solid. This technique evolved inother games, including the Battlezone-liketitle Spectre for Macintosh computers, releasedin 1991. The line-rendering technique quicklyevolved from wireframes to filled surfaces totexture-mapped surfaces, which appeared inthe early 1990s in Wolfenstein 3-D and UltimaUnderworld. Vector art paved the way for mod-ern 3D graphics, suggesting a way to representsolid objects in 3D space and allowing the de-velopment of feasible methods to animatesuch objects in real time. Today, 3D polygonsare rasterized for display in pixel form on amodern computer or TV monitor, but thebasic way that shapes appear in 3D spacecould already be seen by players zoomingthrough Battlezone’s vector landscape.

Tempest turningTempest, designed by Atari’s Dave Theurer

and released in 1981, used a different sort ofmonitor: the Wells-Gardner 6100 Quadras-can, a color display with three beams forred, blue, and green. Along with Atari’sSpace Duel, Tempest was in the first wave ofcolor vector-graphics games. The game alsoallowed players to choose the level wherethey wanted to begin; this poor man’s con-tinue feature let more capable players jumpto more challenging levels, while novicescould select an easier stage. In addition, Tem-pest offered differently shaped levels, so thatthe terrain and the challenges varied as theplayer progressed.

To allow the game’s monsters to movearound, Tempest took advantage of the easewith which objects can be rotated in an XYframework. It used scaling to make it appearthat enemies were moving forward and grow-ing larger. And as those enemies moved overuneven terrain, Tempest exploited the XYgraphics hardware’s ability to shear thecreatures.

The much later Tempest 2000, released in1994, uses raster and vector idioms. In this ver-sion, a tube’s rasterized wireframe, represent-ing the landscape of a level, rotates before the

player who is preparing to start the game.When a level is selected, that shape moves to-ward the player and the empty spaces betweenlines solidify, planes of color filling the tube ina raster-specific way. The player’s ship and theearly opponents look more or less like vectors,but this changes as the game revealsmorepow-erful creatures. The typography is empatheti-cally bitmapped and sometimes dissipatesacross the screen. Finally, the game includes anew type of level, the warp stage, that offersrings to fly through and a background thatlooks like nothing an XY graphics systemcould produce.

Although Tempest 2000 transforms the ar-cade original into an updated raster game, italso hints at the earlier vector-graphics qual-ities of Tempest, both to make a connectionto its arcade inspiration and as a way of evok-ing nostalgia for the random-scan tubes ofyears past. The game shows that although aTV cannot convincingly imitate a vector-graphics display, it can be made to remediatesuch graphics and remind the player of theoriginal display system, rather than com-pletely replacing the vector idiom with a ras-ter one, as with Yars’ Revenge and Asteroids.

Raster and random, bitmap and vectorVideogames of the late 1970s and early

1980s are strongly associated with vectorgraphics. In recent years, we have seen atrend to re-create this ‘‘vector look’’ in con-temporary games that are made to seemretro. New commercial games have been cre-ated that borrow the geometric appearance ofvector graphics even though they are notplayed on XY displays. The most commer-cially successful of these titles is GeometryWars, originally an Xbox shooter released in2003 that combines the simple geometricshapes of games like Asteroids with psyche-delic shader effects afforded by modern 3Dgraphics acceleration. In games like GeometryWars, the use of a simple triangular ship andabstract geometric enemies references thegame’s vector predecessors. Other games,such as Tempest 2000 developer Jeff Minter’sXbox 360 game Space Giraffe, released in2008, borrow the tube shooter dynamicsdescended from Tempest but use vector-styleline art as only a small part of the visuals,which include 3D shader and bloom effects.

Systems with vector-graphics displays pro-vided developers with some capabilities thatwere not available a decade later. Thanks tothe popularity of their vector games, Atarideveloped a general computing system to



aid in their creation. The Atari Analogue Vec-tor Generator (AVG) is a special set of chipsused to run the graphics systems of Asteroids,Battlezone, Tempest, Gravitar, and Star Wars.The AVG, which went through several ver-sions, facilitated numerous useful operationsfor vector rendering. These included drawinga vector from the current cursor position to anew (x, y) position, positioning the cursor atthe center of the screen, setting the color andintensity for new vectors, and program flowoperations such as jumps and subroutines.2,5,11

Of course, Tempest 2000, Geometry Wars, andother reimaginings of vector games were notable to use such hardware. Those gamesrequired that new software subsystems becreated to simulate the vector effect in raster-or polygon-based graphics systems.

Vector art has persisted and evolved incomputer graphics in other ways as well.Just as vector shapes allowed game develop-ers to enact translations and scaling effectswith ease, other forms of computer art bene-fited from mathematical representation. Vec-tor displays have allowed higher-resolutiongraphics than would have been possible atthe time of Asteroids.

Bandwidth became a limitation in latereras. On the early Web, slow dial-up connec-tions conflicted with users’ increasing expec-tation for rich graphics and animations, atrend begun by GUI operating systems andmultimedia CD-ROMs. Here vector graphicsoffered a solution as well. Because vector artis drawn based on a few parameters ratherthan being rendered as pixmaps, a PC can eas-ily bemade to drawmany frames of an anima-tion from instructions rather than data. Thesesets of instructions take up less memory andrequire that less data be sent over the network.

Such a factor was primary in the design ofFutureSplash Animator (1996), the programthat became Macromedia Flash and thenAdobe Flash. Macromedia’s other popular an-imation product, Director, had been designedfor use as CD-ROM and desktop software anduses raster graphics primarily to present pho-torealistic effects. Thanks to the widespreadadoption of broadband Internet service, bit-map art is more frequently used in Flashcompositions because it can be renderedfairly efficiently on today’s computers. Thedistinction between raster- and vector-basedrepresentation is one that continues to affectnot only what we see on the Web, but alsohow geographical data is abstracted in geo-graphic information systems (GISs), where adebate between the two styles is ongoing and

conversion between them is often necessary.The importance of these two hardware displaysystems continues to extend beyond the com-mercial life of random-scan CRTs and the pres-ence of XY graphics games in arcades.

ConclusionThe random-scan display technology has

faded, and even the once-ubiquitous raster-scan CRTs are rapidly yielding to flat-scan dis-plays. Nevertheless, these displays left theirtraces directly and indirectly onmany differentgames, including some of the most influentialhome-console and arcade titles. And many ofthe important concepts behind the two differ-ent systems live on today in software.

Today’s modern techniques for 3D graph-ics descend partly from early vector wireframetechniques. XY graphics display hardware iscertainly not in widespread use, but XY(and XYZ) ways of thinking have becomeprevalent because of changing graphicscapabilities and because of software systemssuch as Flash.

Consideration of the two display systems isno doubt important for understanding the his-tory of videogames. The way in which the dif-ferent technologies supported and constrainedgame development sheds light on contempo-rary and past development practices and howthey relate to computer hardware. Beyondthat, the healthy competition between ran-dom and raster, and the interesting challengesthat prompted developers to innovate whenmoving between the two systems, suggestthat standardization is not always ideal. Amonoculture of videogame displays (or otherhardware) might be convenient, but workingon and across different technologies can pro-voke new, striking developments.

Acknowledgments

The text of this article from ‘‘The buildingblocks of Star Castle’’ through ‘‘Serving upYars’ Revenge’’ has been adapted from chapterfive of our book Racing the Beam (MIT Press,2009).Thisbook is the first in thePlatformStud-ies book series (http://www.platformstudies.com) the authors are coediting at theMITPress.

References and Notes

1. J.D. Foley et al., Computer Graphics: Principles

and Practice, Addison-Wesley: 1996.

2. It’s at least amusing to note that Computer

Space, the first arcade game, was a raster

adaptation of a game that ran on a Type 30

Precision CRT display, a random-scan display.




Pong was originally developed for the TV.

Although there are probably more compelling

reasons for Pong’s commercial success, which

greatly outstripped that of Computer Space,

these two games do provide examples of one

unsuccessful ‘‘port’’ from one display technol-

ogy to another and one successful game that

was done with a specific display in mind.

3. S. Stilphen, ‘‘Interview with Howard Scott

Warshaw,’’ Apr. 2005; http://www.digitpress.

com/archives/interview_warshaw.htm.

4. H.S. Warshaw, interview by J. Weesner, Apr. 2007.

5. T. Skelley, ‘‘Tim Skelley’s History of Cinema-

tronics,’’ June 1999; http://www.dadgum.com/

giantlist/archive/cinematronics.html.

6. J. Novak, Game Development Essentials: An

Introduction, Thompson Delmar, 2004.

7. Z. Whalen, ‘‘Lost in Emulation: World of Differ-

ence in Videogame Typography,’’ Proc. 3rd Ann.

UF Game Studies Conf., 2007.

8. D. Debro, ‘‘YarsRevenge.asm,’’ Disassembly of

Yars’ Revenge with labels and comments added,

21 Sept. 2005.

9. Although the 2D combat tank games corre-

sponded to the 3D, first-person Battlezone,

Rotberg’s other game, Red Baron, can be seen

as a 3D version of the combat biplane games.

10. D. Kushner,Masters of Doom, Random House, 2003.

11. See also http://www.coinop.org/kb_dl.aspx/KB/

gametech/atari_xy.html, 2007.

Nick Montfort is an associ-

ate professor of digital media

at the Massachusetts Institute

of Technology. He collabo-

rates on literary projects and

writes poems, text generators,

and interactive fiction such

as Book and Volume and Ad

Verbum. Montfort has a PhD in computer and in-

formation science from the University of Pennsyl-

vania. Contact him at [email protected].

Ian Bogost is a videogame

designer, critic, and researcher

as well as an associate profes-

sor at the Georgia Institute

of Technology and founding

partner at Persuasive Games.

His research considers video-

games as an expressive me-

dium, and his creative practice focuses on games

about social and political issues. Bogost has a

PhD in comparative literature from the Univer-

sity of California, Los Angeles. Contact him at

[email protected].

For further information on this or any other

computing topic, please visit our Digital Library

at http://computer.org/csdl.



random and raster display technologies and the development of videogames

Documents