CA1284226C - Collission detection system for video system - Google Patents

Collission detection system for video system

Info

Publication number
CA1284226C
CA1284226C CA000549402A CA549402A CA1284226C CA 1284226 C CA1284226 C CA 1284226C CA 000549402 A CA000549402 A CA 000549402A CA 549402 A CA549402 A CA 549402A CA 1284226 C CA1284226 C CA 1284226C
Authority
CA
Canada
Prior art keywords
objects
array
movement
data
collision
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CA000549402A
Other languages
French (fr)
Inventor
George Edward Logg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Midway Games West Inc
Original Assignee
Atari Games Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Atari Games Corp filed Critical Atari Games Corp
Application granted granted Critical
Publication of CA1284226C publication Critical patent/CA1284226C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55Controlling game characters or game objects based on the game progress
    • A63F13/57Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game
    • A63F13/577Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game using determination of contact between game characters or objects, e.g. to avoid collision between virtual racing cars
    • A63F13/10
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45Controlling the progress of the video game
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/42Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of patterns using a display memory without fixed position correspondence between the display memory contents and the display position on the screen
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/12Picture reproducers
    • H04N9/16Picture reproducers using cathode ray tubes
    • H04N9/22Picture reproducers using cathode ray tubes using the same beam for more than one primary colour information
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60Methods for processing data by generating or executing the game program
    • A63F2300/64Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60Methods for processing data by generating or executing the game program
    • A63F2300/64Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car
    • A63F2300/643Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car by determining the impact between objects, e.g. collision detection

Abstract

ABSTRACT OF THE DISCLOSURE
There is disclosed herein a system for rapid processing of the data records of many moving and nonmoving objects on a playfield only part of which is displayed and for determining collisions between objects. Slips point to the first objects on the list for the current scan line speed up the search process.
The collision detect process is speeded up by only checking the nearest neighbors on the playfield in the path of movement and by organizing all the moving and nonmoving objects on the playfield in a two dimensional array mapped to the approximate position of display of the object on the playfield.

Description

lZ84226 COLLISION DETECTION SYSTEM FOR VIDEO SYSTEM

BACKGROUND OF THE INVENTION
The invention pertains to the field of processing of data records for objects to be displayed on a video display. More particulacly, the invention pertains to the field of video-game processing of a plurality of objects on a playfield to determine which ~ objects are vi6ible on the portion of the èlayfield being diselayed and which objects have collided with other objects.
As video games have become more complex and sophisticated they have pcogres6ed to multiple player game6 with multiple character6 in conflict with multiele other entities with the battle taking place on ever more complex elayfields. 8ecau6e 6tandard video display ciccuitry is used to diselay all this action, and because there are a large number of moving and nonmoving objects on such playfields there have developed severe limit6 on the complexity of the game than can be depicted. This is because the amount of time in which to decide which objects are to be displayed on a particular scan line and which objects have collided with other objects is limited by the amount of time the video proce6sing circuitry take6 to 6can the raster lines in the image. Since this 6canning is a fast process, the amount of time to eroce66 the data describing each object to make deci6ion6 about it is limited. Ultimately, this limits the number of object6 that a 6y6tem can handle and thereby limits the number of objects and plAyers that the system can successfully coee with.

Accocdingly, a need has arisen for a video game processing system that can rapidly handle large numbers of objects and player ineuts to cause mo~ion in desiced dicections of some of said objects and which can rapidly detect collisions between many such objects and many othec objects on the playfield.
Fucthec, a need has arisen for a video game system which can gracefully handle multi stame motion objects which ace lacgec than one stame wide and one stamp tall. A stame is a gcoue of pixels and lines, genecally rectangulac and genecally 8 eixels wide and 8 scan lines tall, which is used to erovide the shaee of the motion object. The pixels ace wcitten with data words which define the color or shade of gray at each location in the stame to define the identity of the motion object by its shaee. Heretofore, motion objects have been only one stame wide. This limits the size and complexity of character shaees which could be drawn on the screen because the number of pixel~ available for coloring was too small to define truly comelex chacactec shaees. Thus, as the sophistication of game users has incceased, thece has acisen a need to be able to provide - them with moce coloc~ul and comelex character sha~es.

SUMMARY OF THE INVENTION
According to the teachings of the invention there is provided a video system which can process a large numbec of moving objects undec the contcol of multiple users and a large number of nonmoving objects within the timing constraints imposed by the video image producing circuitry. In the preferred embodiment, the video game system comprises a central CPU which runs the main game program implementing the rules of the game and which reads user control inputs indicating desired movements ----------------------------------------------.

' . " ~ ` ' --, lZ84ZZ6 of the characters and which controls other objectsdisplayed on the screen. The action takes place on a playfield of which only a portion is displayed. The various moving objects and nonmoving objects which are part of the game are all placed on the playfield. The moving objects are moved in response to either user control inputs or in response to commands from the computer under the control of the main program to move the objects to create the conflict in the game. The conflict in the game i8 irrelevant to the invention and may be between the main characters and monsters or between the objects which the players control and other objects that the main processor controls or nonmoving obstacles. The CPU continuously evaluates the positions of the moving objects and stores data records describing both the moving and the nonmoving objects, including their positions relative to a reference eoint on the playfield, in a two dimensional array in a random access memory which will hereafter be refe~'red to as the array RAM. Each location in the array maps to a certain area on the playfield. Contiguous array locations map to contiguous areas in the playfield. The nonmoving objects such as walls on the piayfield are also stored in the two dimensional array as dummy motion object records which are not on the linked list but which are stored at array locations corresponding to the position where they would appear on the playfield. Hereafter, the portion of the playfield which is displayed will be referred to as the window. The dummy motion object recordsonly ~ the x and y locations of the nonmoving objects and may or may not contain a dummy picture pointer. The actual picture pointer for the nonmoving object is stored in another array in the array RAM which is accessed during a time slot devoted to eainting the playfield picture (hereafter called the playfield picture array). The picture pointer is the address in read only memory whete the actual gcaehic information defining the apeearance of the object is S stored. In the preferred embodiment, each array location foc the motion object and dummy motion object data records (hereafter called the collision detect array) maes to a box on the elayfield that is 16 pixels wide and 16 lines tall.
The moving objects in the collision detect array are linked by an ordered, linked list but this linking is not relevant to the collision detect feature of the invention. It is only an element of the invention that increases the speed of display processing which determines which of the motion objects will be visible in the window. The ordering of the list is such that the objects appear on the list in the order they would be displayed if the entire playfield was diselayed in raster scan fashion from left to right and top to bottom. In embodiments where raster scanning is not used, the linked list need not be ordered in this fashion. When the moving objects move, the linked list is reordered by the computer during its time slot for access to the array RAM to maintain the proper order in the linked list.
The video game system processes the data records in the array RAM in time multiplexed fashion. A
time slot will be given to the CPU to read records from or write records to the array RAM. During this time slot the CPU does any of the following things: it builds the array databases (there is a colligion detect array, a playfield picture array, an alphanumeric array and a slip table or array), it moves objects per user commands by changing the eosition offset field in the '` 1284226 cecord to reflect the object~s new position relative to a playfield reference point (usually the upper lef t corner of the elayfield) it updates the a~ray entries to change the links on the linked list and change the slip table entcies oc to move object cecords to the pcopec locations in the collision detect accay when the objects have moved oc it ceads data cecocds of objects that have been moved and neighbocing objects foc collision detect ecocessing. The tecm ~slip~ as used herein means a starting link pointer or link to the corcect object data cecocd on the linked list where pcocessing foc any ~acticular raster scan line is to start.
Another time slot is devoted to access of nonmoving objects foc pucposes of displaying the walls and oc othec nonmoving objects which form part of the playfield landscape. Another time slot is devoted to access of the alphanumecic data foc display of information on the screen regacding the score or other textual material.
Another time slot is dedicated to linked access to the next motion object on the linked list either through use of the link from the last object processed or by use of a slip. The slip table lists the places on the linked list where "hit" processing should start on each raster scan line to determine which motion objects are in positions to appear on the scan line. The slip table is updated by the CPU during its time slot whenever the order of the linked list is changed.
Access into the slip table is generated by decoding data including the current scan line number being processed in the current window. The ---------------------------~ . J

~Z84226 slip data is accessed fcom the slip table in the alrayRAM and latched into a link register at the beginning of the scan of each new caster scan line.
The last described time slot is devoted to accessing data eecords from the linked list describing the y positions foc the motion objects. This data is used to do y hit erocessing to determine if there is a possibility that the object will appear on the current scan line. If a y hit is found, the pointer to the graphic data for the motion object is retrieved and the x position of the object is examined to determine if there is an x hit, i.e., the object is located along the visible portion of the x axis on the ~layfield which is currently being displayed. Each data record has x and y coordinate data describing the position of the motion object relative to a reference point on the playfield.
Each data recocd also has a link field containing a pointer to the next record on the linked list. To avoid needless processing of data records for objects that will not be visible, access to the data records at the correct point in the linked list is gained by using the slip pointing to the first motion object on each scan line, and, thereaftec until the end of the line, by using the links to continue processing. At the end of Z5 each line, a signal is genecated by a state machine/sync generator controller logic to cause the slip address to be updated to its new value and to be latched into the link register for use in access to the linked list at the proper point for pcocessing the next line.
Every time a motion object is to be moved, a collision detect process must be performed to determine if the movement would result in a collision with either another motion object or a nonmoving object on the playfield. The CPU performs this process in a raeid .

~2a9~226 manner by compacing the position of the object to be moved to the positions of only and at most the nearest objects in the path of movement since the motion object obviously will not have collided with any objects not in S the path of movement. To do this the CPU uses a two dimensional collision detect array of data records describing the relative positions of the moving and nonmoving objects on the playfield and accesses the records of only the closest objects in a s~ecific pattern that lies in the path of movement and which will intersect said path of movement. The position data in the data records so accessed are then com~ared record by recocd to the position data of the object to be moved.
Both the x and y coordinates of all the objects in the array are expressed in offsets from the reference point on the playfield so that the comparison process does not have to wait for the whole array to be rewritten every time the window changes position.
The comparison is done by subtracting the x position of the first record in the pattern from the proposed new x position of the object to be moved and testing the absolute value of the result to determine if the result is smaller than a specific, constant number.
If the result is not smaller than the specific constant, then the y position comparison is skipped, and the next record in the pattern is retrieved and the comparison is started on the new record. If the result of the x comparison for the first record is smaller than the constant, the y positions are compared in the same manner. If the absolute value of the result is smaller than the constant~a collision has occurred and all further record comparisons are stopped since the moved object need only collide with one thinq to trigger collision processing. If the absolute value of the '` lZ842Z6 result is not smaller than the constant, the next record foc an object in the pattern i6 retrieved and the position comparison process continues.
Once a collision has occursed, the CPU
S determines ~a~ motion object has collided with which other object and the proper course of action to take foc that type of collision. For example, if a laser blast motion object has collided with an attacking monster, the eroper course of action may be to make the monster disappear. If a monster motion object has collided with the character being manipulated by a player, the eroeer course of action may be to make the character die or lose health, power etc. If the collision was between a character and a wall on the playfield, the proper course of action may be to make the character's motion in the direction of the wall stop at the wall. The proper course of action may differ in different embodiments to implement different rules of play.
According to the teachings of the invention~
multi stamp motion objects are provided. Motion objects may consist of an array of stamps up to 8 stames wide and 8 stamps tall. ~4e ~ach motion object record on the linked list consists of four words, one of which is the address of the first stamp in the array of stamps. The other words of the motion object's data record contain the motion object's vertical and horizontal size, the horizontal and vertical positions and the link to the next motion object. During each scan line~a chain of motion object data records are examined by logic that compares the y position of the motion objects to the y position of the current scan line, both positions being expressed in playfield relative terms. The comparison circuitry delivers a number which is the row number for the stamp in the motion object array containing the .
.:
- ' ~ ` .

