EP0667017A1 - Procede de commande d'un processeur generateur de lutins - Google Patents

Procede de commande d'un processeur generateur de lutins

Info

Publication number
EP0667017A1
EP0667017A1 EP92925041A EP92925041A EP0667017A1 EP 0667017 A1 EP0667017 A1 EP 0667017A1 EP 92925041 A EP92925041 A EP 92925041A EP 92925041 A EP92925041 A EP 92925041A EP 0667017 A1 EP0667017 A1 EP 0667017A1
Authority
EP
European Patent Office
Prior art keywords
control block
spryte
image
sub
processor
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.)
Withdrawn
Application number
EP92925041A
Other languages
German (de)
English (en)
Other versions
EP0667017A4 (fr
Inventor
Robert Joseph Mical
David Lewis Needle
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.)
CAGENT TECHNOLOGIES, INC.
Original Assignee
3DO Co
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 3DO Co filed Critical 3DO Co
Publication of EP0667017A1 publication Critical patent/EP0667017A1/fr
Publication of EP0667017A4 publication Critical patent/EP0667017A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/50—Lighting effects
    • G06T15/80—Shading

Definitions

  • PCT Patent Application Serial No. PCT/US92/09342 entitled RESOLUTION ENHANCEMENT FOR VIDEO DISPLAY USING MULTI-LINE INTERPOLATION, by inventors Mical et al. , filed concurrently herewith, Attorney Docket No. MDIO3050, and also to U.S. Patent Application Serial No. 07/970,287, bearing the same title, same inventors and also filed concurrently herewith;
  • PCT Patent Application Serial No. PCT/US92/09350 entitled METHOD FOR CONTROLLING A SPRYTE RENDERING PROCESSOR, by inventors Mical et al., filed concurrently herewith, Attorney Docket No. MDIO3040, and also to U.S. Patent Application Serial No. 07/970,278, bearing the same title, same inventors and also filed concurrently herewith;
  • PCT Patent Application Serial No. PCT/US92/09462 entitled SPRYTE RENDERING SYSTEM WITH IMPROVED CORNER CALCULATING ENGINE AND IMPROVED POLYGON-PAINT ENGINE, by inventors Needle et al., filed concurrently herewith, Attorney Docket No. MDI04232, and also to U.S. Patent Application Serial No. 07/970,289, bearing the same title, same inventors and also filed concurrently herewith;
  • PCT Patent Application Serial No. PCT/US92/09460 entitled METHOD AND APPARATUS FOR UPDATING A CLUT DURING HORIZONTAL BLANKING, by inventors Mical et al., filed concurrently herewith, Attorney Docket No. MDIO4250, and also to U.S. Patent Application Serial No. 07/969,994, bearing the same title, same inventors and also filed concurrently herewith;
  • PCT Patent Application Serial No. PCT/US92/09461 entitled IMPROVED METHOD AND APPARATUS FOR PROCESSING IMAGE DATA, by inventors Mical et al. , filed concurrently herewith, Attorney Docket No. MDIO4230, and also to U.S. Patent Application Serial No. 07/970,083, bearing the same title, same inventors and also filed concurrently herewith; and
  • PCT Patent Application Serial No. PCT/US92/09384 entitled PLAYER BUS APPARATUS AND METHOD, by inventors Needle et al., filed concurrently herewith, Attorney Docket No. MDIO4270, and also to U.S. Patent Application Serial No. 07/970,151, bearing the same title, same inventors and also filed concurrently herewith.
  • the invention relates generally to image data processing, and more particularly, to techniques for controlling a spryte engine to perform functions related to shadowing, highlighting and other functions, on a source image which is to be mapped and rendered onto a destination grid.
  • the visual realism of imagery generated by digital video game systems, simulators and the like can be enhanced by providing special effects such as shadowing, highlighting and so forth.
  • special effects such as shadowing, highlighting and so forth.
  • shadowing when the image of an airplane is to be displayed flying over a flat terrain on a sunny day, the realism of the overall scene is enhanced by generating a shadow image of the airplane within the image of the terrain. The effect appears more realistic when the terrain region onto which the shadow is projected becomes dimmed rather than completely blackened. The observer continues to see part of the texture of the terrain even though it is covered by the airplane's shadow. The effect is referred to as "shadowing.”
  • Highlighting is another example of realism- imparting effects.
  • an explosive device is displayed detonating near the airplane.
  • Visual realism is enhanced by momentarily increasing the brightness (highlighting) of the airplane's image to create the impression that light from the explosion is reflecting off the airplane's fuselage.
  • the effect appears more realistic when certain brightness and/or colorization relationships between different parts of the airplane (e.g., cockpit, fuselage, wings) are maintained.
  • Home game systems such as the Sega "Genesis” have a two-source image merging system for creating shadowing and highlighting effects on-the-fly (in real time) .
  • a first source "tile” or “sprite” (rectangular block of bit-mapped data representing the airplane shadow region) is overlaid with a second source tile representing the underlying terrain.
  • a digital signal representing the corresponding terrain intensity in the second tile is cut in half to thereby produce a "dimming" effect.
  • the dimmed version of the terrain tile is then output as part of the video image. (The dimmed image data is not stored in memory however.
  • the Sega "Genesis” system divides the shading value of all pixels within the airplane's sprite by two and then adds half the maximum shading value to each such pixel. This preserves the relative shading relation between parts of the airplane while making each brighter.
  • the augmented version of the airplane tile is then output as part of the video signal, but not saved. It is not possible to both shade and highlight a tile at the same time in the Sega "GenesisTM" system.
  • the above-described shadowing and highlighting techniques are of limited use. Optically-complex animated scenes require much more. Consider for example a scene in a Knights of the Realm kind of game. The hero enters the arch chamber of a church.
  • Stained glass windows of different elevations, colorations, transparencies, shapes and angles surround the chamber.
  • a villain is to be seen through the stained glass windows, approaching from the outside of the chamber at an angle relative to the stained glass windows.
  • the scene is to be projected through, or displayed on, a two-dimensional window (hereafter, the observation plane) .
  • the observation plane the window through which the game player views the scene
  • the position of the observation plane is to rotate slowly about the hero, thus giving a three-dimensional quality to the displayed two-dimensional scene.
  • Realistic rendering of such a scene has to take into consideration the transformation of outside light as the light passes at various angles through the stained glass windows to the observation plane. It also has to take into account the reflection of internal lighting off the stained glass windows toward the observer's plane. Moreover, if the villain throws a rock through one of the stained glass windows, the visual effects of the hole have to replace those of the removed window material. If the villain flings mud onto a window, the transparency and coloration of the affected window regions have to change accordingly.
  • Digital graphic processing also relies on the physical transformation of digital signals representing image data from one organizational format to another. Part or all of the transformed image data is then displayed on an appropriate display means (e.g., a cathode ray tube or a liquid crystal display) .
  • an appropriate display means e.g., a cathode ray tube or a liquid crystal display
  • mapping function can be a one-to-one copying of pixels from a source area to a destination area.
  • the mapping function can include a transformation of size, and/or a change of shape (e.g., skew) and/or a rotation of some angle plus a change of colors or image brightness.
  • the displayed brightness of the aircraft body should increase momentarily to simulate reflection of light from the explosion off the fuselage of the airplane.
  • the airplane may have transparent components, such as a large bubble-shaped cockpit window; or a hole on part of its body, the hole being one that is suddenly created by a striking projectile. In such cases, it is desirable to show background scenery passing transparently through the cockpit window and/or body hole as the airplane flies in front of a background scene.
  • An animated real-time scene of this type can be produced on a display means in a number of ways.
  • a brute force approach would separately generate each frame of the animated scene data in its entirety, store the generated frame data in high speed memory (e.g., video RAM) and transfer each complete frame (background plus airplane) to the display means at an appropriate frame rate.
  • high speed memory e.g., video RAM
  • This brute-force approach wastes memory space and demands high-speed performance from the processing circuitry that generates the sequential frames of image data.
  • One area of memory stores nonchanging, background image data and a second area of memory stores the image data of the airplane and other moving bodies. With each displayed frame, the image of the airplane is mapped from the second memory area onto the background image of the first memory area.
  • the mapping function changes with time to provide size enlargement or reduction and rotation over time.
  • the mapping function also provides changes of color and/or brightness to simulate various illuminations such as that from a nearby explosion.
  • High-performance electronic computer systems are available for transforming image data in such a manner, such as the Silicon Graphics IrisTM system mentioned above.
  • Such systems rely on complex software-controlled data transformations and bulk transfers of image data from one memory region to another.
  • a general purpose computing unit is burdened with the task of supporting all calculations.
  • these computer systems suffer from drawbacks such as excessive cost, large circuit size, complexity and/or slow image rendition speed.
  • IC integrated circuit
  • Such routines should also provide protection from unintentional misuse of the image- rendering system.
  • linked lists of spryte control blocks are prepared in memory and traversed by a spryte rendering engine.
  • Each spryte control block controls the rendering of a respective spryte into the display buffer, and contains such information as a pointer to source data for the corresponding spryte, positional and perspective specifications for a destination quadrilateral, a control word for manipulations to be performed on the spryte image source data, and an indication of which of several available formats the spryte image source data is packed in.
  • a spryte control block can also control the spryte rendering engine to modify a portion of existing display data, using either new spryte image source data or constant data.
  • the spryte rendering engine can be called by writing certain values into specific memory-mapped hardware registers, and then writing dummy data to an address recognized by the hardware as a command to initiate the spryte rendering operation.
  • Fig. 1 is a block diagram of major components of a hardware system in which the invention may be used;
  • Fig. 2 is a symbolic block diagram of the address manipulator of Fig. 1;
  • Fig. 3 is a block diagram of part of the address generator of Fig. 2;
  • Fig. 4 is a block diagram of the stack address logic of Fig. 3.
  • Fig. 5 is a block diagram of left address pad logic of Fig. 3.
  • Fig. 1 is a block diagram showing major components of the hardware system. It comprises a CPU 102, which may be an ARM 60 RISC processor manufactured by Advanced RISC Machines, Ltd., Swaffham Bulbeck, Cambridge, U.K. The ARM 60 is described in Advanced RISC Machines, "ARM 60 Datasheet” (1992), incorporated herein by reference.
  • the address bus 104 which is provided as an input to an address manipulator chip 106.
  • the address manipulator chip 106 contains, among other things, an address generator for providing DMA-generated addresses to system memory, as well as addresses from other sources; a D-bus arbiter; two spryte engines; and interfaces to a player bus, a slow bus and a set of external processors.
  • the address manipulator chip 106 generates addresses for system memory 108, which includes a left memory bank 108A and a right memory bank 108B.
  • System memory is 32-bits wide, the high-order 16 bits of each 32-bit word being in left memory 108A and the low-order 16 bits being in right memory 108B.
  • the CPU 102 addresses system memory only in words, but the address manipulator chip 106 can address each half of the memory entirely independently.
  • Address manipulator chip 106 provides addresses and control signals to left memory 108A over an LA bus 110 and an LCTL bus 112, respectively, and provides addresses and control signals to right memory 108B over an RA bus 114 and RCTL bus 116, respectively.
  • System memory 108 can include one or two "sets" of video RAM (VRAM) and zero, one or two sets of DRAM.
  • VRAM video RAM
  • a set VRAM contains 512 k bytes of left memory and 512 k bytes of right memory, for a total of one megabyte.
  • a set of DRAM is, depending on the system configuration, one, four or 16 megabytes long. As with VRAM, half of each set is located in the left bank of memory and the other half is located in the right bank of memory. However, unlike VRAM, DRAM is always accessed in full 32-bit words. System memory 108 is considered big-endian.
  • All of the left and right bank system memory sets receive the respective left and right half addresses generated by the address manipulator chip 106.
  • All of the left bank sets also include a data port which are coupled bi-directionally with a left half data bus D(31:16) 118.
  • the data ports of all of the sets of right bank memory are coupled bi-directionally with a right half data bus D(15:0) 120.
  • the VRAM sets also have a serial port S, which is coupled bi-directionally with an S(31:0) bus 122.
  • Address manipulator chip 106 also provides and receives control signals to and from the CPU 102 over lines 128, and is also coupled bi-directionally with the left and right data buses 118 and 120. Address manipulator chip 106 also interfaces to a slow bus 130, which is an 8-bit bus for accessing such devices as a CPU ROM 132, a battery-backed SRAM, and/or various front panel devices 134. It may also support additional CPU- accessible RAM, and may also support an FM sound generator device.
  • the slow bus 130 includes 14 bits of the address bus 104 A(16:2), an 8-bit data bus PD(7:0), a PDRDB read strobe, a PDWRB write strobe, and various control lines. PDRDB and PDWRB are used to carry the two low-order address lines for accessing the 8-bit wide CPU ROM 132.
  • Address manipulator chip 106 also interfaces to a player bus 136, which is used to connect the system to various user input/output devices such as joysticks, 3- D glasses, hand controllers and steering wheels, and and game saver cartridges. Address manipulator chip 106 is also coupled to a control bus 138, which is used to send and receive control signals to and from other processors in the system of Fig. 1.
  • the system of Fig. 1 further includes an audio/video processor chip 140 which is coupled bi- directionally to both halves 118 and 120 of the D-bus, and coupled to receive data from the 32-bit wide S bus 122. Audio/video processor chip 140 is also coupled to the control bus 138, and is coupled to receive address bits A(15:2) from the system address bus 104.
  • the audio/video processor chip 140 generally includes display path circuitry, an audio subsystem, timers, an interrupt controller, an expansion bus interface and a watchdog timer.
  • the expansion bus interface couples to an expansion bus 142 which includes control lines 144 and an 8-bit bus 146 carrying multiplexed address and data information.
  • the expansion bus 142 supports such devices as CD/CD-ROM player 148 and optional expansion bus RAM 150.
  • the CD/CD-ROM player 148 is built into the housing of the system of Fig. 1 and provides the primary mechanism by which software (including the routines described herein) is loaded into the system for execution on the CPU 102.
  • the audio/video processor 140 communicates with audio/video output circuitry 152 via audio lines 157, control lines 156, and a 12-bit AD bus 158.
  • the audio/video output circuitry 152 generally generates the video timing and output video waveforms. It provides a composite video output, an RF output for connection to a standard television, an SVHS output, and separate left and right audio signal outputs.
  • the system of Fig. 1 also includes a decompression co-processor 166 which is coupled to the control bus 138, to bits A(15:2) of the system address bus 104, and to both halves 118 and 120 of the D bus.
  • Decompression co-processor 166 is used to decompress software which is loaded into the system from the CD/CD-ROM player 148 or from another source.
  • a section of system memory starting at address zero and extending to either 0, 8, 16 or 32 K bytes, may be defined as SYSRAM.
  • the size selection is made by the software.
  • the address manipulator chip 106 contains protections which prevent user software from writing to or reading from SYSRAM. Only software running in the supervisor mode of the CPU 102 may write to SYSRAM.
  • All of the system address and timing signals are generated by the address manipulator chip 106. Any requests for access to system memory from either the CPU 102 or the audio/video processor 140 pass through the address manipulator chip 106.
  • VRAM system memory
  • the low 64k 32-bit words might contain CPU instructions and data.
  • the next 300k bytes might contain uncompressed 8-bit image source data, and the next 172k bytes might contain audio and other data.
  • the next 150k bytes might be allocated for one frame buffer (320 by 240 pixels by two bytes per pixel), and the last
  • 150k bytes might be allocated for a second frame buffer.
  • Frame buffers are arranged so that even number data lines reside in the left memory bank and odd number data lines reside in the right memory bank. Pixels are represented as 16-bit values divided as follows: five bits to represent a red pen number, five bits to represent a green pen number, four bits to represent a blue pen number, and two subposition bits H and V. In an alternative data format, one of the H or V bits is replaced by a fifth blue pen number bit.
  • a color look-up table translates each 4- or 5-bit pen number to an 8-bit value for the corresponding color DAC. The color look-up table can be updated prior to each scan line.
  • Fig. 2 is a symbolic block diagram showing major functional units of the address manipulator chip 106 of Fig. 1. It comprises an internal 32-bit MDT data bus 202, an internal 32-bit MADR address bus 204.
  • the MDT data bus 202 is coupled to the left and right half system D-bus 118, 120 via buffers 222.
  • the chip 106 also includes a CPU interface unit 206 which is coupled to receive CPU-generated addresses over the A-bus 104, and also communicates with the CPU 102 over control lines 128.
  • control lines 128 is an MCLK signal provided by the CPU interface 106 to the MCLK input of CPU 102, which is the memory clock input of CPU 102.
  • Address manipulator 106 controls the waveform of this clock signal to both stretch CPU cycles for slow accesses and to put the CPU 102 to sleep for long periods of time.
  • the ARM 60 CPU is a static part which does not need maintain any minimum clock input frequency.
  • Addresses generated by the CPU 102 are passed by the CPU interface 206 to an address generator 208 when a D-bus arbiter 210 grants control of the D-bus and address generator 208 to the CPU 102.
  • the address generator 208 drives the high-order address bits from A(31:16) onto the MADR bus 204, where they are decoded by an address decoder 212.
  • Address decoder 212 determines from these bits whether the desired address represents a memory-mapped hardware register, in which case it activates the appropriate select line to notify the appropriate hardware component in the system of Fig. 1. That hardware component then performs the desired function in response to bits A(15:2) of system address bus 104.
  • address decoder 212 determines that the desired address is part of system memory 108, then it so notifies the address generator 208.
  • Address generator 208 generates the appropriate addressing and control signals on the LCTL and LA buses 112 and 110, and the RCTL and RA buses 116 and 114.
  • Address generator 208 receives addresses from the CPU via the CPU interface 206 and also from spryte engine 214. Address generator 208 also maintains a stack of DMA control information and can generate addresses for DMA transfers.
  • the D-bus arbiter 210 receives requests from the various devices for transfers over the D-bus, arbitrates among them, and indicates to address generator 208 which request to service. Even though the two halves of system memory are addressed and controlled separately, only one master may be operational at a time. If the winning requestor has requested a DMA transfer, then the D-bus arbiter 210 supplies the address generator 208 with a DMA group address indicating where in the DMA stack the desired control information may be found for the requested transfer.
  • the DMA group address identifies a particular DMA channel.
  • the DMA interface is handled entirely within the address manipulator chip 106.
  • the spryte engine 214 is coupled to the internal MDT data bus 202, and the functions and operation of the spryte engine 214 are described in more detail below.
  • Address manipulator chip 106 also includes a player bus interface 216 and a slow bus interface 218, for interfacing respectively to the player bus 136 and the ⁇ low bus 130. These need not be described here in detail.
  • D-bus arbiter 210 receives requests from various requestors for access to the D-bus and D-port of system memory 108. When D-bus arbiter 210 grants the bus to a particular requestor, it sends an acknowledge signal to the requestor.
  • the details of the D-bus arbiter need not be described here, except to note that the CPU 102 is intentionally given the lowest priority in the arbitration for access to the D-bus port of system memory 108 because in the architecture of Fig. 1, the CPU 102 is conceived to perform housekeeping functions only. All the other functional units in the system are more tightly coupled with the memory than the CPU is, so they can perform their functions at high speed. In the past, the requirement that the CPU perform many of the detailed functions of an interactive multi-media system either limited the performance and realism of the system, or mandated the use of a powerful and expensive CPU, or both.
  • the spryte engine 214 (Fig. 2) is described in detail in the related SPRYTE RENDERING SYSTEM WITH IMPROVED CORNER CALCULATING ENGINE AND IMPROVED POLYGON- PAINT ENGINE and IMPROVED METHOD AND APPARATUS FOR PROCESSING IMAGE DATA applications. Without repeating those descriptions, it is useful to note here that whereas conventional imaging systems are built around the concept of a "sprite", the embodiment described herein refers instead to a "spryte". The difference in spelling is intentional.
  • a conventional sprite consists of a rectangularly-shaped area of image data, with all scan lines of a conventional sprite having the same length.
  • the length of each spryte scan-line is independently controlled by an EOL (end-of-line) terminating code or other appropriate means.
  • the top point on the spryte edge line is defined by a spryte corner position.
  • the total number of horizontal lines which collectively define a spryte is given by a spryte line count.
  • a spryte can include scan-lines with no pixels in them, and particular pixels within a spryte can be designated as transparent. In effect, therefore, a spryte can be thought of as having any shape that might be desired.
  • Fig. 3 is a block diagram of parts of address generator 208 (Fig. 2).
  • Fig. 4 is a block diagram of stack address logic 336 (Fig. 3), and
  • Fig. 5 is a block diagram of the left and right address pad logic units 345, 353 (Fig. 3). These units are described in detail in the above-mentioned AUDIO/VIDEO COMPUTER ARCHITECTURE application and need not be repeated here. It is worthwhile noting, however, that CPU-originated addresses and addresses originating from the spryte engine are provided to the memory 108 via respective input ports of a multiplexer 316. All other system memory accesses are performed by DMA using the DMA stack 312.
  • the 128 22-bit registers in the DMA stack 312 are organized in groups, each group storing the information required to control a respective DMA "channel". Each group is located at a respective fixed set of addresses in the DMA stack 312, and each channel is predefined to control transfers from a particular source device to a particular destination device, Table I sets forth certain information about the channels used for the spryte engine:
  • SCoB Spryte Control Block
  • the SCoB data structure contains the words set forth in Table II below.
  • Spryte rendition takes place by stepping through a linked list having one or more SCoB's. After a first source spryte is mapped to, and painted onto a destination grid area defined by its SCoB, the spryte- rendering engine processes the next SCoB, if any, and renders its source spryte onto its designated destination surface.
  • the linked list can be circular if desired so that the process is repeated iteratively.
  • 32 PPMPC PPMP control word (two halfwords: 16, 16) (See Table IV).
  • the bits of the FLAGS word specified above are defined as set forth in Table III. These flag bits control specific fetching and rendering operations of the spryte-rendering engine 214. The data specific control bits are found in the preamble word of the source data.
  • B26 DSIZE Load 4 words of size and slope data. (DX, DY, LINEDX, LINEDY).
  • B25 LDPRS Load 2 words of perspective (skew control) data. (DDX, DDY).
  • B24 LDPPMP Load new PPMP control word (PPMPC) into PPMP control registers.
  • B23 LDPIP Load new PIP data into PIP.
  • B21 YOXY Translate the XY values to a system memory address value and write the corresponding data to the hardware.
  • B18 ACW Allow rendering of a CW (clock-wise) oriented destination pixel.
  • B17 ACCW Allow rendering of a CCW oriented destination pixel.
  • B16 TWD Terminate rendition of this Spryte if wrong direction is encountered (CW- CCW).
  • B15 LCE Lock the operations of the 2 corner-calculating engines together, (at H change).
  • B14 ACE Allow the second corner-calculating engine to function.
  • B ASC Allow Super-Clipping (the local switch is ANDed with ASCALL).
  • B6 PIPPOS Use PIP generated bits as the subposition bits (BO & B15 of the Output- PEN signal) instead of the SCoB selection made below by B15POS and B0POS.
  • B3:B0 PIPA PIP address bits, these are used to pad the 5-bit wide PIP address input signal when BPP (Bits Per Pixel) output of unpacker is less than 5 bits wide.
  • the bits of only the upper half are defined as set forth in Table IV.
  • the lower half has identical structure.
  • the secondary functions are set forth in Table V.
  • AVO Invert the output of the second divider in the PMPP and set the carry-in of the adder.
  • AVI Enable the sign-extend function for the signals flowing down the second math side of the PMPP (Post possible XOR).
  • AV2 Disable the wrap-limiter function. (Use the 5 LSB's of the 8-bit adder output and ignore possibility that it wrapped above decimal 31 or below decimal zero.)
  • SCOBCTLO general spryte-rendering engine control word
  • B31:B30 B15POS B15 oPEN selector for output of PMPP.
  • the B0POS value of *2' is the only setting that uses PPMP math to control the B0 bit in the actually output oPEN signal. When this setting is chosen, the Blue LSB will also be included in the input parameters of the black detector.
  • Non-totally literal Sprytes require one word preamble, whereas totally literal Sprytes require two words of preamble.
  • preamble words may be located at the end of the SCoB words (but before the PIP) as set forth in Table II, or at the start of the image data. The normal location for these words is at the start of the image data, but for totally literal Sprytes that are in frame buffer format, they are typically at the end of the SCoB that invokes that spryte.
  • Non-totally literal Sprytes can be compacted to save both memory space and rendering time.
  • Each source scan line of data has its horizontal word size specified as part of the data.
  • Totally literal Sprytes have a rectangular format that is specified in the preamble of the data.
  • the first preamble word for all sprytes is the data structure preamble. It contains the data-specific control bits for the source data, defined in Table VII.
  • B31->B21 Reserved, set to 0.
  • B20 PACKED. This is identical to the PACKED bit in the SCoB
  • B15->B6 VCNT Vertical number of source data lines in this image data, minus 1. (10 bits)
  • B2->B0 BPP Bits/pixel, pixel type.
  • VCNT is loaded into a hardware counter in the Spryte requestor and is decremented at the end of the fetching of each source scan line of data. When the count is at -1, there are no more source lines of data in the object. Note that Spryte processing does not end here, this is merely one of the events that is required to end a Spryte.
  • VCNT line count -1. An initial value of -1 for VCNT will cause a "REAL BIG Spryte" to be fetched. There is no 'zero line count' value.
  • the LINEAR bit applies only when the BPP type indicates 8 bits per pixel or 16 bits per pixel. In those cases, there are enough PIN bits to provide a 15 bit IPN without using the PIP. Since the PIN bits are spread linearly across the IPN, and it will result in a linear translation from PIN to IPN, the mode is called 'LINEAR' .
  • the LINEAR bit should be set only for sprytes having 8 or 16 bits per pixel, known as LINEAR 8 and LINEAR 16 (as opposed to 'normal' 8 or 16) format.
  • the REP8 bit is effective only in the 8 bit per pixel source data size.
  • the source data is totally literal.
  • there is a second preamble word It contains, among other things, the horizontal pixel count for each line of the source data and the word offset from one line of source data to the next. These bits are valid only while the totally literal Spryte is being rendered, and they are not used when the current Spryte is not totally literal.
  • the bit fields of the second preamble word are defined in Table IX.
  • Table DC Second Sprvte Data Preamble Word 8 Word offset from one line of data to the next (-2) (8 bits). Bits 23- > 16 of offset are set to 0. IO). Word offset from one line of data to the next (-2) (10 bits). Bits 31->26 of offset are set to 0.
  • the TLLSB bits perform the same function that the IPNLSB bits perform in normal Sprytes.
  • the source data has the frame buffer format of the screen as a source format. Vertically adjacent pixels in the rectangular display space are horizontally adjacent in the 2 halves of a memory word. This is useful for the 16 bit per pixel totally literal data format.
  • the unpacker in spryte engine 214 will disable the 'B' FIFO data requests and alternately place pixels from the source into both FIFOs. Left 16 bits go to 'A' FIFO, right 16 bits go to 'B' FIFO. The data requests for 'A' FIFO are made in a request 'pair' to minimize page breaks and other latencies.
  • the hardware locks the corner engines to operate together (regardless of the LCE bit) .
  • TLHPCNT is the number of pixels in the horizontal dimension, minus 1. This is the number of pixels that the spryte engine 214 will attempt to render for each horizontal line of the Spryte source data. This value is used by the data unpacker. A '0' value for TLHPCNT will attempt one pixel. A '-1' value will attempt many pixels. There is no 'zero pixel count' value.
  • WOFFSET is the offset in words of memory from the start of one line of data to the start of the next line, minus 2. If the BPP for this Spryte indicates an 8- or 16-bit per pixel format, WOFFSET(IO) or WOFFSET( ⁇ ) is appropriate. This number is zero for the minimum sized Spryte (2 words) .
  • the address generator 208 will also use WOFFSET as the length value in the normal data fetch process. WOFFSET and TLHPCNT must be set so that WOFFSET does not expire first.
  • the first one or two bytes of data on each line of spryte source data contain a word offset from the start of this line of source data to the start of the next line of data, minus 2.
  • bits 31:16 1 byte of offset
  • the actual offset has a maximum size of 10 bits.
  • the rest of the bits in the 2 bytes are set to 0. 10 bits of word offset is 2048 pixels at 16 bits per pixel. 8 bits of word offset at 6 bits per pixel is 1365 pixels. The requirement is 1280 pixels.
  • This offset is used by the address generator 208 both to calculate the start of the next line of spryte source data (by adding it to the start of the current line), and to set the maximum length (by subtracting 1 and placing it in the DMA stack length register) for the current DMA transfer.
  • next data after the offset is a control byte and zero or more bits of PIN data.
  • the number of bits used for each PIN is specified by BPP.
  • the control byte consists of a 2-bit code and a 6- bit count, as follows: OOxxxxxx end of line, xxxxxx need not be present
  • Olcount literal PINs for 'count*1' lOcount Defined 'transparent' for 'count*1' llcount packed 'PIN' for 'count+1'
  • the 'transparent' definition will actually output a 'transparent' bit from the unpacker. This will cause the remainder of the pixel processing pipe to ignore this pixel.
  • the CPU 102 In order to render a spryte into an area of system memory 108, the CPU 102 first sets up the required data in a different area of the system memory 108.
  • data includes 6 to 15 32-bit words as specified in Table II above, all located contiguously in system memory 108; 4, 8 or 16 optional 32-bit words contiguously located in system memory 108 to represent PIP data; and spryte image data of any length.
  • 6 to 15 words specified in Table II note that several groups are optional as set forth more fully below.
  • the second word of the SCoB is a pointer to the next SCoB to process; thus, the CPU may create a linked list of any number of SCoBs to process in sequence, each defining its own spryte source data, optional PIP data, and spryte rendering control information.
  • the CPU 102 writes desired information directly into certain memory-mapped hardware registers as follows:
  • SCOBCTL0 32-bit word defined in Table VI above.
  • REGCTLO Controls the modulo for reading source frame buffer data into the primary and/or secondary input port of the spryte engine 214 and for writing spryte image result data from the spryte engine 214 into a destination frame buffer in system memory 108.
  • the modulo effectively indicates the number of pixels per scan line as represented in the respective frame buffer in system memory 108.
  • REGCTLO Only the low-order 16 bits of REGCTLO are used.
  • the low-order 8 bits specify the modulo for the source frame buffer, and the next 8 bits specify the modulo for the destination frame buffer.
  • the low-order 4 bits specify a Gl value and the high-order 4 bits specify a G2 value.
  • the modulo specified for a particular buffer is then calculated as G1+G2.
  • CFBD refers to current frame buffer data, a source buffer separate from spryte source data, which the spryte engine may read as input data
  • REGCTLO BIT DESCRIPTION 0 Gl 32 for CFBD read buffer.
  • REGCTL2 Read base address. Indicates the address in system memory 108 of the upper left corner pixel of the source frame buffer data.
  • REGCTL3. Write base address. Indicates the address in system memory 108 of the upper left corner pixel of the destination frame buffer (CFBD) . Also before the spryte engine is started, the CPU 102 places the address of the first SCoB in the linked list into the DMA stack 312 register corresponding to "next SCoB" . The CPU then writes to the memory mapped address designated SPRSTRT in order to start the spryte engine running. Once the spryte engine starts running, it retains exclusive control of the D-bus until either it finishes processing all the SCoBs in the list, or an interrupt occurs. If an interrupt occurs, the spryte engine continues to a convenient stopping point, then releases the D-bus.
  • CFD destination frame buffer
  • the CPU then vectors to an appropriate interrupt handler, and when done, returns to the routine which originally started the spryte engine. That routine checks the status bit SPRON in a memory mapped status bit register to determine whether the spryte engine stopped due to an interrupt or due to completion of processing, and if the former, restarts the spryte engine.
  • the CPU can have a separate bus to program memory, to thereby permit the CPU 102 to perform other tasks while the spryte engine 214 renders the sprytes.
  • the spryte engine can generate an interrupt for the CPU 102 when spryte processing has completed, at which time the CPU 102 can vector to an interrupt handler.
  • the DMA stack 312 includes an 8-register grouping for spryte control.
  • the eight registers are as follows:
  • the DMA engine of Figs. 3 and 4 loads in the first six words from the first SCoB beginning from the system memory address specified in the NEXT SCOB register in the DMA stack 312.
  • the address of the first word to load is read out of the NEXT SCOB register and provided to the memory address lines via source multiplexer 314.
  • the address is also incremented by adder/clipper 320 and written back via multiplexer 310 into the CURRENT SCOB register in DMA stack 312. All six words are read from memory in this manner, the CURRENT SCOB register maintaining the address of each next word to load.
  • the first SCoB word read, FLAGS is written into a 32-bit hardware register in address manipulator chip 106.
  • the next SCoB word read, NEXTPTR is written into the NEXT SCOB register in DMA stack 312.
  • SOURCEPTR is written into the SPRYTE DATA ADDRESS register of DMA stack 312, and
  • PIPPTR is written into the PIP ADDRESS register in DMA stack 312.
  • XPOS and YPOS are written to two memory mapped hardware registers XYPOSH and XYPOSL, each having the format of x,y. That is, the high-order 16 bits from XPOS and the high-order 16 bits from YPOS are written to the high- and low-order half words, respectively, of XYPOSH, and the low-order 16 bits of
  • XPOS and the low-order 16 bits of YPOS are written to the high and low half words, respectively, of XYPOSL.
  • the DMA control unit of Figs. 3 and 4 If the LDPPMP bit of the FLAGS word was set, then the DMA control unit of Figs. 3 and 4 expects the first (next) word of the optional seven words to be PPMPC. This word is written to a memory mapped PPMPC hardware register.
  • the DMA control unit of Figs. 3 and 4 performs a preamble load of either one or two words. If the SCOBPRE bit of FLAGS was set, then the preamble word(s) is (are) assumed to be at the end of the SCoB, in which case the CURRENT SCOB register in DMA stack 312 contains the address of the first preamble word. If SCOBPRE was not set, then the preamble word(s) is (are) assumed to be at the start of the data, in which case the SPRYTE DATA ADDRESS contains the address of the first preamble word.
  • the DMA control unit selects the appropriate register source for the starting address of the preamble load and returns the incremented addresses to the same register.
  • the first preamble word is always present and is loaded into the appropriate hardware registers.
  • the second preamble word is present only when the PACKED bit of the FLAGS word was zero, indicating that the spryte image data is in "totally literal" format.
  • the DMA unit reads this word, the information in the WOFFSET field is written to an offset register and the information in the TLHPCNT field is written to a pixel count register in the hardware.
  • the offset indicates the width of the totally literal spryte in memory, and is used by the DMA controller to calculate the start of each next line of the spryte source data.
  • the pixel count indicates the number of pixels to be transferred on each scan line of totally literal spryte source data. These two values are settable independently in order to permit the transfer of only a rectangular portion of a larger bit image, smaller than the overall bit image both in width and height.
  • the DMA control unit After the preamble load, if the LDPIP bit of the FLAGS word was set, the DMA control unit will read out 4, 8 or 16 words of PIN to IPN conversion information, beginning from the address in the PIP ADDRESS register in the DMA stack 312. Incremented addresses are also rewritten into the same DMA stack register.
  • the number of 4-word bursts to perform depends on the data compression format of the spryte image source data, which is specified in the BPP ("bits per pixel") field of the first preamble word.
  • the DMA unit of Figs. 3 and 4 begins transferring spryte image source data from system memory 108 to the data input FIFOs of the spryte engine 214.
  • the first one or two bytes of the first word contain a word offset from the start of the current line of source data to the start of the next line of source data, minus 2. This offset is used by the DMA controller both to calculate the start of each next line of source data and to set the length of a DMA transfer of the line of source data.
  • the DMA controller reads this word from the address specified in the SPRYTE DATA ADDRESS register of the DMA stack 312, incrementing the address and placing it into the ENGINE A FETCH ADDRESS register of the DMA stack 312.
  • the high-order 8 or 10 bits of this word are placed into the ENGINE A LENGTH register of the DMA stack 312, and the entire word is also sent to the spryte engine data input FIFO for corner engine A.
  • the spryte engine knows to ignore this word. Note that if the spryte image source data is in totally literal format, then the single offset value (as well as the pixel count value) specified in the second preamble word and described above applies to the entire spryte.
  • the DMA controller transfers additional words of spryte image source data for the current scan line in bursts of up to four words each, as requested by the spryte engine 214.
  • the starting address for each burst is found in the ENGINE A FETCH ADDRESS register of DMA stack 312, and the incremented addresses are placed in the same register.
  • the DMA controller decrements the value in the ENGINE A LENGTH register of DMA stack 312 according to the number of words transferred.
  • the DMA controller also updates the SPRYTE DATA ADDRESS register in DMA stack 312 by adding the offset specified in the first word of the scan line, so that that register always points to the next scan line to be processed.
  • the spryte engine 214 can also request DMA transfers of 4-word bursts of the next scan line of spryte image source data into the corner engine B data input FIFO, using the ENGINE B FETCH ADDRESS and ENGINE B LENGTH registers. In this manner, both corner engines A and B in the spryte engine 214 can operate on different scan lines of spryte image source data simultaneously, and the DMA controller can burst data to each as independently requested.
  • the BPP field and the LINEAR setting in the SCoB must match the format of the incoming source data. If they do not, then the results are unpredictable. These are some examples; there are many others.
  • RGB(a,b,c) (((a) ⁇ ⁇ 10)
  • RGB2(a,b,c) (RGB(a,b,c)*Ox00010001)
  • typedef long Color typedef long Coord; typedef long RGB888;
  • the spryte engine 214 is advantageously controlled using three software data structures known as Screen, ScreenGroup and Bitmap. These structures are owned by the system as opposed to a user task, and in order to prevent illegal combinations of control information from reaching the hardware, the information in these structures can be modified only by a routine running in the supervisor mode of the CPU 102.
  • the following are type definitions for the Screen, ScreenGroup and Bitmap data structures.
  • ItemNode bm ubyte *bm_Buffer, int32 bm_Width; int32 bm Height, int32 bm ClipWidth; int32 bm ClipHeight; int32 bm_VerticalOffset; int32 bm_Flags; int32 bm SCOBCTLO; int32 bm REGCTLO; int32 bm_REGCTL1; int32 bm_REGCTL2; int32 bm_REGCTL3; ⁇ Bitmap;
  • the Bitmap structure includes certain global information about a destination buffer (typically but not exclusively a display buffer) into which the spryte engine 214 is to render sprytes.
  • Such global information includes the base address of the buffer (bm_Buffer) , its width, height and characteristics (bm_Width, bm_Height and bm_Flags, respectively) , clipping widths and heights (bm_ClipWidth and bm_ClipHeight) beyond which the spryte engine 214 need not render sprytes, a vertical offset value (bm_VerticalOffset) , and values for the five spryte engine control registers (bmjSCOBCTLO, bm_REGCTL0, bm_REGCTLl, bm_REGCTL2, bm_REGCTL3).
  • the Screen structure points to a Bitmap structure to be displayed, and a ScreenGroup structure, as well as containing certain other information about the display.
  • the following are some sample routines to manipulate Bitmaps, ScreenGroups and Screens. Though some of these routines are trivial, it is advantageous that they be provided anyway as operating system routine callable by a user program. In this manner they can run in the supervisor mode of CPU 102.
  • bitmap->bm_ClipWidth • ciipwidth
  • bitmap- >bm_ClipHeight clipheight
  • bitmap->bm_REGCTL1 MAKE_REGCTL1( bitmap- >bm_ClipWidth, bitmap->bm_ClipHeight )
  • retvalue 0; DONE: return( retvalue );
  • Bitmap "bitmap; Item brtmaprtem; ubyte **bufptr, **bufptr2, *zbufptr, *prevbufptr; int32 *widthptr, *heightptr;
  • bitmapitem SuperCreateltem( MKNODEID(NODE GRAPHICS, TYPE BITMAP), NULL); if ( bitmapitem ⁇ 0 )
  • bitmap (Bitmap *)Locateltem( bitmapitem );
  • G1_WM0D32; break; case 64: i3 G2_RM0D64
  • G2_WM0D64; break; case 96: i3 G1_RM0D32
  • G2_WM0D64; break; case 128: i3 G2_RMOD128
  • bitmap- > bm_VerticalOffset currentHeight
  • currentHeight + bitmap- >bm_Height
  • ⁇ ⁇ retvalue sgitem; DONE: if ( retvalue ⁇ 0 ) if ( sgitem > 0 ) SuperextemalDeleteltem( sgitem );
  • the following routine illustrates how to directly modify a bitmap of a buffer.
  • ReadPixel ( Item bitmapltem, GrafCon *gc, Coord x, Coord y ) /* Read a pixel from the graphics context and return its value. " A read outside the bitmap boundaries returns a value of ⁇ 0.
  • SCoB spryte control blocks
  • SpryteData "scb Spryt ⁇ Data; void *scb_PIPPtr;
  • bitmap (Bitmap *)Checkltem( bitmapltem, NODE_GRAPHICS, TYPE_BITMAP ); if ( NOT bitmap )
  • the spryte engine 214 can map a spryte source image onto a quadrilateral (proper or degenerate) of any shape, given appropriate values in the SCoB for that spryte.
  • the following routine is useful to help users calculate correct values for the scb_X, scb_Y, scb_HDX, scb_HDY, scb_VDX, scb_VDY, scb_DDX and scb_DDY values in a SCoB, given the four points of a destination quadrilateral in the destination buffer.
  • MapSpryte( SCB "scb, Point "quad, int32 width, int32 height ) /* Take a spryte and create position and delta values to map
  • spryte rendering routines may be built on the above primitives. These spryte rendering routines may be written to merely create appropriate SCoBs and link them into a list for subsequent rendering by a routine such as DrawSprites, or they may call the spryte engine 214 directly. Such routines can include routines to draw horizontal or vertical lines with specified endpoints, routines to fill a specified rectangle, and routines to draw a line from the current pen position of a graphics context to a new position.
  • routines can all operate by creating a SCoB which points to spryte image source data containing a single pixel of the current graphics context foreground color, and setting up appropriate values in scb_X, scb_Y, scb_hdx, scb_hdy, scb_vdx, scb_vdy, scb_ddx and scb_ddy to have the spryte engine 214 expand the pixel to the desired shape.
  • the routine can then either link the SCoB into a list or use a routine like DrawSprytes to call the spryte engine 214 immediately.
  • routines such as these utilize a GrafCon data structure to maintain "current" foreground and background colors, and "current" X and Y pen positions within a destination bitmap.
  • Such a data structure may be defined as follows:
  • the following is an example of a routine that uses DrawSprytes to call the spryte engine 214 to draw a line in a specified bitmap.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Graphics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Electrophonic Musical Instruments (AREA)
  • Measurement And Recording Of Electrical Phenomena And Electrical Characteristics Of The Living Body (AREA)

Abstract

Des listes enchaînées de blocs de commande de lutins sont préparées dans la mémoire (108) et parcourues par un générateur de lutins. Chaque bloc (106) de commande de lutins commande la reproduction d'un lutin respectif dans le tampon de visualisation et contient des informations telles qu'un indicateur des données sources du lutin correspondant, des spécifications sur la position et sur les incréments requis pour atteindre un quadrilatère de destination, un mot de commande concernant les manipulations à effectuer sur les données sources de l'image du lutin, et une indication sur le format dans lequel les données sources de l'image du lutin se présentent, parmi une pluralité de formats disponibles. Une fois que la liste enchaînée est prête, on peut appeler le générateur de lutins (106) en inscrivant certaines valeurs dans des registres matériels spécifiques tracés dans la mémoire, puis en inscrivant des données fictives à une adresse que le matériel reconnaît comme constituant une commande de démarrage de l'opération de reproduction du lutin (106).
EP92925041A 1992-11-02 1992-11-02 Procede de commande d'un processeur generateur de lutins. Withdrawn EP0667017A4 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US1992/009350 WO1994010642A1 (fr) 1992-11-02 1992-11-02 Procede de commande d'un processeur generateur de lutins

Publications (2)

Publication Number Publication Date
EP0667017A1 true EP0667017A1 (fr) 1995-08-16
EP0667017A4 EP0667017A4 (fr) 1996-01-03

Family

ID=22231497

Family Applications (1)

Application Number Title Priority Date Filing Date
EP92925041A Withdrawn EP0667017A4 (fr) 1992-11-02 1992-11-02 Procede de commande d'un processeur generateur de lutins.

Country Status (5)

Country Link
EP (1) EP0667017A4 (fr)
JP (1) JPH08502844A (fr)
AU (1) AU3124493A (fr)
BR (1) BR9207171A (fr)
WO (1) WO1994010642A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU670941B2 (en) * 1992-04-29 1996-08-08 Canon Kabushiki Kaisha Object sorting and edge calculation for graphics systems
US5649173A (en) * 1995-03-06 1997-07-15 Seiko Epson Corporation Hardware architecture for image generation and manipulation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1990015395A1 (fr) * 1989-06-02 1990-12-13 Atari Corporation Appareil et procede de production d'images comprenant des symboles graphiques dynamiquement interactifs
WO1990015396A2 (fr) * 1989-06-02 1990-12-13 Atari Corporation Systeme et procede pour structure de blocs de commande de symboles graphiques

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4653013A (en) * 1984-11-19 1987-03-24 General Electric Company Altering spatial characteristics of a digital image
US4905168A (en) * 1986-10-15 1990-02-27 Atari Games Corporation Object processing for video system using slips and linked list
US4951038A (en) * 1987-05-15 1990-08-21 Hudson Soft Co., Ltd. Apparatus for displaying a sprite on a screen
US4951229A (en) * 1988-07-22 1990-08-21 International Business Machines Corporation Apparatus and method for managing multiple images in a graphic display system
US4952051A (en) * 1988-09-27 1990-08-28 Lovell Douglas C Method and apparatus for producing animated drawings and in-between drawings

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1990015395A1 (fr) * 1989-06-02 1990-12-13 Atari Corporation Appareil et procede de production d'images comprenant des symboles graphiques dynamiquement interactifs
WO1990015396A2 (fr) * 1989-06-02 1990-12-13 Atari Corporation Systeme et procede pour structure de blocs de commande de symboles graphiques

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO9410642A1 *

Also Published As

Publication number Publication date
EP0667017A4 (fr) 1996-01-03
BR9207171A (pt) 1995-12-12
WO1994010642A1 (fr) 1994-05-11
AU3124493A (en) 1994-05-24
JPH08502844A (ja) 1996-03-26

Similar Documents

Publication Publication Date Title
US5596693A (en) Method for controlling a spryte rendering processor
US5701444A (en) Three-dimensional graphics subsystem with enhanced support for graphical user interface
US5835096A (en) Rendering system using 3D texture-processing hardware for accelerated 2D rendering
US5727192A (en) Serial rendering system with auto-synchronization on frame blanking
US6111584A (en) Rendering system with mini-patch retrieval from local texture storage
US5815166A (en) Graphics subsystem with slaveable rasterizer
US5572235A (en) Method and apparatus for processing image data
US5764228A (en) Graphics pre-processing and rendering system
US6025853A (en) Integrated graphics subsystem with message-passing architecture
US5798770A (en) Graphics rendering system with reconfigurable pipeline sequence
US6348919B1 (en) Graphics system with optimized use of unified local and frame buffers
US5805868A (en) Graphics subsystem with fast clear capability
US5764243A (en) Rendering architecture with selectable processing of multi-pixel spans
US5777629A (en) Graphics subsystem with smart direct-memory-access operation
US5742796A (en) Graphics system with color space double buffering
US6108014A (en) System and method for simultaneously displaying a plurality of video data objects having a different bit per pixel formats
EP1323131B1 (fr) Procede et appareil pour la mise en oeuvre d'un superechantillonnage anticrenelage d'une scene complete
US7737982B2 (en) Method and system for minimizing an amount of data needed to test data against subarea boundaries in spatially composited digital video
US5594854A (en) Graphics subsystem with coarse subpixel correction
US5867166A (en) Method and system for generating images using Gsprites
US6008820A (en) Processor for controlling the display of rendered image layers and method for controlling same
US5864342A (en) Method and system for rendering graphical objects to image chunks
US5856829A (en) Inverse Z-buffer and video display system having list-based control mechanism for time-deferred instructing of 3D rendering engine that also responds to supervisory immediate commands
US5969726A (en) Caching and coherency control of multiple geometry accelerators in a computer graphics system
US6567091B2 (en) Video controller system with object display lists

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19950502

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LI LU MC NL SE

A4 Supplementary search report drawn up and despatched
AK Designated contracting states

Kind code of ref document: A4

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LI LU MC NL SE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CAGENT TECHNOLOGIES, INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 19980603