~ '' " . .

lZ84Z26 g cucrent scan line. The row number of the ~tamp and the horizontal size infocmation i8 used to look up or calculate a motion object stamp offset number. This is the stamp number of the first stamp in the array on the row containing the current scan line. Each array of stamps is numbered with the stamps in row 1 numbered 1, 2, 3 .. up to 8. The first stamp in the second row will then be numbered as the next number in the sequence following the number for the last stamp in row 1. A
countec then counts as each stamp is processed to provide the relative address of succeeding stamps in the current row. The motion object~ picture field also contains a field which is the actual address in the graphics ROM of the ficst stamp in the array. This address is added to the offset from the first stamp number of the current stamp number.
The comparison circuitey also delivers a number which represents the actual scan line in the current stamp which is being scanned. This information plus the actual addre6s of the current stamp in ROM derived from the above described circuitry is used as an address to access a ROM where the graphic data in the form o~ a pixel pattern for that type of motion object is stored.
The correct pixel pattern is then latched into a shift register and shifted bit by bit into the line buffer being loaded in preparation for scanning the next line.
All the foregoing process is done one line time ahead of the time of actual scanning of the line and is stored in one of a pair of "ping pong" line buffers in waiting for the actual scanning process. The other ping pong buffer stores the pixel pattern that is actually being scanned at any pacticular moment Accocding to another aspect of the teaching of the invention there is provided a lookahead feature for .

~284226 erocessing the linked list of motion objects to determine which will be visible in the current window.
In the prefe~red embodiment of the invention, a synchronous state machine in the form of a ROM coupled to a sync generator and to several status signals is used to generate the control signals which control the time slots for multiplexing of addresses for the ar~ay RAM and the latching of output data f~om the array RAM.
The status signals which are input to the state machine indicate the match or no match condition for the vertical and horizontal eosition comparisons between the current motion object~s position and the scan line being painted in the cur~ent window. These status input signals to the state machine also indicate several other things when the end of processing of all the stamps on one row of a motion object has occurred; when the end of each scan line is reached; and, when the state machine is entering its first cycle of 7 basic time slots which are used in looking for hits and doing other things.
The state machine has a foreground cycle of 7 time slots where various addresses are selected and various data is written to or read from the RAM.
The foreground cycle is generally for the purpose of processing the linked list records to determine which motion objects at or beyond the slip pointer address are to be displayed on the current line.
Each motion object is processed first for a y hit. This means that for an object which is a "hit", i.e., will be visible, the y position is such that part of the object is supposed to appear on the current scan line. If there is a y hit, the motion object is processed for an x hit in another time slot of the foreground state machine cycle. This x hit processing is to determine if the x position of the object and the x position of the window and the horizontal size of the object are such .~r ~28~226 that the object is supposed to at least pactially appear on the cu~rent scan line.
Since the erocess of processing a multistamp motion object to retcieve the gcaphic data foc sevecal stamps on the cuccent line takes some time to comelete, the state machine also has a background-cycle. This cycle is entered each time a status signal indicating that the stamps of a ecevious motion object are still being erocessed to load the graehic data into the line buffer. The pueeose of the background cycle i8 to continue processing of the next motion objects on the linked list ollowing the motion object last processed in the foreground states. The background processing howevec is limited to detecmination of which motion object on the linked list has both a y hit and an x hit. No pictuce pointec is retcieved for any motion object having a y hit and an x hit found in the background state. Only the focegcound states retcieve pictuce data.
To pecform its function, the backgcound cycle continues pcocessing the motion objects fucthec down the list from the motion object which is curcently having its gcaphic data loaded into the line buffer so as to implement a lookahead function. When the background ~tates find the next motion object with both~x and~y hit (in some cases, one foceground state is also involved in the lookahead function), erocessing goes into a hold mode wheee the backgcound ~tates continue to cycle in looking at the hocizontal position of the motion object which was found, but no new motion objects ace erocessed. Thi~ holding continues until the focegcound states and the associated ciccuitcy finish loading all the pictuce data fcom the ociginal motion object into the line buffec as signaled by one of the status -B

.. ...
'` .. , " ~za~z26 `

signals. The foreground cycle is then re-entered, and the picture pointer is retrieved for the object so located in the background states. This pointer is used to access the graphic data from the graphics ROM for the new motion object. If this motion object is more than one stamp wide then, as soon as this graphic data loading process commences, the status signal indicating that the graphics ROM and shift registers are busy with the graphic data loading process ~c4m~4_5cu~, and the background cycle is re-entered to continue the lookahead process. A motion object which is only one stamp wide can be processed and loaded to the line buffer in one complete foreground cycle of 8 time slots, at the rate of one time slot per pixel. The background cycle is entered only if the motion object to be displayed has more than one stamp horizontally which will be visible.

Brief DescriPtion of the Drawinqs Figures lA and lB are a block diagram of the ci~cuitry implementing the teachings of the invention.
Figure 2 is an illusteation of the conventions used in describing the positions on the playfield of motion objects and playfield objects, the cucrent window position and the stamp arrays of the objects on the playfield.
Fiqure 3 is an illustration of the collision detect array in the arcay RAM.
Figures 4A and 4B are block diagrams of the vertical and horizontal match circuits and the stamp offset calculation circuits.
Figure 5 is a state diagram of the foreground cycle.
Figure 6 is a state diagram of the backgcound cycle.

~13-Figure 7 is a flow diagcam of the collision detect algorithm.
Figure 8 is a symbolic diagram of the conventions and tests used to determine the presence of collisions between objects on the playfield.

Detailed DescriPtion of the Pceferred Embodiment Referring to Figures lA and lB, there is shown a block diagram of a system according to the teachings of the invention. For convenience, the reader may wish to cut both Figures lA and lB along the cut line and assemble them as one figure. These two figures will be hereafter cefereed to as Figure 1. Such a system has utility in a video game or other application where large numbecs of moving objects must be displayed on a screen and/or where collisions among them during the movements must be detected.
A computer 20 runs a main erogram stored in working ROM 22 to do various functions for the system.
The main proqram implements the particular rules of the game, and causes the comeuter 20 to perform input/output operations to read user control input data from user controls and interface unit 24 and is given in Appendix A. The user control interface unit is of known design and is not critical to the invention. It provides one or more user control sets such as joysticks, fire buttons, magic buttons etc. In the preferred embodiment, four user control sets are provided, and the computer 20 reads data from them either by interrupt vector processing or by polling of the controls. In the preferred embodiment, polling i8 used. The particular rules of the game implemented by the main program such as what happens when a monster collides with a character or what happens when a character~s shot or other form of . ~ .
..
- , assault collides with a monster are not critical to the invention. The teachings of the invention are broadly applicable across the video game market and, in fact, may be useful in other fields such as processing radar or sonar imaqes with large numbers of moving targets where collision or proximity must be detected.
In the preferred embodiment, the system of Figure 1 is used in a video game involving fou~ main characters which move and fight aqainst multiple moving monsters. Some of the characters shoot rays or bullets and these also are displayed as moving objects. All this action takes place on a playfield which is essentially a maze with walls, treasures, food, keys and other stationary and nonstationary objects placed therein. All of these moving and nonmoving objects have data records stored in a database comprised of several arrays in the array RAM. Each of the records in the database describes certain attributes of the object.
Among these attributes for each object are the horizontal and vertical position on the playfield.
In the preferred embodiment, the playfield has multiple levels each of which are different. The information as to the configuration of each level and the locations of the various nonmoving objects on each level is stoced in a wocking ROM shown as part of memocy 22. The computer uses data feom this ROM to build a two diménsional playfield array in the array RAM 32. Each nonmoving object record in the playfield array also has a dummy motion object entry in the collision detect two dimensional array in the proper array location that corresponds to the position of the object on the playfield. This dummy entcy has the x position and y eosition data of the object and may or may not have a picture pointer. The presence or absence of the picture -, ~28~ 26 pointer is icrelevant to the invention. The pureose of this dummy entry is to complete the collision detect array with all the moving and nonmoving objects on the playfield so that collision detect processing can be done from one array. `The nonmoving objects in the collision detect array may or may not be part of the linked list.
In the preferred embodiment, only a portion of the playfield is displayed. This portion of the playfield will be hereafter called the window. The playfield has a reference point which can be anywhere but which is usually its upper left cocner. The window also has a reference point, and it also can be located anywhere in the window but is usually located in the upper left corner. There may be as many as 10Z4 moving and nonmoving objects scattered about the playfield at any particular time, but only some of them will be visible in the window. The positions of the moving and nonmoving objects are expressed in terms of their offsets from the reference eoint on the playfield. In the preferred embodiment, the window location is moved to keep the four main characters visible at all times.
In other embodiments, the window may remain stationary or may follow the movements of some but not all the main characters. A DajOr function of the system of Figure 1 is to determine which of the moving and nonmovinq objects on the playfield will be visible in the window.
The system is aided in this process by the fact that the positions of all the objects on the playfield are expressed as playfield relative offsets.
The computer 20 is responsible for creating the database for all the objects and updating the database when the position of the objects change. As the term is used herein, the database is comprised of several arrays ~2`8~6 and tables. There is a collision detect two dimensional array, a playfield two dimensional array, an alphanumeric two dimensional array and a slie table in an otherwise unused part of the alphanumeric array. The database also contains data regarding the current score for each player and the current eosition of the window.
All these array entries and other data are updated by the computer. For example, the computer is responsible for calculating the new eosition of the window and for updating the data records which indicate where the window is currently located. Also, the computer updates the data records regarding the current score. The computer is also responsible for determining when collisions between objects in the database occur when one or all objects involved in the collision move too close to the other object or objects.
Because the display is to be on a video color monitor, the speed at which each scan line is traced by the electron beam sets the basic time limit du~ing which all processing of objects to determine which are to appear on the particular scan line must be completed.
5ince each scan line is traced in a very short time, there is a need to process the objects in the database with great efficiency to be able to finish processing them in sufficient time.
Because of the limited time available far processing objects, both the moving and the nonmoving objects are stored in the RAM 3Z as part of the two dimensional collision detect array where each location is physically mapped to a corresponding area on the diselay, This data organization allows the collision determinationfi made by the computer 20 to be made in a more expeditious manner by only checking the nearest objects in the direction of movement.

' `' .
.

lzs4æz6 ( To speed up processing to detecmine which objects are to be visible in the window, the moving objects in the database are oeganized as a linked list.
The link organization is set by the computer 20 to approximate the order in which the objects would appear if the entire playfield were displayed in raster scan fashion. When the objects move, the computer 20 changes the links on the list to adjust the order of the list to again correspond to the physical order of appearance of the objects. To maintain the physical mapping that is necessary f or the collision processing, the data record of the objects which have moved must also be moved to the addresses in the RAM which correspond to the array location which maps to the object's current location in the window on the playfield.
The known synchronization signals needed by the video display 26 are generated by a sync generator 28 which is driven by a pixel clock 46. These sync signals also serve as a basis to generate basic timing signals used to clock the system. Some of these clocking signals are coupled to a state machine 30 and are used in conjunction with other status signals as address signals for a ROM which implements the state machine.
The state machine serves to generate the control signals which control the other circuitry in the system for address selection and latching of data coming out of the RAM. The truth table of the state machine 30 is qiven in Appendix B.
The database of records f or the moving and nonmoving objects is stored in an array RAM 32. The address inputs 34 to this RAM 32 are controlled by a multiplexer 36. The multiplexer has one output coupled to the address input port of the RAN 32 and several inputs coupled to various sources f or addresses. The ~Z8~2~6 state machine generates the select signals to cause the multiplexer to select one of the several inputs for connection to the output bus 34 during each of the 7 basic time slots in the time division multiplexing of the system.
The seven basic time slots established by the state machine will be explained in greater detail later when the state diagrams of the state machine 30 are explained. Basically, the time slots so that one time slot allows the computer 20 to access the database RAM
to build or revise the database. Another time slot allows alphanumeric information to be displayed on the screen at specified locations such as the score of each player and other information about the game. Another time slot allows the link address to the next motion ob~ect to be loaded to enable continued "hit" processing to determine if the next ob~ect on the linked list is ~o be visible. Another time slot allows the vertical position of the current motion object to be examined for a ~y hit~. Another time slot allows a slip pointer address to be loaded which points to the correct position on the linked list to begin processing for the current window position to determine which objects will be visible.
Because the data which emerges from the RAM
during each of the time slot~ is transitory, a series of latche~ are provided to store the data temporarily. A
latch 38 stores the vertical position data of the motion ob~ect record which has currently been retrieved from the RAM 32. This motion ob~ect is retrieved when the ~tate machine either causes the slip address to be selected or the link address to be selected by the multiplexer 36. The slip address is comprised of a few bits from the alphanumeric address input on line 40 concatenated with the window vertical address on line 42. The link address is the address on the line 44.

,'~....

lZ~34226 The slie is used to save time in processing the motion objects on the linked list to detecmine which will be visible at the current window location. ~ecause the linked list includes all the motion objects on the S entire playfield but the window only displays a fraction of the total playfield, the slip is used to vector the y hit processing to the propee point on the linked list to start processing. This prevents y hit processing of data records for objects which are so ~ar above the window that there is no possibility that they will be visible in the window. There is a slip for every 8 scan lines in the preferred embodiment. Each slip points to the fiest motion object on the linked list that would appear on each group of eight scan lines.
lS There are 64 slips in the preferred embodiment, and they are stored in an otherwise unused portion of the alphanumeric two dimensional array in the array RAM
32. The proper slip in the slip table is accessed by selecting the window vertical address on line 42 with the proper bits of the alphanumeric address on line 40 and applying them to the address bus 34. The slip then appears and is latched into the link to next motion object latch 48. This process occurs once per scan line. It is caused when the select signals on lines 50 and 52 assume states which indicate that the beginning of a new scan line is at hand, as signaled by the signal on the line S0, and when the signals on line 52 indicate that the state machine is ready to get the link to the next motion object.
A latch 54 is used to store the motion object horizontal position data when the state machine 30 causes same to be accessed. Each motion object record is comprised of 4 words. These words cannot all be placed on the data bus 56 at the same time, and the link -1;~8~

addcess on line 44 is the index into the motion object record. When the data desired by the state machine resides in one of the other words, the state machine changes the bit pattern on the motion object control bus 58 (M.O. CTL) to select the desired wocd. The state machine is also coupled to the clock or load inputs of all the latches so that the proper one of them can be enabled to load the data then present on the data bus 56. These are the structures that allow the state machine to access the horizontal position data for the motion object pointed to by the link address (or slip) to appear on the data bus 56 and to store it in the latch 54.
The eart of the motion object record which comprises the address in ROM of the graphic data or actual pixel pattern for the motion object is stored in the latch 60.
The position on the playfield of the particular scan line being processed is tracked and stored in the window vertical counter 62. This counter is loaded with the playfield relative scan line number of the toe of the window from a particular storage location in RAM
which is kept updated with the current vertical location by the computer 20. This scan line number is loaded into the counter 62 at the beginning of every frame by a signal (not shown) from the sync generator or the state machine. The counter 62 counts up from this scan line number each time the HSYNC signal from the sync generator 28 occurs. The actual signal used to cause the counting by the counter 62 is not the actual hocizontal synchronization that causes the flyback after every line i8 painted on the display but is a digital signal derived therefrom.

~284;~26 The addre~s of the playfi~ld stamp in the graphics ROM for the cu~rent electeon beam position in the window is accessed by the state machine by causing the multiplexer 36 to select the address window veetical S on line 42 and window horizontal on line 64. The address bits on these two lines define the cucrent electron beam position on the playfield in terms of an offset from the reference point on the playfield. When this address is selected)the playfield picture stamp address i8 outeut from the array ~AM 32 and is latched into the plarfield picture latch 64. The playfield picture addresses are stored in a two dimensional array in the array~RAM 32 which is organized so the array locations map to corresponding areas on the display.
The graphics data for the playfield stamps and the motion object stamps is stored in the graphics ROM
64. When the address of a motion object or playfield stamp is presented as an input on a bus 72, the graphics ROM delivers the graphics data on the graphics data output bus 74. This graphics data is routed through a multiplexer 76 under the control of the state machine.
The data is routed to either the playfield shift register 78 or the motion objec-t shift register 80 depending upon what type of graphics data is being output. The shift registers shift the graphics'data out serially for use in painting the particular scan line ~being processed. In the case of the playfield shift regi6ter 78, the data is shifted out on line 82 as digital video information to a color priority and mapping circuit 84. This circuit receives as inputs, digital, serial information on the lines 82, 86 and 88.
The data on the line 86 comes from either line buffer A
or line buffer B in the line buffer circuit 90. The digital data on the line 86 is motion object data which , ....

,,~, .....

~284226 was shifted into the line buffer so by the motion object shift register 80 via a line 92. This occurs for line buffer B while line buffer A is being displayed and occurs for line buffer A when line buffer B is being displayed. The data on line 86 is the motion object data for the line currently being displayed. The digital data on line 82 is the playfield data. The shifting is done under the contcol of a SHIFT signal from the sync generator 28 so as to be synchronous with movement of the electron beam across the scan lines.
The digital video data on line 88 caceies the pixel patterns for the alphanumeric information that is to be displayed.
In the priority and mapping circuit 84, the incoming serial, digital, video data is prioritized and a decision is made as to which information will be displayed for each particular playfield location that is visible in the window. There may, for any one playfield location, be several items that must be displayed. For Z example, alphanumeric information, a motion object and playfield wall may all be independently shifted into the circuit 84 for display at the location. Not all these items may be displayed there, so the circuit 84 decides which item to display and sends the proper digital video information to the digital to analog conversion, scan and display circuitry 26. The circuit 84 also adds . . .
color information to the data stream based upon the color palette information in the data records for the playfield and motion object data records. The palette data is stored i.n a portion of one of the words of both the motion object and the playfield data records. The design of the color priority and mapping circuit is game dependent, not ccitical to the invention and conventional and will not be detailed herein.

-z3-The alphanumeric information to be displayed on the screen is stored in an alphanumecic array in the array RAM 32. This information i8 kept current by the computer 20, and is accessed by selection of the alphanumeric addeess on line 40. The alphanumeric address is expressed in window relative terms as an -offset of the current electron beam position from a reference point in the window, usually the upper left hand corner. When this address is selected. the address of the alphanumeric graphic information for that particular window position is accessed from the array RAM 32 and latched in the alehanumeric latch 66. This address is output on the line 68 to the alphanumeric ROM
70 where the actual graphic data is stored. This causes the actual pixel eattern for the earticular alphanumeric stamp accessed to be loaded in parallel format into an alphanumeric shift register 94 and to be shifted out on line 88 synchronously with movement of the electron beam across the screen.
The addresses supelied for shifting of serial, motion object video data into the line buffers 90 are supplied by a playfield offset horizontal match circuit 98. This circuit has as its ineut the motion object horizontal position data on the bus lOo and the x position of the edge of the window on bus 102. The information on the bus 102 is sueplied by a window horizontal counter/latch 104. The circuit 104 serves to store the current x position of the edge of the window in a latch and to count up pixel positions from the edge of the window upon reCeipt of pixel clock signals on line 106. The current x position of the edge of the window is stored in the latch portion of the circuit 104 by the computer 20 via the data bus 106 and the address bus 108 of the computer. Data is loaded into the x .

~28~:26 location latch o~ the ciecui~ 104 ~hrough CPU buffe~ 110 enabled by the computer addres6 bus. The window horizontal counter 10~ presets to this x location, ex~ressed in ~layfield celative terms, at the end of each scan line. Any suitable ci~cuitcy to imelement this preset function may be used, e.g., a p~eset signal based upon HSYNC OL upon eeaching a p~edetermined count indicating the end of the scan line has been reached.
The playfield offset horizontal match circuit ~ 98 also receives data regarding the horizontal size of the motion object. From the horizontal position data, the circuit 104 generates a horizontal match or x hit signal called HMATCH on line 99 which is sent to the state machine. The horizontal match circuit 98 also uses the horizontal size data and the horizontal position data and generates an END signal on line 101.
This signal is transmitted to the state machine 30 to indicate when the last horizontal stamp graphic data in a motion ob;ect's àrray of stamps on a particular scan line is being shifted into the line buffers 90. This END signal indicates to the state machine that it is permissible to re-enter the foreground state from the background state. The END signal also means that it is permissible to continue to access and process data records for other motion objects on the linked list and to use the graphics ROM 64 for loading the pixel data into the line buffer since the graphics ROM is no longer tied up in accessing graphic data for the previous motion object. The horizontal position data of the edge of the window and the motion object are also used to generate the window relative positions of the motion objects to be shown on the current scan line being stored in the line buffers 90. This screen relative position is sent on the address bus 112 to the line buffer to control loading thereof. The details of this ~Z84Z26 horizontal match circuit 98 will be descri~ed in more detail below.
When the computec Z0 wishes to update any information in the array RAM 32, the data bus 106, address bus 108, buffer 110 and a CPU latch 112 are used to store the data to be written into the RAM. The latch 112 is loaded for input and enabled for outeut of the stored data onto the data bus 56 by control signals from the state machine (not shown) during t~me slots devoted to CPU access to the array RAN 32.
A vertical match and stamp offset address calculation ciecuit 114 serves to process the motion object vertical position and size data with data regarding the vertical position of the current playfield scan line to determine whether a particular motion object is to be displayed. This circuit 114 also calculates the stamp number of the first stamp in the motion object's array of stamps in which the current scan line lies. Reference to Figure 2 will clarify this last statement. Figure 2 (not to scale) shows a typical position of the display window 116 in a playfield 118 and shows the typical size for one stamp of video graphic data and shows a typical 6 x 6 stame motion object 120 (the maximum size for a motion object in the preferred embodiment is an 8 x 8 array of stamps).
Motion objects have their x and y locations expressed in terms of the playfield rela~ive position of the first stamp in the lowest (most positive y coordinate) row of stamps in the motion object's array of stamps relative to a reference point 123 at the lower left corner of the playfield. In the case of the motion object 120. the position of stamp 37 is stored in the array RAM as the number of scan lines up the y axis from the elayfield reference point 123 and the number of pixels to the ~r .

.
.
- . .

~Z84~26 ~ight along the x axis from either the playfield ceference point 12Z or ceference point 123. The playfield dimension along the y axis can be ex~ressed in the number of scan lines or in some other unit which can be converted to scan lines. The playfield scan lines such as lines 1 and 2 at the toe of the playfield are not video dis~lay scan lines but are, instead. fictional playfield scan lines since all areas outside the window 116 will not be visible. The scan lines that are within the boundaries of the window 116 will be visible however.
Each scan line in the window can be identified by either its playfield relative eosition or by its screen relative position. For purposes of discussion, the terms "screen relative" and ~window relative" are interchangeable. In the preferred embodiment, the current scan line's y position is expressed in terms of the number of scan lines down from the reference point 122. For purposes of the access to the alphanumeric information however, the current scan line is expressed in terms of the number of scan lines down from the window position reference point 124 where the current scan line lies.
Referring again to Figure 1, the purpose of the vertical match circuit 114 is to compare the y position 2s of all the motion objects on the linked list starting from the motion object at the slip address to the y position of the scan line currently being processed to determine if any part of the motion object will appear on that scan line. Figure 3 is a diagram of the mapping of the locations in the two dimensional collision detect array in the array RAM 32 to the corresponding locations on the playfield 118. Two different positions for the window are shown. The array locations in the collision detect array are shown as the boxes with x and y collision detect array coordinates in the upper left corners. The motion objects on the linked list are shown as boxes with numbers in them giving their . ~.,.~

28~6 -27~

position on the list. Links between the motions objects are shown as acrows connecting the boxes. Playfield objects such as walls are shown as boxes with designations such as PF 1 in them.
S Since only the motion objects which ace inside oc partially inside the window ~ositions will be visible, the job of circuit 114 is to dete~mine which ones of the motion objects have y eositions which ace within the y extents of the cueeent window location.
This process is speeded up by the fact that the circuit 114 only has to examine the y positions of the motion objects on the linked list starting with the motion object pointed to by the curcent slip. The function of the slips is illustrated in Figuce 3. Foc ~rocessing the linked list foe the window position 1, the state machine 30 would force slip 3 to be latched into the link register 48 at the beginning of scan line 17. Thus only the data records foc motion objects S and following would be presented sequentially to circuit 114 foc y hit pcocessing This y hit peocessing is done by comearing the -motion object y position (expcessed playfield celative) on bus 128 from latch 38 to the current window scan line being processed (expressed playfield relative on bus 130 feom latch 62. When a y hit is found, the signal VMATCH
on line 138 coupled to the status signal inputs of the state machine 30 is caused to go true.
The circuit 114 also calculates which stamp number in the array of stamps making up the motion object to address given the scan line that is curcently being processed. To detecmine this, the ciccuit 114 compares the current scan line number to the motion object's veetical position and the motion object's horizontal and vertical size. Referring again to Figure 2, if the ---------------------------------------------~; :

: ( current scan line was line 250, the ciccuit 114 would process motion object lZO and find a y hit because the y eoSition of stame 1 is within the y extents of window 116. After ~inding the y hit, the horizontal si2e data S on bus 132 f rom latch 38 of 6 stamps would be used to calculate that the first stamp number of motion object 120 would be stame number 7 for that type of motion object. The address of stamp 7 would then be calculated and provided on the address bus 134 through a multiplexer 136 controlled by the state machine to the addcess input bus 72 theceby causing access of the eroper graphic data. In another embodiment. instead of using a multiplexer 136, the output of the circuits 114 and 98 may be tri-state outeuts coupled to the same bus with the state machine controlling the tri-state contcol signal so that only one or the other of these circuits in non-tri-state thereby implementing a de facto multiplexer.
The other input to the multiplexec 136 is the address of the playfield object picture field stored in latch 64 and coupled on bus 140 to the input of the multiplexer. The multiplexer 136 is controlled by the state machine 30 to couple the eroper address at the proper time to the graphics ROM 64 to be able to access both playfield and motion object graphic data out of the same ROM.
Referring to Figure 4 (comprised of Figures 4A
and 4B), the details of the vertical match and stamp offset calculation circuit 114 are given. The first step in determining whether there is a y hit is to compare the y position of the motion object [playfield relative) to the y position of the current scan line being processed (also playfield relative). One way of doing this is to use two's complement arithmetic and add , .. .

~284226 the two y positions with one or the other expressed in 2's complement form.
To implement this approach, an adder 140, an adder 148 and an AND gate 152 are used. The adder 140 adds the y position of the motion object expressed in terms of the number of-scan lines up (in the negative y direction) from the reference point 123 in Figure 2 to the y position of the current scan line expressed in terms of the number of scan lines down from the reference point lZZ in Figure Z. The y position of the motion object is expressed in Z's complement format in ' this way because a signal VBLANK on a line 160 coupled to the carry-in'ineut of the adder 140 is a logic 1 thereby adding a 1 to the inverted expeession'of the motion object y eosition. This yields the Z's complement format. The motion object y position is the offset of the bottom scan line,in the motion object's stamp array relative to reference point 123. The computer stores the y position of the top scan line of the current window in the assigned location in the array RAM, and the counter 62 increments it as each'scan line is finished. The result is the current scan line position as a playfield relative offset from the ceference point 122 on the bus 130.
The equations that must be satisfied to have a y hit ace as follows:

(1) SPOS - VPOS is less than or equal to 0, and (2) tSPOS - VPOS] + (~VSIZE + 1] x 8) is greater than zero where ~Z8422~;

SPOS is the playfield relative cuerent scan line position as an of~set from the fi~st scan line at the to~ of the playfield, VPOS is the motion object vertical position expressed as an offset from the top scan line on the playfield wheee the reference eoint on the motion object stamp acray is the lowest line (most eositive y coordinate) in the lowest row of stamps in the stamp array and the left most pixel (smallest x coordinate) using the reference system of Figure 2 with refecence point 122 at the origin, and VSIZE is the vertical size of the object ~xpressed in numbers of rows of stamps with 0 répresenting a vertical size of 1 and 7 representing a vertiaal size of 8 rows of stamps, where each row is 8 scan lines tall.
The adder 140 is a 9 bit addee and implements equation (1). It adds the 2's complement of VPOS to SPOS and outputs data 'reeresenting the difference between the two numbers on the 6 bit bus 142 with the.
top three bits, i.e.. bits 6, 7 and 8 represented by the line 144. These most signi~icant three bits are represented by the simple line 144, and are true (logic 1) when both equations (1) and (2) are satisfied if the motion object size VSIZE is 7 (8 rows vertically in the stamp array) or less. The bus 142 is comprised of two sub-buses. The first sub-bus, bus 158, carries the middle three bits (bits 3, 4 and 5) to the input of an adder 148, and the second sub-bus, bus 160 carries bits 0, 1 and 2 to a latch 156. The data on the bus 158 represents the offset in rows of stamps of the bottom of the motion object from the current scan line.
If the current motion object having its y position examined is not 8 stamps by 8 stames, the vertical size o~ the object must be examined to . .

- ~*84226 determine i equations (1) and (2) are satisfied foc the vertical size of the object. In~uitively, the fact that the circuit 114 is tcying to determine is whether the bottom of the motion object is lower than the current scan line, and, if so, is the motion object tall enough so that the cuerent scan line easses through it. The adder 148 answers the second half of the inquiry by determining if equation (2) is satisfied for the size of the motion object being examined. The term-[VSIZE + 1]
x 8 is satisfied by the motion object vertical size information in rows of stamps on bus 132 being applied to the B input of the adder and the carry-in input of the adder being tied to logic l at all times when vertical match determinations are being made. This adds l to the vertical size information. The multiplication by 8 occurs by virtue of the addition of the data at the B
input to the data at the A ineut which is multiplied by 8 by virtue of the A input being connected to bits 3, 4 and 5, i.e., shifted upward by 2 or 8. This shift has the effect of a multiplication by 8. That is, the data on the bus 158 is SPoS - VPOS scan lines divided by 8 to equal the row in the motion object (counting from the bottom of the object) in which the current scan line resides if the motion object is 8 x 8 stamps.
The result of the addition by the adder 148 is the offset from the current scan line to the top of the motion object with the carry-out set. Thus, if the line 162 is a iogic 1 and the three bits represented by line 144 are a logic 1, then there is a y hit, and the AND
gate 152 causes VMATCH to go true signaling to the state machine that the current scan line passes through the current motion object and that the picture data should be retrieved if there is also an x hit.
.

.

~2~34;~

~ s an examele o~ the above calculation considec Figure 2. I~ the current scan line is 250 and the motion object whose vertical position i8 being examined is motion object 146 with a y position of 20. the y position dif~erence on bus 142 Will be 230 scan lines, and equation (1) will not be satisfied because the result is positive and no y hit condition will be signalled. Bus 158 will contain digits representing 230 divided by 8. If, however, the motion object whose y position is on bus 128 is motion object 120, the y position on bus 128 will be the ~'s complement representation of 294 and the current scan line will be 250. Thus, the y eosition diffeeence SPOS - VPOS on bus 142 is -44 scan lines and equation (1) would be satisfied and equation (2) would be satisfied if the motion object were an 8 x 8 stamp object. Since the motion object 120 is not 8 x 8,stamps, the result from equation (2) is crucial to determination of whether there is an actual y hit. In the example at hand, the ~esult of equation (2) would be -44 ~ t6 1 1]~ x 8 = 12 and equation (2) would be satisfied indicating a y hit has occurred. Since scan line 250 is the 4th scan line down from the top scan line in stamps 7 through 12 in the motion object, it can be seen that the result of equation (2) is indeed the offset of the curcent scan line down ~rom the first scan line in the motion object, i.e., scan line 238. Since the result of the addition by the adder 148 is positive, the carry out on line 162 is true and the AND gate 152 causes VMATCH to be true.
The next function performed by the circuit 114 is a calculation of the first stamp in the row in which the current scan line resides. In Figure 2, the stamp number for the first stamp in the row containing current scan line 250 is stamp number 7. ThiS process is begun . . . ,~ .. .; .

: ( ( `~ ~Z 8 ~ ~ 6 by a lookup table stoced in ROM 164. The truth table for ROM 164 is qiven in Appendix C. The input of thi8 lookup table is the data on bus 150, i.e., the row offset of the current scan line fcom the top of the motion object, and the horizontal size of the object on the bus 132. The M.O. REFL signal on the line 166 is a 1 bit field which is stored in an unused part of the word used to record the motion object's y eosition data. It indicates that the motion object should be a micror image of the original motion object.
The lookup table 16~ uses all the above infocmation to access a record stored therein which is the stamp offset from stamp 1 in the first row to the first stame in the cow in which the current scan line resides. The stamp offset data indicates in the case of the motion object 120 that the first stamp in the row in which the scan line 250 resides is stamp number 7 and is output on the bus 168 to the preset input of a counter 170. This counter receives a signal MFLP at its up/down input which determines whether the counter will count up or down each time a stamp~s graphic data has all been loaded into the line buffer so as to be able to display mirror image motion objects. The 4H signal is generated by sync generator 28. It occurs once every 8 pixels, i.e., once for each stamp. A NEW M.O. signal coupled to the load input of the counte~ 170 causes the data on the bus 168 to be loaded into the counter each time a new motion object is peocessed and a y hit cesults.
The output of the counter is on the bus 172 and is the current stamp offset as the scan proceeds across the motion object. This data is added by an adder 174 to the low byte of the motion object picture data on the bus 176. This picture data is stored in the latch 60 in Figuce 1 and is accessed only upon a y hit from the data record for the motion object causinq the y hit in the array R~M. This data is related to the actual address in the graphics ROM of the pixel patteen for the approeriate stamp of the motion object which caused the S y hit when it is added to the motion object stamp offset data on line 172. The resulting data is output on the bus 180 and is concatenated in a latch 178 with the motion object high byte data on the bus 176 at the most siqnificant bit positions and the motion object line data on the bus 182 in the least significant bit positions. The data on the bus 182 is the actual scan line in the stamp currently pointed to by the stamp offset data. The output data fcom buffer 178 is the actual address in the graphics ROM of the actual pixel data foc the 8 pixels on the cucrent scan line in the cuccent stamp. This address data is coupled to the geaphics ROM on the bus 134 to the multiplexer 136 in Figure 1.
The hocizontal position of motion objects which 2~ have had y hits must also be analyzed to determine if the object will be visible in the window and to detecmine where in the line buffer to write the information if the object will be visible. The circuitry that does this analysis is shown in Figure 4A
which is a detailed block diagcam for the playfield offset/hocizontal match circuit 98 in Figure 1. The examination for x hits is started by the adder. This device receives the motion object horizontal position, expcessed in playfield eelative tecms on the bus 100.
The cucrent x po~ition of the edge of the window expressed in playfield relative l's complement terms is ceceived on the bus 102 at the B input of addec 184. In the prefecced embodiment, the playfield celative position of the edge of the window position is expcessed -( 84ZZ6 t in l's complement for~ by virtue of the computer 20 writing the x position of the window into the latch portion of the circuit 104 in standard signed binary, playfield relative form followed by inversion of the latch output. The complement output data from the latch on the bus 102 is then input at the B input of the addec 184 where it is converted to 2's complement focm by vietue of the carey-in input of the adder being set to a loqic 1 (adding 1 to a l's complement number converts it to 2's complement). The addition of the data at the A
and B inputs of the counter 184 is actually a subtraction between the motion object horizontal position and the current position of the window because of the 2's complement form of the window position.
The addition by the adder 184 results in the screen relative position of the left edge of the motion object on a bus 185 exeressed in units representing two stamps wide. The reason for this is that only bits 4 thcough 8 of the output of the adder 184 are used for the bus 185 while bits O through 8 are used for the bus 191. The data on the bus 191 will be the screen relative position of the leftmost pixel on the current scan line of the current motion object expressed relative to the edge o the window. Because only bits 4-8 are on bus 185, the effect is that of a division by 16 pixels oc 2 stamps.
' This data on bus 185 will be a negative number if the left edge of the motion object is to the left of the left edge of the cucrent window left edge. The data on the bus 185 is input as part of the address for a PROM 189. The othec poction of the address of the PROM
189 is the motion object hocizontal size on the bu$ from latch 38 in Figure 1. The PROM 189 contains data that convects the playfield relative position of the left ' .
.- .

( ~
- lza4z2~

edge of the motion object and the motion object~s horizontal size expressed in stamps extending to the right into the HMATCH signal and a MOD H SIZE signal.
The truth table for the PROM 189 i8 given in Appendix D. The PROM 189 data words are such that if the hoeizontal size is such that any portion of the motion object is in the window, the HMATCH signal on a line 195 will be set to logic 1. If the left edge of the motion object is to the left of the cueeent window left edge, the signal on the line 197 will be the entiee hoeizontal extent of the motion object expressed in numbees of stamps. If, howevee, the motion object left edge is in the window, but the right edge of the motion object is to the eight of the right edge of the window, the data on the bus 197 will be the number of stamps completely oc paetially visible in the window.
A down countec 201 counts down fcom the stamp numbec represented by the data on the bus 197. The count input is coupled to a signal 4HD3 fcom sync geneeator 28 which deceements the count every 8 pixel times. The countee is loaded with the data on the bus 197 each time a signal NEWMO goes high. This happens each time the state machine is in the foceground processing state, and loading of the gcaphic data fcom an object having x and y hits begins. ~s long as the counter output is not zeco, the down counter outputs the-END signal on the line 203 as a logic OJ and the state machine entecs the backgcound, lookahead peocessing state. When the count reaches 0, END becomes a logic 1, and the state machine ce-entees the foceground cycle in time slot 3.
Refeccing to Fïguce 5 there is shown a state diageam foe the focegcound states of the syncheonous state machine 30 in Figuee 1. Figuce 6 shows the ~284226 background states of the state machine 30 which are used in the lookahead mode. The state machine 30 controls the operation of the system of Figures lA and lB by cycling through the states shown in Figures 5 and 6 during 7 basic time slots and generating the necessary control signals to cause the multiplexer to cycle through all its states to connect each of the buses shown in Figures lA and lB carrying address data to the address ports of the array RAM during an assigned time slot. The state machine also generates the proper control signals to cause the proper one of the latches coupled to the output of the array RAM to load the data placed on the data bus 56 by the array RAM in response to the address data supplied at its address port. The names inside each state circle indicate which address is selected during that time slot and which latch is loaded with the data that is output from the array RAM in response to the address selected during the time slot.
The background processing cycle is used when a motion object that is to be displayed, (that is, a y hit and an x hit have been found) is more than one stamp wide. In all other cases, the foreground ~rocessing cycle is used. The state machine receives three clock signals on the bus from the sync generator 28. The sync generator 28 is in turn driven by pixel clock signals on a bus 192 from a pixel clock 46. The pixel clock sets the lowest common denominator of the timing of the system by marking off pixel times during which each pixel is painted by the electron beam as it scans across the raster lines. The sync generator 28 counts the pixe1 times and generates the horizontal and vertical sync signals on the bus 194 for use by the video display scan circuitry in circuit 26. The horizontal sync signal HSYNC (not the actual horizontal sync signal used by the video but related to it) on bus 196 macks the end ~Z84226 of each scan line and the beginning of the next scan line. The timing signals on the bus 190 are used by the state machine as the basic macker signals to determine which of the 7 basic time slots in which the state machine currently resides. Some time slots have two or more states. The particular state in the time slot that the state machine enters depends upon the logic states of seveeal status signals. These status signals indicate such things as whether oc not there are y or x hits, the state of the y hit or x hit signals on the last motion object processed, and whether the HSYNC signal is or is not true. They also indicate whether the horizontal stamp address calculation circuit in circuit 98 indicates that the last stamp of graphic data in the row of stamps containing the current scan line has been loaded in the line buffer (END), and whether the state machine is currently in the foreground or the background state (NEWMO feedback signal from the output of the state machine).
The state machine 30 is a PROM, and uses the clock signals on bus 190 and the status signals mentioned above as address signals. The data stored at the addresses made up by the concatenation of all the status and timing signals is then output and latched into a buffer (not shown in Figure 1). Certain bits are assiqned as the load signals for the various latches in the system thereby allowing the state machine to control the storage of the various fields of data being accessed from the array RAM. Certain bits of the data stored in the state machine PROM are assigned as the select bits and control the states of the select signals on the bus 52 to the multiplexer 36. Others of the output bits are control signals to other logic in the system.
The foreground cycle is started by entering state 188 in time slot O in Figure 5. If the status signals indicate that the state 188 is entered at the beginning -------------------------------------------1284~26 ~9 of a new scan line, data from the memory location in the PROM accessed by the address comprised of the timing signals and status signals controls the select signals in such a way that the slip address i~ selected and supplied to the array RAM. This causes an entry from the slip table in the array RAM 32 to be loaded into the link register 48. This slip is a link to the first motion object on the linked list through which the current scan line may pass. The state machine is forced into the foreground processing state also at this time (by setting NEWMO true), and the current state of the MATCH status signal is set to false.
When the clock signals indicate time slot 1 is current, the state machine enters state 202. Here the state machine selects the link address on line 44, and sets the M.O. CTL signal on line 58 to select the output word in the motion object record containing the vertical position. This causes the data record of the motion object on the linked list pointed to by the link to be accessed, and the vertical position data of this record to be placed on the bus 56. In state 202, the state machine also generates a signal which presets the hocizontal match signal HMATCH to genecate an artificial x hit in case an actual y hit is found when y hit erocessing is completed by the time time slot 3 accives. The ceason foc this will be apparant from the discussion below.
The circuitry for artificial setting of HMATCH
true in state 202 is shown in Figure 4A. In state 202, the state machine sets a signal VERTDL on a line 210 true. This presets a flip flop 212 and causes the signal CLK HMATCH on line 214 to be true regardless of the actual state of HMATCH on line 195.
~11 the timing and status signals define the address for the state machine PROM on each time slot and do not individually affect states as might be assumed by the \

reader from inseection of Figures 5 and 6. The depiction shown in Figures 5 and 6 is symbolic only.
In state 204, the process of examining the vertical position data for a y hit is begun. As soon as S state 204 has been entered and the proper control signals generated, the vertical position data loaded into the latch 38 is examined by the circuit 114 independently as desccibed above. The process done by circuit 1]4 occurs during time slot 2, and the result is available as an input to the state machine during time slot 3.
While circuit 114 is checking for a y hit, the state machine selects address line 206 to give the CPU
control of the array RAM 32 address lines. The CPU 20 may then read or write the array RAM to update the current window position or change any of the data in any of the arrays in the array RAM.
To understand how the background and foreground cycles relate to each other, first assume that the foreground erocessing cycle has been entered for the first time on a new line. Since the signal MATCH was forced to 0 by the NXL signal ineut to the state machine during state 188, and, since MATCH only changes states between time slots 2 and 3 (or between time slots 6 and 7, then the state machine will transition to a state Z08 via a path 209 in the foreground cycle upon reaching time slot 3. In this state, the address on line 40 will be selected and the alphanumeric information for the current pixel position will be retrieved from the alehanumeric array in the array RAM 32. This pointer will be latched in the latch 66 and used by the circuitry 70, 94, 84 and 26 to eaint the proper alphanumeric information in the window at the current pixel position.

~28~2Z6 In time slot 4, the state machine tcansitions to either state 218 or 2ZO depending upon the state of the MATCH signal. As can be seen from the match circuitcy shown in Figure 4A, the MATCH signal is generally the AND function of the VMATCH and HMATCH
signals clocked by the signals VERTDL and HORDL
generated by the state machine in the states where vertical and horizontal match information is needed.
Thus MATCH is true only when there has been both a y hit and an x hit. Assuming a y hit on the first motion object processed in the first cycle through the foreground states, the state machine will transition to the state 218. In this state, the link address on line 44 will be selected, and the M.O. CTL bits will be set to access the motion objects picture pointer field which data will be latched into the latch 64.
The state machine will then transition to the state 222 in time slot 5 where the link address will again be selected, and M.O. CTL will be set to access the horizontal position field of the motion object record. This data will be latched into the latch 54, and will be examined by the circuit 98 as detailed above. This processing will result in HMATCH being set to the actual x hit status of the current motion object. The HORDL output signal from the state machine, seen on Figure 4A, will latch this status into the flip flop 212 and the AND gate 224 in Figure 4A will reevaluate the signals on the lines 214 and 226 and set MATCH to the logic state representing the actual x and y hit situation.
In time slot 6, state 228 will again grant CPU
access to the array RAM. Meanwhile the horizontal match examination erocess for presence of an x hit will be proceeding simultaneously. The sampling of the status of HMATCH and VMATCH with the signals HORDL and VERTDL

:
~ '' .

- 1284;~26 will occur in time slot 6. State 230 in time slot 7 is the time slot devoted to access of the playfield stamp data. In this state, the state machine select6 the address on lines 42 and 64 and causes the access of the proper playfield picture pointer from the playfield picture array in the acray R~M 3Z. This picture pointec is a pointer to the address of the proper playfield stamp in the graphics ROM 64 and is latched into the playfield picture latch 64. This data is coupled to the address port of the graphics ROM 64 through the multiplexer 136 which the state machine or other suitable logic contcols to select the address on the bus 140.
From state 230, the state machine transitions to either state 232 or state 188 depending upon the states of the MATCH and the MATCHDL signals. If an x hit was found by the processing started in state 222, MATCH will be 1. In the hypothetical case at hand, MATCHDL will be 1 because VMATCH changed states to a logic 1 ~ time slots earlier in.6tate 202 and MATCHDL
will have had time to pick up this change between time slots 3 and 4. Whenever MATCHDL is a logic 1, path 232 in the foreground cycle is taken regardless of the state of MATCH. Path 232 is also taken when MATCH is O
indicating no hit regardless of the state of MATCHDL.
The path 234 is taken only if MATCH is a 1 indicating a hit on the current motion object and MATCHDL is a O
indicating MATCH was O and no hit on the previous motion object occurred prior to time slots 3 and 4 of the current cycle in foreground.
In the example at hand, both an x hit and a y hit were found on the first motion object processed, and the state machine has entered state 188 in time slot 0.
This causes the link to the second motion object to be ,. . ,~
, ' ' ' ~ ' .

.

latched. Transition to state 202 ~hen occur~ and the ver~ical position data ef the second motion object is latched. State 204 is then enteced in time slot 2 and CPU access occucs.
Assume that the first motion object is more than one stamp wide (each time slot is equal to one pixel time). This means that END will be 0 and MATCH
and MATCHDL will still be logic l since the tcansition from time slot 2 to time slot 3 (for MATC~) and from time slot 3 to time slot 4 (for MATCHDL) will not yet have occurred. This means that there was a hit on a motion object and the graphics data is still being retrieved and stored in the line buffer. This will cause the state machine to stop processing in the foreground cycle and enter the background cycle since path 209 is taken only for the conditions shown on Figure 5.
The state machine now enters the lookahead mode while the graphic data from the first motion object is loaded in the line buffer. Referring to Figure 6, the first state entered in the background mode is state 238 where the pointer to the graphic data for the alphanumeric information to be displayed at the current pixel or electron beam position is accessed and latched. The state machine then transitions to either state Z40 or 242 depending upon the state of MATCH. If there was a y hit found in state ZOZ of the foreground cycle, the path Z44 will be taken so that processing for an x hit can peoceed. In the example at hand, and assuming that there was no y hit on the Znd motion object, path Z46 is taken to state 242 where the link to the next motion object is accessed and latched.
The state machine then transitions to state 248 where the vertical position data for the 3rd motion object on the list is accessed and latched. An examination for a y hit is then perfoemed during time slot 6. The state Z48 forces HMATCH to be tcue while . ~. , .
3.

looking for a y hit so MATCH will be true in time slot 7 if a y hit is found. A transition to state 250 once again gives the CPU access to the accay RAM, and then the state machine changes to state zs2 whece the S playfield pictuce data pointec is accessed and latched foc pucposes of painting the playfield objects.
~ ssume foc this example that the 3cd motion object is not a y hit. From state 252, transition to either state 254 or 256 occurs depending upon the states of MATCH and MATCHDL. MATCH will be 0, so transition to state 256 occurs. Assuming that the status signal indicating the beginning of a new line is as hand is false, state 256 will latch the link to the next motion object, i.e., the 4th motion object on the list.
Transition to the state 258 is then made, and the y pogition data foc the 4th motion object on the list is accessed and latched. Processing for a y hit then proceeds during time slot 2 as desccibed above while the CPU is given access to the array RAM in state 260. If the END signal changed to logic 1 at any time during the backgcound cycle just described, when state 260 is reached, the state machine again enter~ the foreground cycle.
Re-entry from the background cycle to the foreground cycle i8 to state 208 where ~ e the alphanumeric pointer is accessed. Transition then occurs to either state 218 or 220 depending upon the cucrent state of MATCH as detecmined from processing in the background state. In the example, no hits were found in the background state, 80 processing proceeds to state 220 where the link to the 5th motion object on the list is accessed and stored.
The state machine then transitions to state 264 where the vertical position data of the 5th motion -~-q ,. . , .. ~ . :

:"., :, - .
., . ~ . : '' ..

object on the linked list is accessed and latched.
State 264 also forces HMATCH to be true as was dane in state 202 in time slot 1. Processing for a y hit proceeds in state 228 during time slot 6 as described above in the description of circuit 114. Here, the computee 20 is once again given access to the areay RAM, and the state machine makes the transition to state 230.
Assume that a y hit for the 5th motion object was found in the process started by state 264. Thus, when state 230 is reached, MATCH will be 1 and MATCHDL
will be 0. This will cause the state machine to transition to state 232 where no operation is performed.
Transition to a state 266 is then made where the x position of the 5th motion object is accessed and latched. During time slot 2, the presence or absence of an x hit will be determined while the state machine is in state 204 where access by the computer 20 to the array RAM will again be granted. State 208 will be entered because thè MATCHDL signal is a logic 0 indicating no hit on the previous motion object, and processing proceeds as previously described with a transition out of state 208 to state 220 for a "no hit on the current motion object" condition or to state 218 for a hit on the current motion object.
Assuming for our examele that an x hit was found in state 266, transition will be made to state 208 because there was no hit on the previous motion object and MATCHDL will be 0. The alphanumecic infoemation will be accessed in state 208 and tcansition to state 218 will be made because MATCH is equal to 1. In state 218 the pictuee eointee will be eetrieved and the peocess of loading the line buffee with the pixel data will begin. Transition to state 2Z2 will then be made where the horizontal position data will again be examined and a hit will be found aqain. This is not necessacy, and is only an idiosyncrasy of the way in which the state machine must work. Transition through the states 2Z8 and 230 will then occur for CPU RhM
access and accessing of playfield object data.
Transition out of state Z30 will be to state 18~ where the link to the next motion object will be reteieved.
Transition to state 202 causes the veetical eosition of the 6th motion object to be retrieved and the 0 examination foe a y hit staets.
Assume that the 5th motion object was more than one stamp wide. MATCHDL will be 1 as determined between time slots 3 and 4 for motion object 5, and END will be 0. This will cause transition out of state 204 into the backqround state 238 while the END signal remains 0.
The reason for this is that the graehics ROM and the hoeizontal and vertical stame offset circuitry is busy processing the stam~s for the 5th motion object and cannot be simultaneously used to begin hit processing for the 6th motion object. To avoid wasting time, the background lookahead cycle is entered to find the next hit. This architecture implements a search pipeline to speed up processing the linked list to find out which objects will be visible in the current window position.
ZS The background cycle state first executed when the background cycle is entered is state 238 where the alphanumeric information for the motion object at the current electron beam position is accessed and the display process is started in the parallel channel for alphanumeric information. Transition is then made to state 240 because of the y hit found in state 202 of the foreground cycle. If there had been no hit in state 202 when the background cycle was entered, the state 242 would be entered to access the vertical position of the 7th motion object for y hit ----------------------------.

- ~284226 pcocessing. However, there was a y hit for state 202 for the 6th motion object, so state 240 is entered.
This is a no operation state since the picture infoemation cannot be accessed for the 6th motion object S while the picture information for the 5th motion object is being processed. Thus, transition to state 300 follows. Here the x position of the 6th motion object is retrieved, and x hit processing is started by the ciccuit 98.
Assuming an x hit occurred, the background cycle must then enter a wait cycle until END goes to logic 1 indicating the graphic data processing circuitry is free. This wait cycle consists of continual cycling through states 300, 250, 252, 254, 302 (where the horizontal position is examined again--unnecessacy but an idiosyncrasy of the operation of the system), state 260, state 238, state 240 and finally back to state 300 to begin the cycle again. This process continues until END goes to 1. After this time, the state machine makes a transition out of the background cycle back into the foreground cycle the next time state 260 is reached.
After re-entering the foreground cycle, the state 208 is reached followed by state 218 where the picture pointer for the 7th motion object found in the backgcound cycle is retrieved. Thereafter, processing continues as described above.
Referring to Figure 7 there is shown a flow diagram of the collision detect process performed by the computer 20 each time a motion object is moved on the playfield. Before the collision detect process can be performed of course, the various arrays in the array RAM
must be initialized, i.e., filled. There are many different known ways of doing this, and any of the known methods that will fill the collision detect array in the : - . .~.~ . ., --q8 -mapeed fashion shown in Figure 3 will suffice. Of cou~se the play~ield and alphanumecic arrays must also be filled, and any known method of filling them will suffice as long as the playfield may be painted and the alehanumeric information dis~layed in the proper places within the time constraints imposed by the time division multiplexed addressing of the array aAM. Generally, it is good practice to organize the arrays so that array entcies map to corresponding locations on the screen in a similar fashion to the organization shown in Figure 3.
One way of filling the arrays is to use a compacted table which desccibes the tyees of objects to be placed in the two dimensional array. Then starting at the upper le~t corner of each array, the array locations ace filled feom left to right.
~ fter the arrays are filled, the computer periodically reads the player oeerated controls to get data regarding the desired movements of various motion objects. The comeuter 20 uses this information to move the various motion objects in the array by accessing the data record for each object and changing the x and y position data and the link data. Before this can be done however, each motion object to be moved must be checked against the position of its neighbors in the collision process of Fiqure 7. If the result of the collision detect plocess is that the move would not result in a collision, then the move is allowed. lf the progeam determines that the object has moved to a new array location, then the entire record for the motion object to be moved is written into the new array location in the co11is~on detect array. For example, if motion object 12 of Figure 3 is to be moved from the box corresponding to array location 3,5 to the box corresponding to array location 4,6, then the entire record for motion object 12 will be --------------------~rp~

' , ' - ' ~ ' .
: -moved ~rom array location 3,5 to array location 4,6 i~
the collision detect algorithm indicates this is permissible. In such a case, the links on the linked list will be changed so the link f~om motion object 11 S points to motion object 13 and the link from motion object 14 points to motion object 12 in its new location.
This pcocess is symbolized by the flow of Figure 7. The ~icst stee is to detecmine the desired movements of the various motion objects. This process of reading the elayer controls is known and is symbolized by block 268. The other motion objects may be moved using the same collision algorithm. The direction of desired movement is game dependent and is not relevant to the invention. Next, a series o~
lS collision detect erocesses are peeêormed depending upon the dicection of movement of the object. The puepose of these collision detect peocesses is to compace the current eosition of the motion object with the positions of only, and at most, the nearest neighbors in the collision array in the direction of movement. If the direction of movement is along one of the principal two dimensional axes, then only the three closest neighbors perpendicular to the axes in the nearest straight line of neighbor locations perpendicular to the direction of movement are checked. For example, in Figure 3, if motion object 12 is to be moved left along the negative x axis considering it8 present position in box 3,5 as the origin, the collision detect algorithm would check only the contents of boxes 2,4 and 3,4 and 4,4 for a collision. However, if motion object 12 is to be moved to array location 2,4, the contents of array locations (4,4), (3,4), (2,4), (2,5) and (2,6) will be checked for a collision.

? ~;
~' ,. . .

.

-49a-In Figure 7, this process is started by block 270 which is a test to determine if the ~otion ob~ect is moving left. If it is, then the process of block 272 is performed to check for a left collision. If the result 5of the test of block 270 is no, thon path 274 is taken /

.
' ' ' ,... , ' ' .

- - ~.

- lZ84ZZ6 so--to the next direction collision test. In Figure 7, the next direction test is for a move right symbolized by block 276 but it could be any of the other directions since the sequence in which the dieections are checked S i8 not imeortant.
The process of checking for a left collision is detailed in Figure 8. A ~mall 6egment of the collision detect array is shown at 280 with the motion object to be moved shown at the current eo6ition and its nearest neighbor6 to the left 6hown as left 1, left 0 and left 2 po6ition6. The x and y po6itions of the object in the left 0 location are xo and yo respectively. A similar notation is used for the left 1 and left 2 object positions. The test for collision of the motion object to be moved with its neighbors is shown at 282.
Ba6ically, the x and y positions of the current motion object, designated x and y, respectively, are compared to the x and y position6 of it6 neighbor6 by a series of 6ubtcactions. These tests may be performed in any 6equence. As 6hown, the fir6t test i6 to take the absolute value of the x po6ition minus the xO position `~
and compare it to 16. If the absolute value is less ~;
than ^r equ~ 16,-then there is a collision.~ If the ~- ~
condition is not met, the next test is performed where ~ ~
the absolute value of x - xl i6 compared to 16. -If the condition i6 not met, then the next test is performed to ~-determine the absolute value of (x - x2). If any of the x comparison tests indicates a collision, then the y coordinate is checked. If the corresponding y coordinate check indicates a collision, then all further te6t6 are abandoned 6ince only one colli6ion i6 enough to trigger colli6ion processing.
Block 284 in Figure 7 6ymbolizes the testing process detailed above. Path 286 to block 288 .
;

symbolizes collision pcocessing if any of the te~ts for collision indicates there was same. The collision processing is game dependent. The process may include a determination of what collided with what and the result of the collision depends upon the rules of the game.
What those rules are is irrelevant to the invention.
If no collision is indicated, block Z90 is performed to change the x and y position of the current motion object.
After the block 290 process i8 performed or after the process of block 288 is performed or if path 274 is taken, the process of block 276 is performed to perform the same type of test as was done for a move "~
left for a move right. The tests of blocks 292 and 294 ~`' 15 are performed if the movement involves up or down ~-~
movement components. Basically, if a movement is not ~~~
along the x or the y axis, it~will ~ have components~
- .. . . - . , ~ . .__= .
along two of the 4 basic directions embodied by these axes. For example, if up is called north and left is~
called west, then a move northwest will have move=ent~
components both west and north. In such an example, thé~
up and left tests will be performed and all~the~;others will be skipped.
After all the appropriate tests have been -' ~ t'~
performed, the test of block 296 is performed.~ Here,~
the new position of the object moved is-tested to ~
determine if it is still in the correct array location corresponding to the box-on the screen mapping to that array location. If the answec is no, then the process -of block 298 is performed to move the data record of'thè~
object moved to the correct array location and to ~ -rearrange the linked list. `~-Although the invention has been described in terms of the preferred embodiment disclosed herein, ~-~

B ~:

. .

those skilled in the art will appreciate other ways of doing the functions disclosed herein. All apparatu~ and methods that achieve ~ubstantially the same result using similar means operating in similar manner are intended to be included within the scope of the claims appended hereto.

:: :

.

:

Claims (9)

1. An apparatus for collision detection between objects on a video display comprising:
means for storing moving and nonmoving object data records containing position information as to the location of the associated objects on said display in terms of the x and y coordinates of a reference point on each object relative to a predetermined reference point, said storing of data records being in memory as a two-dimensional array where each array element is mapped to a corresponding area on said video display;
means for detecting a collision between objects on said display by detecting the desired movement of an object on said video display and comparing the position information in the data record of said object being moved with the position information of the data records of objects, if any, stored in, at most, the nearest array locations in the direction of movement and for determining that a collision has occurred if predetermined criteria are met regarding the degree of proximity of said reference points of said object being moved and the objects whose data records are stored in said adjacent array locations.
2. The apparatus of claim 1 wherein said means for detecting also compares the position information of the objects, if any, in a predetermined number and pattern of array locations nearest to the array location storing the data record for said - Page 1 of Claims -object for which movement is desired and which pattern of array locations map to an area on said display which is a right angle which intersects the desired path of movement and which intersects both orthogonal axes having components of said movement thereon and which have an origin at the current position of the object for which movement is desired.
3. The apparatus of claim 1 wherein said means for detecting compares the position information for objects, if any, in at most the three closest array locations that map to an area on said display through which the path of movement on said display for the object being moved passes for movements along any of the principal, two-dimensional, orthogonal axes, such as the vertical and horizontal axes of said video display.
4. The apparatus of claim 3 wherein, for movements in any direction not on one of the principal orthogonal axes of two-dimensional movement on said video display, said means for detecting compares the position information for objects, if any, in, at most, the closest array locations which would be checked if the movement was solely along each of the axes for which there is a movement component for the direction of movement the object is actually following.
5. An apparatus for collision detection between objects on a video display comprising:

- Page 2 of Claims -means for storing moving and nonmoving object data records containing position information as to the location of the associated objects on said display in terms of the x and y coordinates of a reference point on each object relative to a predetermined reference point, said storing of data records being in memory as a two-dimensional array where each array element is mapped to a corresponding area on said video display;
means for detecting a collision between objects on said display by detecting the desired movement of an object on said video display and comparing the position information in the data record of said object being moved with the position information of the data records of objects, if any, stored in, at most, the nearest array locations in the direction of movement and for determining that a collision has occurred if predetermined criteria are met regarding the degree of proximity of said reference points of said object being moved and the objects whose data records are stored in said adjacent array locations:
and wherein said means for detecting further comprises means for comparing the position information for objects, if any, in at most the three closest array locations that map to an area on said display through which the path of movement on said display for the object being moved passes for movements along any of the principal, two-dimensional, orthogonal axes, such as the vertical and horizontal axes of said video display;
and wherein for movements in any direction not on one of the principal orthogonal axes of two-dimensional movement on said video display, said means for detecting compares the - Page 3 of Claims -position information for objects, if any, in, at most, the closest array locations which would be checked if the movement was solely along each of the axes for which there is a movement component for the direction of movement the object is actually following: and wherein said means for detecting stops comparing position information as soon as a collision or impending collision is detected and takes predetermined collision detect action.
6. An apparatus for collision detection between objects on a video displayed portion of a larger playfield comprising:
means for storing moving and nonmoving object data records having positional information expressed as offsets of a reference point for each object from a reference point on said playfield, said data records being stored in a memory as a two-dimensional array where each array location maps to an area on said video display and where contiguous locations of said array map to contiguous areas on said video display;
means for detecting a collision by detecting the desired direction of movement of an object on said video display and determining the principal orthogonal axes on said display along which said direction of movement has movement components in the vector addition sense, and for comparing the position information in the data record of the object to be moved with the position information of the data records of objects, if any, having data records stored in at most a predetermined number of the closest array locations which map to an area on said display - Page 4 of Claims -that is orthogonal to all principal orthogonal axis along which there is a movement component for the current direction of movement of the object and for determining that a collision has occurred if predetermined criteria are met regarding the degree of proximity of said reference points of said object being moved and the objects whose data records are stored in said adjacent array locations being checked; and means for stopping the comparison process when the first collision is detected thereby preventing the comparison of any further data records from the array locations that would otherwise be checked if no collision occurred, and for taking predetermined action in response to the collision.
7. A method of collision detection between objects on a video display comprising the steps of:
storing data records describing at least the positions of the objects visible on said video display in a two-dimensional array in memory where each array location maps to a corresponding area on said video display; and detecting an impending collision by comparing the position information of any object to be moved to the position information of at least one object having a data record stored in an array location adjacent to the array location storing the data record for the object to be moved which array location maps to an area of said display which intersects the intended path of movement and determining that a collision has occurred if a predetermined criteria is met regarding the proximity of the - Page 5 of Claims -reference points of the object to be moved and said object having a data record stored in the adjacent array location being checked.
8. A method of collision detection as described in claim 7 wherein said comparing step includes the steps of comparing the position information of an object to be moved with the position information in data records for objects, if any, in a predetermined pattern of the nearest array locations which are orthogonal to a principal, orthogonal axis of movement on said display upon which there is a movement component for the intended direction of movement desired for said object.
9. A method of collision detection between moving objects and other moving or nonmoving objects on a video display comprising the steps of:
storing data records for both moving and nonmoving objects containing position information as to the location of the associated objects on said display in terms of the x and y coordinates of a reference point on each object relative to a predetermined reference point, said storing of data records being in a two-dimensional array where each array location maps to a corresponding, area on said display;
detecting the desired movement of an object;
comparing the position data for each object for which movement is desired to the position data for objects, if any, whose associated data records are stored in said array in a - Page 6 of Claims -pattern of array locations which map to a corresponding pattern of areas on the display where said path of desired movement of said object to be moved intersects said pattern of areas mapping to the array locations storing data records being checked and determining that a collision has occurred when predetermined criteria are met regarding the proximity between reference points for the object being moved and any of the objects associated with the data records being checked:
stopping the comparison process for each object to be moved as soon as a data record in the pattern of array locations being checked is found which causes said predetermined collision criteria to be met.

- Page 7 of Claims -
CA000549402A 1986-10-15 1987-10-15 Collission detection system for video system Expired - Fee Related CA1284226C (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US06/919,128 US4905147A (en) 1986-10-15 1986-10-15 Collision detection system for video system
US919,128 1986-10-15

Publications (1)

Publication Number Publication Date
CA1284226C true CA1284226C (en) 1991-05-14

Family

ID=25441547

Family Applications (1)

Application Number Title Priority Date Filing Date
CA000549402A Expired - Fee Related CA1284226C (en) 1986-10-15 1987-10-15 Collission detection system for video system

Country Status (4)

Country Link
US (1) US4905147A (en)
EP (1) EP0270771A3 (en)
JP (1) JPS63109586A (en)
CA (1) CA1284226C (en)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0461577B1 (en) * 1990-06-11 1998-12-02 Hitachi, Ltd. Apparatus for generating object motion path
USRE36675E (en) * 1990-06-22 2000-04-25 Nintendo Co., Ltd. Game apparatus and memory cartridge used therefor
US5265888A (en) * 1990-06-22 1993-11-30 Nintendo Co., Ltd. Game apparatus and memory cartridge used therefor
JP3056514B2 (en) * 1990-08-27 2000-06-26 任天堂株式会社 Image display device and external storage device used therefor
US5287446A (en) * 1990-10-15 1994-02-15 Sierra On-Line, Inc. System and methods for intelligent movement on computer displays
US5515489A (en) * 1991-12-31 1996-05-07 Apple Computer, Inc. Collision detector utilizing collision contours
JP2716349B2 (en) * 1993-10-15 1998-02-18 株式会社エス・エヌ・ケイ Apparatus and method for determining grid hit in a game machine
JP3428151B2 (en) * 1994-07-08 2003-07-22 株式会社セガ Game device using image display device
JP3839501B2 (en) 1994-10-13 2006-11-01 株式会社スクウェア・エニックス VIDEO GAME DEVICE, CONTROL METHOD AND CONTROL DEVICE THEREOF, AND MEMORY CARTRIDGE FOR VIDEO GAME
JP3239683B2 (en) * 1995-05-11 2001-12-17 株式会社セガ Image processing apparatus and image processing method
US6146275A (en) * 1995-12-01 2000-11-14 Sega Enterprises, Ltd. Image processing apparatus
JP2950228B2 (en) * 1996-02-15 1999-09-20 株式会社セガ・エンタープライゼス Game image display method and game device
EP1580695A3 (en) * 1996-06-05 2007-08-29 Sega Corporation Image processing for a game
US6146269A (en) * 1996-08-06 2000-11-14 Konami Corporation Apparatus for and method of determining win for competitive video game, and recording medium storing win determining program
US6377288B1 (en) * 1998-01-12 2002-04-23 Xerox Corporation Domain objects having computed attribute values for use in a freeform graphics system
US6018346A (en) * 1998-01-12 2000-01-25 Xerox Corporation Freeform graphics system having meeting objects for supporting meeting objectives
US6509912B1 (en) 1998-01-12 2003-01-21 Xerox Corporation Domain objects for use in a freeform graphics system
WO1999057667A1 (en) * 1998-04-30 1999-11-11 Dusan Mraovic Procedure of aligning objects in a field and application of the procedure
JP3321570B2 (en) * 1999-09-14 2002-09-03 株式会社ソニー・コンピュータエンタテインメント Moving image creation method, storage medium, and program execution device
JP2002248261A (en) * 2000-12-22 2002-09-03 Sony Computer Entertainment Inc Object display program, computer readable storage medium for storing object display program, program executing device for executing object display program, character battle display program, computer readable storage medium for storing character battle display program and program executing device for executing character battle display program
US6907579B2 (en) * 2001-10-30 2005-06-14 Hewlett-Packard Development Company, L.P. User interface and method for interacting with a three-dimensional graphical environment
JP3927821B2 (en) * 2002-01-25 2007-06-13 株式会社バンダイナムコゲームス PROGRAM, INFORMATION STORAGE MEDIUM, AND GAME DEVICE
US20040121830A1 (en) * 2002-12-20 2004-06-24 Alessi Jeremy Frank Enigma-X
US8133115B2 (en) * 2003-10-22 2012-03-13 Sony Computer Entertainment America Llc System and method for recording and displaying a graphical path in a video game
US20060071933A1 (en) 2004-10-06 2006-04-06 Sony Computer Entertainment Inc. Application binary interface for multi-pass shaders
US7620530B2 (en) 2004-11-16 2009-11-17 Nvidia Corporation System with PPU/GPU architecture
JP4668655B2 (en) * 2005-03-24 2011-04-13 株式会社バンダイナムコゲームス Program, information storage medium, and image generation system
US7636126B2 (en) * 2005-06-22 2009-12-22 Sony Computer Entertainment Inc. Delay matching in audio/video systems
JP3892884B2 (en) * 2005-08-01 2007-03-14 株式会社コナミデジタルエンタテインメント GAME DEVICE, GAME DEVICE CONTROL METHOD, AND PROGRAM
US7880746B2 (en) * 2006-05-04 2011-02-01 Sony Computer Entertainment Inc. Bandwidth management through lighting control of a user environment via a display device
US7965859B2 (en) 2006-05-04 2011-06-21 Sony Computer Entertainment Inc. Lighting control of a user environment via a display device
JP5250267B2 (en) 2008-01-11 2013-07-31 ヤマハ発動機株式会社 Linear motor and component transfer device
JP5443832B2 (en) * 2009-05-29 2014-03-19 任天堂株式会社 GAME PROGRAM AND GAME DEVICE
US10786736B2 (en) 2010-05-11 2020-09-29 Sony Interactive Entertainment LLC Placement of user information in a game space
US9342817B2 (en) 2011-07-07 2016-05-17 Sony Interactive Entertainment LLC Auto-creating groups for sharing photos
JP7140465B2 (en) * 2016-06-10 2022-09-21 任天堂株式会社 Game program, information processing device, information processing system, game processing method
US10099101B1 (en) 2017-12-07 2018-10-16 Ssg International, Llc Golf club grip with sensor housing
USD849166S1 (en) 2017-12-07 2019-05-21 Ssg International, Llc Golf putter grip
US10798394B2 (en) * 2018-06-27 2020-10-06 Avago Technologies International Sales Pte. Limited Low complexity affine merge mode for versatile video coding

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4053740A (en) * 1975-12-22 1977-10-11 Lawrence David Rosenthal Video game system
US4116444A (en) * 1976-07-16 1978-09-26 Atari, Inc. Method for generating a plurality of moving objects on a video display screen
US4119955A (en) * 1977-03-24 1978-10-10 Intel Corporation Circuit for display, such as video game display
US4296476A (en) * 1979-01-08 1981-10-20 Atari, Inc. Data processing system with programmable graphics generator
US4471465A (en) * 1979-01-08 1984-09-11 Atari, Inc. Video display system with multicolor graphics selection
US4445114A (en) * 1979-01-15 1984-04-24 Atari, Inc. Apparatus for scrolling a video display
US4324401A (en) * 1979-01-15 1982-04-13 Atari, Inc. Method and system for generating moving objects on a video display screen
US4423870A (en) * 1979-04-30 1984-01-03 Atari, Inc. Video game collision detection system

Also Published As

Publication number Publication date
JPS63109586A (en) 1988-05-14
US4905147A (en) 1990-02-27
EP0270771A3 (en) 1990-11-07
EP0270771A2 (en) 1988-06-15

Similar Documents

Publication Publication Date Title
CA1284226C (en) Collission detection system for video system
US4905168A (en) Object processing for video system using slips and linked list
US4894774A (en) Lookahead pipeline for processing object records in a video system
US4930074A (en) Multiple stamp motion objects in a video game system
KR100222314B1 (en) Still picture display apparatus
US4725831A (en) High-speed video graphics system and method for generating solid polygons on a raster display
KR960006527B1 (en) Image processing apparatus
EP0013801B1 (en) Method and system for generating moving objects on a video display screen
US4600200A (en) Three-dimensional image display system
US5615322A (en) Image synthesizing system for producing three-dimensional images
CA1283980C (en) Display generator circuitry for personal computer system
JPH0535913B2 (en)
US7868889B2 (en) Method of causing object to take motion using motion data
EP0990458A3 (en) Video game machine, method for switching viewpoint on gamescreen of video game, and computer-readable recording medium containing game-screen-viewpoint switching program
US5739826A (en) Polygon display based on x coordinates of edges on scan line
KR910009102B1 (en) Image synthesizing apparatus
US6878058B1 (en) Image processor and game device with image processor
EP0797172A3 (en) Image processor and game apparatus equipped with the same
US4834374A (en) Object image indicating apparatus
US5926184A (en) Polygon sorting ordered by grouping according to distances in sorting groups
CA1197030A (en) Vector scan system for video game display
JP2990190B2 (en) Three-dimensional simulator device and image synthesizing method
JPH02134182A (en) Shooting game device
JP2898482B2 (en) Computer game equipment
JPH07124335A (en) Method of determining the crossing and game device using this method

Legal Events

Date Code Title Description
MKLA Lapsed