JP5070540B2 - Game machine - Google Patents

Description

  The present invention relates to a screen display method for performing a predetermined effect display during a game in a display area of a display device provided on a game board surface.

  In gaming machines such as pachinko machines and slot machines, various effects are displayed during the game using a display device provided in the gaming board. A liquid crystal panel is often used for this effect display. The liquid crystal panel displays an image with pixels arranged in a matrix. Display data for displaying an image is generated by the following procedure, for example. First, the CPU for controlling the effect display receives the display command, analyzes the contents, and determines the contents of the screen to be displayed with reference to schedule data prepared in advance. Then, a drawing command is output to a VDP (Video Display Processor) based on the schedule data. The VDP expands the drawing command into a bitmap and generates display data in units of pixels and outputs it to the liquid crystal panel. Some VDPs make it possible to implement various types of drawing by dividing drawing commands into layers and adjusting the overall transparency and color tone of each layer.

  A display screen of a gaming machine is often configured by arranging sprites prepared in advance and stored in a character ROM. The sprite means, for example, the fish picture shown in FIG. Patent Document 1 discloses display control using sprites. VDP needs to perform drawing using this sprite at a rate of one sheet per 16 msec or 32 msec so as to match the frame rate of the display device. As the number of sprites increases, the number of accesses to the character ROM increases, and the time required for drawing on the display screen increases. In order to be able to use various sprites so that an interesting production screen can be displayed, it is preferable to improve the sprite reading speed. From this point of view, Patent Document 1 discloses that a sprite stored in a character ROM is transferred to a DRAM in advance when used for screen display, thereby improving the sprite reading speed and allowing a large number of sprites to be used. The technology to do is also disclosed.

JP-A-9-28880

  However, even if the sprite reading speed is improved, there is a limit to the number of sprites that can be used to perform drawing in accordance with the frame rate, as long as there is an upper limit on the drawing capability of VDP. In recent years, the resolution of display devices has been increasing in the field of gaming machines, and as the number of pixels to be drawn has increased and the amount of sprite data has increased, the number of sprites that can be used for drawing has been further suppressed. Tend to be. With the number of sprites limited in this way, taking into account this limitation and the degree of overlap between sprites, it has been a heavy burden to design an interesting display screen. In addition, there is a limit to the variety of effect display realized thereby, and it has been difficult to realize a more interesting effect display. In view of these problems, the present invention has an object to realize more various presentation displays while taking into account that there is an upper limit in the drawing capability of VDP.

The present invention is directed to a gaming machine that performs a predetermined effect display during a game in a display area of a display device provided on a game board surface. The gaming machine as the first configuration corresponds to a pachinko machine or a spinning-type gaming machine. The display device is a device in which display pixels are two-dimensionally arranged, and a liquid crystal panel, a plasma display, an organic EL, or the like can be used. The gaming machine generates a display data for driving the display device in response to a display command from the sub control board that outputs a display command for controlling the effect display according to the game situation and the sub control board. An effect control means including a display control board for outputting to the display device is provided. In addition, a main control board that integrates control of the entire gaming machine, a payout board that controls payout of prize balls, medals, and the like may be provided.

  The display control board includes a drawing control unit, a display data generation unit, and a display data storage unit. The drawing control unit outputs a drawing command that defines the configuration of the screen to be displayed on the display device in response to the display command from the sub control board. A drawing command may be set and output directly from the display command, or a series of screens to be displayed on the display device (hereinafter, each screen is referred to as a “frame”) is stored in advance in association with each other. The drawing command may be set and output based on this frame. Further, a method may be adopted in which this frame is stored as a drawing command group, and these are read out and output sequentially.

  The drawing command is a command for generating data representing the display content of the frame expanded by the pixel unit of the display device. When sprite data representing a predetermined sprite displayed on the screen in units of pixels of the display device is stored in a character memory prepared in advance, the drawing command includes an arrangement of the sprite, a plurality of sprites. How to superimpose can be included. The drawing command may include a command for designating a figure or line segment other than the sprite. Further, it is not always necessary to use a sprite, and only drawing of a figure or a line segment may be designated by a drawing command.

  In this specification, “character” and “sprite” are used in the following meaning. The sprite means an image displayed as a unit on the screen of the gaming machine. For example, when various persons are displayed on the screen, data for drawing each person is referred to as “sprite”. In order to display a plurality of persons, a plurality of sprites are used. Not only a person but also a house, a mountain, a road and the like constituting a background image can be used as sprites. The entire background image may be a single sprite. The gaming machine can display various images by determining the arrangement of each sprite on the screen and determining the vertical relationship when the sprites overlap.

  In a gaming machine, for the convenience of handling data, each sprite is configured by combining a plurality of rectangular regions of a certain size such as 64 pixels vertically and horizontally. Data for drawing this rectangular area is called a “character”. In the case of a small sprite, it can be expressed by one character, and in the case of a relatively large sprite such as a person, for example, it can be expressed by a total of 6 characters arranged in a horizontal 2 × vertical 3, etc. . If the sprite is larger than the background image, it can be expressed using a larger number of characters. The number and arrangement of characters can be arbitrarily specified for each sprite.

  The display data generation unit generates display data that defines the display state of each pixel of the display device based on the drawing command. In the display device of the present invention, the display data is generated using a row or a column of the pixel array in the display device as a generation unit. In a display device in which pixels are two-dimensionally arranged vertically and horizontally, when a main scan is performed in units of rows (array in the horizontal direction) and a sub-scan is performed in the column direction (vertical direction), the screen is displayed. The display data generation unit preferably generates display data using a line as a generation unit. Conversely, when main scanning is performed in units of columns, it is preferable to use columns as generation units. However, when a frame memory for holding display data of the entire display control board frame is provided, any direction may be used as a generation unit.

  The display data generation unit has an upper limit on the total number of pixels that can be drawn for each generation unit. This upper limit is a value determined by the display period of the frame and the processing capability of the display data generation unit. The drawing control unit outputs a mask command for drawing a predetermined invisible figure as a mask figure for a portion to be masked in the screen. In general, a mask means to hide a part, but in this specification, a mask makes a part of a figure to be rendered transparent, that is, allows the background image to be seen through. Say processing. The part to be masked may be directly specified by a display command, or may be specified by data of each frame specified according to the display command. The number of mask commands is a number that allows the number of pixels drawn by the display data generation unit to exceed the upper limit value alone or together with the drawing command.

  According to the present invention, in the portion where the above-described mask command is output, the number of pixels to be drawn by the display data generation unit may exceed the upper limit value (hereinafter referred to as “sprite over”). . If the upper limit is exceeded, further drawing becomes impossible, and as a result, a part of the drawing command is lost without being drawn. As a result, a display in which a part of the drawing command is omitted in the generation unit can be performed, and a mask can be easily realized. For example, when generating display data in units of lines, it is possible to easily display a figure to be drawn in a state where only a part corresponding to a specific line is missing. If a mask command sufficient to cause sprite over is output, such a mask can be reliably realized.

  If a part of the sprite is masked by the conventional technique without using the present invention, a method of preparing a new sprite with the masked part made transparent or an opaque background image corresponding to the masked part is prepared. I could only take the method of drawing the foreground. In the former method, in order to change the masked part arbitrarily during the game, it is necessary to prepare many sprites with different transparent parts for one figure, increasing the sprite storage capacity, This leads to the problem of complicated read control. In the latter method, in the display data generation unit capable of handling the layers, it is necessary to set the foremost surface as an opaque layer, which reduces the degree of freedom in setting the transparency of each layer. An example is shown in FIG.

  FIG. 13 is an explanatory view showing a screen display example in the prior art. The image shown in the foreground is displayed by overlaying the front layer of the background layer representing the sea with the layer that displays the start memory indicating the number of winning game balls to the start winning opening with the layer depicting the fish, the heart and the spade. An example to be shown. The start memory layer is placed in front of the layer where the fish is displayed with the transparency set to “opaque”, so a part of the fish is hidden in the start memory on the entire screen. Is done. In this method, in order to display an image in a state where a part of the fish is masked, the foremost layer is constrained to the setting of “opaque”.

  On the other hand, according to the present invention, it is possible to easily realize a mask without causing these problems by causing sprite over. As a result, it is possible to realize an interesting production display by taking advantage of the new effect of masking a part of the sprite. In addition, in the display data generation unit capable of handling layers, the degree of freedom of setting for the foremost layer is increased, and it is possible to realize various presentation displays. Also, even if another sprite overlaps the front of a sprite, you can easily make the front sprite partially transparent and display the back sprite by applying a mask if necessary. Since it becomes possible, there is also an advantage that it is possible to design an effect display without being excessively aware of the overlap between sprites.

  In the present invention, the mask command is preferably output at a timing at which at least one mask graphic is drawn before the drawing command by the display data generation unit. For example, when drawing is performed in the order of command output, an intended mask can be realized by outputting at least one mask command before the drawing command. However, the mask command does not need to precede all drawing commands, and only needs to precede the drawing command to be masked.

  The display data generation unit may be able to generate display data preferentially from the layer on the back side based on a drawing command defined by being divided into a plurality of layers superimposed from the back to the front. In this case, the drawing control unit may output a drawing command for a figure that should be displayed in the same area as the mask command or in a layer on the back side in the area for outputting the mask figure. In this way, whether or not masking is possible can be easily controlled.

  The drawing control unit may output the mask command within a range not reaching the upper limit value only by the mask command. If a mask command is output in such a way that the number of pixels to be drawn is slightly less than the upper limit value, sprite over may or may not occur depending on the size and number of figures to be drawn according to the drawing command. It is possible to easily realize an interesting and irregular display.

  The drawing control unit may output a drawing command at an indefinite position between a plurality of mask commands. That is, it is not necessary for all mask commands to precede the drawing command, and the mask command may be output after the drawing command. Further, the position of the drawing command for a plurality of mask commands, that is, the output order of the mask command and the drawing command may be indefinite. By doing so, it is possible to change whether or not the masking is performed according to the output order of the drawing commands, and it is possible to easily realize an interesting and irregular display.

  The mask figure can have various shapes, for example, a shape in which a plurality of rows or columns as generation units are arranged adjacent to each other. By doing so, a belt-like mask can be realized and can be used for various effects display.

  When masking in a strip shape in this way, the mask figure may be mixed with shapes having different numbers. That is, bands having different widths may be mixed. By doing so, whether or not the mask is masked depending on the size and number of figures drawn by the drawing command changes around the belt-like mask area, and it is easy to realize interesting and irregular display. be able to.

  Further, the position for drawing the mask figure in the screen does not have to be fixed, and may be changed. By changing the portion to be masked, a more interesting display can be easily realized.

  As described above, the present invention can adopt a configuration in which drawing is performed using sprite data. In this case, the sprite data may be stored in a character memory composed of a memory element that requires a refresh operation in order to maintain the storage. The character memory is provided with a character memory control device for controlling sprite reading in response to a request from the display data generation unit. When a predetermined refresh character is requested, the character memory control device may deliver a predetermined invisible figure as a sprite to the display data generation unit and perform a refresh operation. In this way, it is possible to easily perform a refresh operation during the drawing command output process. When such a character memory is provided, a drawing command for designating drawing of a refresh character may be output as a mask command. This makes it possible to efficiently perform the character memory refresh operation and the mask in parallel.

  Specifically, the present invention can be applied in the following manner. Targeting gaming machines that perform a predetermined winning action when a game ball enters a predetermined starting prize opening provided on the game board surface, at least a part of the screen has a winning action after entering the starting prize opening. Consider a case in which a start memory display that displays the number of game balls that have not been completed is included. In this case, the drawing control unit outputs the drawing command and the mask command so that the mask graphic is drawn on the start storage display until the upper limit value is exceeded after the start storage display is drawn.

By doing so, it is possible to avoid the start memory display being hidden by other graphics. This effect will be described more specifically. Even when the present invention is used, the start memory display can be displayed in the foreground by outputting the start memory display drawing command last. However, in this case, it is necessary to set the frame in advance in consideration of the size, number, position, etc. of other figures so that the start memory display is drawn without causing sprite over. The design load increases. In addition, in a VDP that can handle layers, the start-up memory display is arranged in the foreground layer, so that the foreground layer is fixed to the “opaque” setting, and the transparency setting is set. It will be constrained. On the other hand, in the present invention, the area corresponding to the start memory display is masked, and other figures cannot be drawn by causing sprite over. Since the start memory display can be drawn first, it is possible to easily avoid the adverse effects caused by the above-described design load and layer setting restrictions.
According to a second aspect of the present invention, there is provided a gaming machine that performs a predetermined effect display during a game, the display device being provided on a gaming board surface, wherein display pixels are two-dimensionally arranged, and Effect control means for controlling display of display according to the game situation by generating display data for driving the display device and outputting it to the display device, wherein the effect control means is the game A drawing control unit that outputs a drawing command that defines a configuration of a screen to be displayed on the display device according to the situation, and display of each pixel of the display device based on the drawing command from the drawing control unit A display data generating unit that generates the display data defining a state using a row or a column of the array as a generation unit, and the display data generating unit is divided into a plurality of layers stacked from the back to the front Defined drawing When the display data is preferentially generated from the back side layer based on the command, there is an upper limit on the total number of pixels that can be drawn for each generation unit, and the drawing control unit In the case of outputting a mask command for drawing a predetermined invisible figure as a mask figure for a portion to be processed, the number of mask commands to be outputted is set as the number of pixels drawn by the display data generation unit is set to the upper limit value. In addition to setting the number to exceed, the drawing command for the graphic to be displayed in the area where the mask graphic is output may be output in the same layer as the mask command or on the back side layer.
Also in the second configuration, as described above, by causing sprite over, a mask can be easily realized without causing the above-described adverse effects. As a result, it is possible to realize an interesting production display by taking advantage of the new effect of masking a part of the sprite. In addition, in the display data generation unit capable of handling layers, the degree of freedom of setting for the foremost layer is increased, and it is possible to realize various presentation displays. Also, even if another sprite overlaps the front of a sprite, you can easily make the front sprite partially transparent and display the back sprite by applying a mask if necessary. Since it becomes possible, there is also an advantage that it is possible to design an effect display without being excessively aware of the overlap between sprites. In addition, when the display data generation unit preferentially generates display data from the back side layer based on the drawing commands defined by dividing the plurality of layers from the back to the front, the drawing control unit Whether or not masking is possible can be easily controlled by outputting a drawing command for a figure to be displayed in the same area as the mask command or in a layer on the back side in the area where the mask figure is output.

  In the present invention, it is not necessary to have all the various features described above, and some of them may be omitted, or may be applied in combination as appropriate. In addition, the above-described characteristic portion in the present invention may be realized by hardware or software.

Embodiments of the present invention will be described in the following order. In the present embodiment, a configuration example as a pachinko machine is shown, but the gaming machine may be a spinning-type gaming machine.
A. Game machine configuration:
B. Control hardware configuration:
C. Design control board:
D. Example of VDP configuration:
E. Display control processing:
F. Drawing process:
G. Drawing command output processing:
H1. Modification (1):
H2. Modification (2):

A. Game machine configuration:
FIG. 1 is a front view of a pachinko machine 1 as an embodiment. The pachinko machine 1 has a game board 4 provided with a game area 6 in the center. The player can play a game by operating the handle 8 and driving a game ball into the game area 6 to win a winning opening. When a game ball wins a start winning opening 9 which is one of the winning openings, the pachinko machine 1 performs a lottery, and it is determined whether or not it is a “hit” according to the result. When a big hit occurs, a big hit game such as opening the big prize opening 10 for a predetermined period is performed.

  The result of the above lottery is displayed on a special symbol display device 41 composed of four lamps. In the center of the game area 6, an LCD 16 is provided, and various effect screens (sometimes referred to as decorative symbols) are displayed during the game. An effect screen corresponding to the state of the game is also displayed when winning at the start winning opening 9 or when a big hit occurs. Decorative symbols vary depending on the game situation. In the process of displaying the lottery results, when reaching a reach state where the possibility of a big hit is high, a screen full of speed is displayed, and the player is thrilled and excited.

B. Control hardware configuration:
FIG. 2 is a block diagram showing a control hardware configuration of the pachinko machine 1. The pachinko machine 1 is controlled by distributed processing of control boards such as the main control board 3, the payout control board 25, the sub control board 35, and the symbol control board 30. The main control board 3, the payout control board 25, and the sub control board 35 are each configured as a microcomputer having a CPU, a RAM, a ROM, and the like, and implement various control processes according to programs recorded in the ROM. .

  In the pachinko machine 1 according to the embodiment, input from the outside to the main control board 3 is restricted in order to prevent various frauds. The main control board 3 and the sub control board 35 are connected by a unidirectional parallel electric signal, and the main control board 3 and the payout control board 25 are connected by a bi-directional serial electric signal for the necessity of control processing. Yes. The payout control board 25 and the sub control board 35 operate in response to commands from the main control board 3, respectively. The symbol control board 30 operates in response to a command from the sub control board 35. The pachinko machine 1 also has a mechanism that is directly controlled by the main control board 3. In the figure, as an example of a device controlled by the main control board 3, a special winning opening solenoid 18 for driving the special winning opening 10 and a special symbol display device 41 are illustrated. In addition to this, the main control board 3 can control displays such as a normal symbol display device, a special symbol hold lamp, a normal symbol hold lamp, a big hit type display lamp, and a status display lamp. Further, detection signals from various sensors are input to the main control board 3 in order to control the operation during the game. In the figure, the input from the winning detector 15a is illustrated as an example. The winning detector 15 a is a sensor for detecting a winning at the start winning opening 9. The main control board 3 can execute the jackpot game by performing the lottery described above according to the signal from the winning detector 15a. Various other inputs are made on the main control board 3, but the description thereof is omitted here.

  Other controls during the game are performed via the payout control board 25 and the sub-control board 35. The payout control board 25 controls the launch and payout of the game ball being played in the following procedure. The launch of the game ball is directly controlled by the launch control board 47. That is, when the player operates the launch handle 8, the launch control board 47 controls the launch motor 49 according to the operation to launch a game ball. The game ball is fired only under a situation where the touch detector 48 detects that the player is touching the firing handle 8. The payout control board 25 indirectly controls the launch of the sphere by sending a launch control signal to the launch control board 47.

  When a command indicating that a prize has been won during the game is received from the main control board 3, the payout control board 25 controls the payout motor 20 in the prize ball payout device 21 and regulates the number of balls by the payout ball detector 22. Pay out a number of balls. The operation of the payout motor 20 is monitored by a motor drive sensor 24, and when an abnormality such as a ball bit or a ball break is detected, the payout control board 25 displays an error code on the display unit 4a. When an error is displayed, it can be recovered by operating the operation switch 4b after the attendant has removed the abnormality.

  The sub-control board 35 controls effects such as voice, display, and lamp lighting during the game. These effects vary according to the status during the game, such as a normal time, a prize, a big win, an error, an alarm when an illegal act or other abnormality occurs. When an effect command corresponding to each status is transmitted from the main control board 3, the sub control board 35 activates a program corresponding to each command to realize the effect instructed from the main control board 3. .

  In the present embodiment, the sub-control board 35 directly controls the speaker 29 as shown in the figure. The LCD 16 is controlled via the symbol control board 30. The circuit configuration of the symbol control board 30 will be described later. The lamps to be controlled by the sub-control board 35 include the panel decoration lamp 12 provided on the game board surface and the frame decoration lamp 31 provided on the frame. The sub control board 35 is connected to the panel decoration lamp 12 and the frame decoration lamp 31 via the lamp relay boards 32 and 34, and can blink each lamp individually.

C. Design control board:
FIG. 3 is a block diagram showing a circuit configuration of the symbol control board 30. The symbol control board 30 includes a character ROM 340, a first character RAM 321, a second character RAM 322, a CPU 311, a control ROM 325, a VDP 330, and a memory interface control circuit 324.

  The symbol control board 30 controls the effect display according to the symbol display control program based on the display command from the sub-control board 35. A scaler 390 and a frame buffer 397 are provided between the VDP 330 and the display device 16. The scaler 390 has a function of temporarily storing display data output from the VDP 330 in the frame buffer 397 and outputting it to the display device 16 as appropriate. In this process, the scaler 390 enlarges / reduces the display data and performs a process to match the number of pixels of the display device 16 or superimposes an OSD (On Screen Display) figure prepared in advance on the display data and outputs it. It is also possible.

  A CPU (Central Processing Unit) 311 controls display on the display device 16 based on a display command from the sub-control board 35. The VDP 330 generates display data to be displayed on the display device 16 based on an instruction from the CPU 311 (central processing unit). Various circuits constituting the symbol control board 30 are provided on a single board having, for example, six wiring layers.

  The CPU 311 reads from the control ROM 325 drawing parameters that define display data generation conditions for realizing a display mode corresponding to the display command. As the drawing parameters, color palette data defining drawing color information, layer data setting transparency of each layer, sprite attribute data defining sprite drawing conditions, and background drawing conditions are specified. Background attribute data. The CPU 311 sets (instructs) the drawing parameters read from the control ROM 325 in various registers of the VDP 330. The VDP 330 generates display data to be output to the display device 16 based on the drawing parameters.

  In addition, the symbol control board 30 includes a character ROM 340 and a control ROM 325. The control ROM 325 stores a symbol display control program executed by the CPU 311 and a development table for managing development information referred to by the CPU 311 and the like in a nonvolatile manner. This expansion table is referred to when displaying the above-described variation display pattern, and manages the combination of scenes included in the variation display pattern and the display order of each scene. The symbol display control program may include the function of this expansion table.

  On the other hand, the character ROM 340 stores in advance a group of data (data necessary for video display) related to each scene constituting the variable display pattern. That is, it includes sprite data (or moving image data) as a material necessary for displaying each scene. Here, the expansion table manages an address as a position storing each sprite data (or moving image data) and an address as a position storing each sprite data in the character ROM 340.

  The moving image data is stored in the character ROM 340 in a state where the data structure is compressed by a preset irreversible compression method. On the other hand, the sprite data is stored in the character ROM 340 in a state where the data structure is compressed by a reversible compression method set in advance. In the present embodiment, the compressed moving image data is referred to as “compressed moving image data”.

  Here, the sprite has a non-transparent area that does not visually transmit the moving image and a transmissive area that visually transmits the moving image as the background when superimposed on the moving image as the background. ing. In the present embodiment, the compressed sprite data is referred to as “compressed sprite data”.

  Next, the CPU 311 includes an SDRAM (Synchronous Dynamic Random Access Memory) as a built-in memory. The CPU 311 (operation instruction processor) is connected to a control ROM 325 (control memory), a VDP 330 (video display processor), and a memory interface control circuit 324. The control ROM 325 is a read-only memory that stores not only the expansion table but also a symbol display control program for controlling the effect display under the control of the CPU 311.

  The CPU 311 controls the operation of the VDP 330 based on the display command from the sub control board 35 by the operation of the symbol display control program read from the control ROM 325 to the SDRAM. The CPU 311 analyzes the display command received from the sub control board 35, and controls the execution of the effect display according to the analysis result.

  Specific examples of this effect display include a reach effect display and a round display in a special game state. This reach effect display indicates to the player, etc., that the player is likely to win in the jackpot lottery triggered by the winning of a game ball, or may not win, but as if he will win a jackpot. It is a production display that is expected. On the other hand, the round display represents an effect display in each round in the special game state when, for example, the state is shifted to the special game state.

  When executing the variable display of the symbol related to the reach effect display or the like, the CPU 311 determines each scene to be included in the variable display pattern in the reach effect display or the like and the display order of each scene with reference to the development table. .

C1. Configuration example of the memory interface control circuit 324:
The memory interface control circuit 324 illustrated in FIG. 3 has a function of controlling an interface related to data exchange among the character ROM 340, the first character RAM 321 and the second character RAM 322, and the VDP 330 under the control of the CPU 311. When the character RAMs 321 and 322 are referred to from the VDP 330 via the memory interface control circuit 324, since the same sprite data is arranged in the same location (address space) in the character RAMs 321 and 322, the character RAMs 321 and 322 Even if the characters are switched, the character RAMs 321 and 322 are not distinguished from each other, and it looks as if one character RAM exists.

  The memory interface control circuit 324 includes a CPU interface 316, a compressed data memory controller 312, a moving image data decompression controller 327, sprite data decompression controllers 328 and 329, a decompression data memory controller 315, a first character RAM controller 314, and a second character RAM controller. 317 and a VDP interface 320 are provided. The memory interface control circuit 324 is connected to the character ROM 340, CPU 311, VDP 330, and character RAMs 321 and 322, respectively.

  The CPU interface 316 controls the interface between the CPU 311 and the memory interface control circuit 324. In addition to the CPU 311, the compressed data memory controller 312, the moving image data expansion controller 327, the sprite data expansion controllers 328 and 329, and the expansion data The memory controller 315 is connected.

  These compressed data memory controller 312, moving image data decompression controller 327, sprite data decompression controllers 328 and 329, and decompressed data memory controller 315 are respectively registered in registers 312a, 327a (moving image register), 328a (sprite register), and 329a (sprite register). ), 315a. These registers 312a, 327a, 328a, 329a, 315a are connected to the CPU interface 316.

C2. CPU interface configuration:
The CPU interface 316 controls writing to the registers 328a and 329a by the CPU 311 as a sprite expansion control processor, and also controls writing to the register 327a (moving image register) by the CPU 311 as a moving image expansion control processor.

  The CPU interface 316 controls writing by the CPU 311 to the register 315a of the decompressed data memory controller 315 and the register 312a of the compressed data memory controller 312.

  That is, the setting values are written into the registers 312a, 327a, 328a, 329a, and 315a by the CPU 311 via the CPU interface 316, respectively. The compressed data memory controller 312, the moving image data decompression controller 327, the sprite data decompression controllers 328 and 329, and the decompression data memory controller 315 are controlled by the CPU 311 via registers 312a, 327a, 328a, 329a, and 315a, respectively. It has become.

  The moving image data decompression controller 327 starts or stops the decompression processing of the lossy compressed data for the compressed moving image data according to the set value written in the moving image register 327a. The moving image data decompression controller 327 also reads out the compressed moving image data read start address of the character ROM 340 serving as the transfer source, the number of data to be read (number of bytes), and the character RAM 321 serving as the transfer destination according to the set values written in the moving image register 327a. Alternatively, an expansion data write address to the character RAM 322 is designated. The moving image data decompression controller 327 is provided with a status register for confirming the decompression processing state and the other (execution and stoppage).

  On the other hand, the sprite data decompression controller 328 and the sprite data decompression controller 329 start the decompression process of the lossless compression data for the compressed sprite data or stop the decompression process according to the setting values written in the register 328a and the register 329a, respectively. It has become. Also, the sprite data expansion controllers 328 and 329 read the compressed moving image data read start address of the character ROM 340 that is the transfer source, the number of data to be read (number of bytes), and transfer according to the setting values written in the moving image registers 328 and 329a, respectively. The write address of the decompressed data to the character RAM 321 or the character RAM 322 that is the destination is designated. Each of the sprite data decompression controllers 328 and 329 is provided with a status register for confirming the decompression processing state and others (execution and stoppage).

C3. Configuration of two sprite extension devices:
The CPU 311 as a sprite expansion control processor has a function of independently controlling expansion operations by the sprite data expansion controllers 328 and 329 as two sprite expansion devices. The sprite data decompression controllers 328 and 329 are compressed sprites according to a preset sprite decompression method based on the registers 328a and 329a written by the CPU 311 and the CPU 311 writing to the registers 328a and 329a, respectively. A sprite decompression unit (not shown) for decompressing data into sprite data is included.

  First, if compressed sprite data obtained by compressing sprite data is stored in the character ROM 340, the storage capacity of the character ROM 340 can be effectively utilized to store more sprite data, but sprites are included. When displaying a scene, it is necessary to decompress the compressed sprite data read from the character ROM 340.

  If this sprite data is to be decompressed by the sprite data decompression controllers 328 and 329, considering that switching between the storage state and the readout state in the character RAMs 321 and 322 is necessary, at first glance, decompression control becomes complicated. Is also possible. However, in this embodiment, even when the sprite data decompression controllers 328 and 329 exist, the sprite data is generated by decompressing the compressed sprite data by simple control of each writing to the sprite registers 328a and 329a by the CPU 311. Therefore, the extension control is simplified as a whole.

C4. Configuration of video expansion device:
The CPU 311 as a moving image expansion control processor has a function of controlling the expansion operation by the moving image data expansion controller 327. The moving image data expansion controller 327 expands the compressed moving image data according to a preset moving image expansion method based on the register 327a written by the CPU 311 and the writing to the register 327a by the CPU 311 as described above. It is configured to include a moving image decompression unit used as data.

  First, if the compressed moving image data obtained by compressing the moving image data is stored in the character ROM 340, the storage capacity of the character ROM 340 can be effectively used to store data relating to more moving images. When displaying a scene including a moving image as well as a sprite, it is necessary to expand not only the compressed sprite data read from the character ROM 340 but also the compressed moving image data.

  Here, when the sprite data is expanded as described above and the moving image data is to be expanded by the moving image data expansion controller 327, it is necessary to switch between the storage state and the reading state in the character RAMs 321 and 322. Considering this, the extension control may be complicated.

  However, according to the present embodiment, even when the moving image data expansion controller 327 exists in addition to the sprite data expansion controllers 328 and 329, the compression is performed by the simple control of writing to the moving image register 327 a by the CPU 311. As the sprite data is expanded, the compressed moving image data can be expanded to generate moving image data, so that the expansion control is simplified as a whole.

  The compressed data memory controller 312 reads compressed moving image data and compressed sprite data for displaying each scene included in the variable display pattern to be displayed from the character ROM 340 according to the set value written in the register 312a. Take control.

  Here, the CPU 311 sets an access timing according to the type of the character ROM 340, for example, in the register 312a of the compressed data memory controller 312 via the CPU interface 316.

  Specifically, the settings written by the CPU 311 to the moving image register 327a of the moving image data expansion controller 327, the register 328a of the sprite data expansion controller 328, and 329a of the sprite data expansion controller 329 according to the contents of the expansion table of the control ROM 325, respectively. The transfer source address of the storage area of the character ROM 340 is designated according to the value. When the CPU 311 designates the compressed data memory controller 312 in this way, the compressed data memory controller 312 receives the compressed sprite data and the compressed moving image data from the storage area of the character ROM 340 corresponding to the designated transfer source address based on the written setting values. Is read out and transferred to the sprite data expansion controllers 328 and 329 and the moving image data expansion controller 327.

  The moving image data expansion controller 327 has a function of expanding compressed moving image data compressed by an irreversible compression method by an expansion method corresponding to the irreversible compression method. On the other hand, the sprite data decompression controller 328 has a function of reading compressed sprite data compressed by a reversible compression method from the character ROM 340 and decompressing the compressed sprite data by a decompression method corresponding to the reversible compression method.

  In this embodiment, the memory interface control circuit 324 is provided with two sprite data expansion controllers 328 and 329 as expansion means for expanding the compressed sprite data read from the character ROM 340. These sprite data expansion controllers 328 and 329 are not fixedly associated with the character RAMs 321 and 322, but are provided according to the number of character RAMs 321 and 322, respectively. The sprite data decompression controllers 328 and 329 can be set (switched) in correspondence with the character RAMs 321 and 322, respectively, and decompress the compressed sprite data read from the character ROM 340 independently into sprite data.

  The moving image data is expanded by the moving image data expansion controller 327 when the CPU 311 writes to the register 327a, and each moving image data is transferred from the moving image data expansion controller 327 to the expanded data memory controller 315.

  Also, the sprite data is decompressed independently by the sprite data decompression controllers 328 and 329 when the CPU 311 writes to the registers 328a and 329a, and the decompressed data memory is independent from the sprite data decompression controllers 328 and 329. It is delivered to the controller 315.

C5. Expanded data memory controller:
The expanded data memory controller 315 is designated with a switching condition between a storage state (also referred to as “development state”) and a read state in the first character RAM 321 and the second character RAM 322 according to the set value written in the register 315a by the CPU 311. The In the present embodiment, for example, the first character RAM 321 and the second character RAM 322 are switched in synchronization with the rising edge of the external signal.

  The expanded data memory controller 315 controls the first character RAM controller 314 and the second character RAM controller 317 in accordance with the set value written in the register 315a by the CPU 311. The first character RAM controller 314 has a function of controlling the expansion and reading of sprite data and moving image data to the first character RAM 321. On the other hand, the second character RAM controller 317 has a function of controlling the expansion and reading of sprite data and moving image data to the second character RAM 322. In the present embodiment, sprites and moving images are illustrated as scene materials, but in the following description, sprite data is mainly illustrated as scene materials.

  Furthermore, these character RAM controllers 314 and 317 (sometimes referred to as “memory refresh units”) have a function of executing a refresh operation on the character RAMs 321 and 322 under the control of the development data memory controller 315, respectively. The expanded data memory controller 315 controls the execution of the refresh operation for the character RAM controllers 314 and 317 in accordance with instructions from the CPU 311. In the present embodiment, the first character RAM controller 314 performs a refresh operation on the first character RAM 321 and the second character memory controller 317 performs a refresh operation on the second character RAM 322. It has been.

  The expanded data memory controller 315 (refresh data providing unit) has refresh character data for causing the character RAMs 321 and 322 to perform a refresh operation, and has a function of providing the refresh character data to the VDP 330. Specifically, the expanded data memory controller 315 provides refresh data to the VDP 330 in accordance with an instruction from the CPU 311. The expanded data memory controller 315 may generate refresh character data and provide it to the VDP 330 instead of providing the refresh character data prepared in advance to the VDP 330 as described above.

  Here, the sprite data is image data for displaying a sprite in 8 bits (256 colors) in a display range of 64 dots × 64 dots, for example. On the other hand, the refresh character data is also image data for displaying the refresh character with 8 bits (256 colors) in a display range of 64 dots × 64 dots, for example. That is, in the present embodiment, the refresh character data and the sprite data have the same data structure although the display contents thereof are different, so that the display range of one sprite is the same as the display range of one refresh character. Yes. Then, the decompressed data memory controller 315 provides sprite data to the VDP 330 via a bus line connecting itself and the VDP 330, for example, a 32-bit wide bus line.

  The character RAM controllers 314 and 317 then perform a refresh operation on the character RAMs 321 and 322, respectively, when the VDP 330 reads the refresh character data from the expanded data memory controller 315 in accordance with an instruction from the CPU 311. ing.

  Furthermore, in this embodiment, the VDP 330 stores a refresh character based on the read refresh character data outside the visible area of the line buffer 336 in accordance with an instruction from the CPU 311. Here, in the present embodiment, a colored image can be employed as the refresh character.

  The visible region in the frame here refers to a region where the arranged sprite is displayed on the display device 16 by the VDP 330. On the other hand, the outside of the visible region refers to a region excluding the visible region in the frame, for example, a non-visible region where the arranged sprite is not displayed on the display device 16 by the VDP 330. That is, the frame includes a visible region and a non-visible region.

  Here, when the character RAM controllers 314 and 317 cause the character RAMs 321 and 322 to perform a refresh operation, the CPU 311 designates an address (eg, “0C00 0000”) that designates a refresh character area in the character RAMs 321 and 322, for example. The address “0C00 0000” represents the head address of the refresh character area in the character RAMs 321 and 322 as shown in FIG.

  In this embodiment, refresh character data is not actually stored in the refresh character area, and the CPU 311 instructs the character RAM controllers 314 and 317 to execute the refresh operation. An instruction to read refresh character data from the refresh character area is given.

  The character RAM controllers 314 and 317 operate according to the set value of a refresh character number setting unit (not shown) under the control of the development data memory controller 315. In this refresh character number setting section, the number of refresh characters to be displayed is set by the CPU 311 in accordance with the time required for the refresh operation for the character RAMs 321 and 322. The refresh character number setting unit corresponds to, for example, a register 315a provided in the expanded data memory controller 315.

  That is, the CPU 311 presets the number of refresh characters (set value) to be displayed according to the time required for refreshing the character RAMs 321 and 322 in the refresh character number setting unit (register 315a), for example, at the time of initial setting. I will leave it. The number of refresh characters is a value set according to the refresh range (capacity to be refreshed) in the character RAMs 321 and 322. The number of refresh characters is also the number of refresh character data that the VDP 330 reads from the memory interface control circuit 324 when executing the refresh operation on the character RAMs 321 and 322.

  Here, as a specific example of the capacity refreshed by one refresh character, for example, it corresponds to the data size of the refresh character data used for displaying the refresh character which is a display range of 64 dots × 64 dots × 8 bits (256 colors). is doing. That is, when it is desired to refresh a wide range (large capacity) in the character RAMs 321 and 322, the number of refresh characters to be displayed increases.

  The register 315a of the expanded data memory controller 315 has a register name (REFOFT, REFNOF, REFNCH). In these register names, desired setting values are written by the CPU 311 as the operation instruction processor. These register names are set to values based on the specifications of the character RAM connected to the memory interface control circuit 324. The register REFOFT is a register for setting a refresh execution period. On the other hand, the register name REFNOF is a register for setting the number of refreshes that must be executed within the refresh execution period.

  The register name REFNCH is a register for setting the number of refresh times by the refresh character, and sets the number of times the refresh character data is read corresponding to one refresh instruction. The number of times the refresh character data is read here is set according to the specifications of the connected character RAMs 321 and 322.

  The memory interface control circuit 324 manages the number of refreshes and a refresh monitoring counter (corresponding to the time during which refresh is executed). It is determined whether or not the refresh unit has performed the refresh operation by the number of times set by the register name REFNOF within the time set by the register name REFOFT. In the present embodiment, the CPU 311 instructs the refresh unit to repeat the refresh operation four times, for example, every 1024 times every 16 ms.

  In other words, in this embodiment, the refresh operation is executed 4096 times for 64 ms, for example, based on the set value of the register name REFNOF and the set value of the register name REFOFT. Further, in the present embodiment, if the refresh operation for the character RAMs 321 and 322 is not executed for the number of times corresponding to the set values of the register name REFNOF and the register name REFOFT, based on the values set in the register name RENOF and the register name REFOFT. The central refresh is started.

  That is, in the present embodiment, a refresh condition setting unit for setting refresh conditions such as the set value of the register name REFNOF and the set value of the register name REFOFT is prepared, and a refresh monitoring unit (refresh monitoring unit) (not shown) When it is detected that the set value (refresh condition) set in the refresh condition setting unit is not satisfied, an instruction to forcibly start the refresh operation so as to satisfy the refresh condition is issued.

C6. Character RAM switching configuration:
The first character RAM 321 and the second character RAM 322 each have a development state (storage state) in which sprite data is temporarily stored and a read state in which stored sprite data is read out under the control of the development data memory controller 315. It becomes the structure switched alternately so that it may become reverse.

  More specifically, the expanded data memory controller 315 is controlled to execute reading from the second character RAM 322 during a period during which the expanded data memory controller 315 is expanded to the first character RAM 321 (hereinafter referred to as “first expanded period”). To do. On the other hand, the expanded data memory controller 315 controls to read out data from the first character RAM 321 during the period of expansion to the second character RAM 322 (hereinafter referred to as “second expansion period”). In the present embodiment, the development data memory controller 315 repeatedly and alternately repeats the first development period and the second development period in response to a vertical synchronization signal (so-called V blank signal) that is an external signal output from the VDP 330. Thus, the switching operation of the first character RAM 321 and the second character RAM 322 is controlled.

C7. Management of storage area of both character RAMs:
Here, in the present embodiment, the storage areas of the first character RAM 321 and the second character RAM 322 are managed by the same address. That is, the storage area of the first character RAM 321 and the storage area of the second character RAM 322 have the same storage capacity, and the same address is assigned to each storage area.

  In the first character RAM 321 and the second character RAM 322, the same sprite data is alternately developed in the storage areas managed by the same address. In this way, even if the first character RAM 321 and the second character RAM 322 are switched during reading, the read sprite data can be the same.

C8. Multiple common areas:
Here, in the present embodiment, the first character RAM 321 and the second character RAM 322 each include sprite data necessary for displaying a combination of scenes (videos) used for a variable display pattern as an example of a combined video group. A plurality of common areas (a plurality of common areas) that can be temporarily stored are defined.

  The plurality of common areas are areas partitioned by the CPU 311 based on the contents of the expansion table stored in the control ROM 325, respectively. From the plurality of common areas, sprite data necessary for each combination of scenes is independently read out under the control of the development data memory controller 315.

C9. Static load:
As an example of the variable display pattern, the CPU 311 as a data expansion processor temporarily stores sprite data necessary for each combination of scenes included in the variable display pattern in any of a plurality of predetermined common areas. To remember.

  As described above, in the present embodiment, sprite data necessary for scene display related to a combination of scenes included in the variable display pattern is stored in any one of a plurality of common areas determined in advance based on the contents of the development table. It is designed to be deployed separately. That is, in this embodiment, according to the above expansion table, each sprite data necessary for scene display has a predetermined expansion destination in a plurality of common areas, and is expanded in a different common area among the plurality of common areas. It has become so. In the present embodiment, such fixed development of sprite data in any of a plurality of common areas is referred to as “static load”. That is, the static load indicates that sprite data is temporarily stored in a predetermined common area among a plurality of common areas.

  Here, sprite data necessary for displaying a plurality of scenes at the same time may be developed in one shared area. However, in this embodiment, sprite data necessary for displaying a plurality of scenes is simultaneously displayed in one shared area. The configuration is such that the sprite data necessary for displaying one scene is expanded without being expanded. Here, the sprite data necessary for the scene display developed in the plurality of common areas at the same time is data used to display one variation display pattern.

  In the present embodiment, sprite data necessary for scene display related to a combination of scenes in which the display order is continuous among the scenes included in one variable display pattern is set to a different common area determined in advance among the plurality of common areas. To remember.

C10. Resident area:
When the memory interface control circuit 324 reads sprite data necessary for scene display from the character RAMs 321 and 322, the memory interface control circuit 324 overwrites the sprite data necessary for scene display read from the character RAMs 321 and 322, respectively. However, in this embodiment, when displaying a plurality of variable display patterns, sprite data necessary for scene display that is frequently used to display each scene is stored in a part of the storage area of the character RAMs 321 and 322. It shall be resident. In this embodiment, the CPU 311 develops, for example, sprite data necessary for scene display frequently used in common by forming a resident area (resident area) as a part of a plurality of common areas in the character RAMs 321 and 322. Shall.

  In this way, if the character RAMs 321 and 322 are provided with resident areas and the sprite data necessary for scene display is constantly developed, it is not necessary to read from the character ROM 340 frequently. The sprite data necessary for the scene display developed in the resident area includes, for example, sprite data used for displaying a symbol that is always displayed during the symbol variation display. It should be noted that the deployment time may be expanded immediately after the power is turned on. Here, the expansion table includes expansion information used for expanding the sprite data necessary for the scene display into any of a plurality of common areas including the resident area.

C11. Data size of each common area:
Here, in each of the plurality of common areas, when a certain variable display pattern of a plurality of variable display patterns having different display modes is displayed, and when a different variable display pattern is displayed. The sprite data necessary for displaying a plurality of different scenes is stored.

  Thus, in the present embodiment, the CPU 311 as the data expansion processor controls the expansion data memory controller 315 via the CPU interface 316, thereby displaying a plurality of scene displays that can be stored in each common area among the plurality of common areas. A plurality of common areas are partitioned in advance on the basis of the data size of the sprite data necessary for the scene display having the maximum data size among the sprite data necessary for the above. The data size here represents, for example, the data size of sprite data necessary for displaying a sprite as a material necessary for displaying one scene.

  First, since the sprite data that can be stored in each of the plurality of common areas is determined in advance, it may not be partitioned in consideration of the data size of the sprite data that is not expanded in the common area. For this reason, it is not necessary to form an extra data size in the plurality of common areas assuming that sprite data having a large data size may be developed in the future. A partition may be formed based on sprite data having the largest data size. Therefore, according to the present embodiment, the data size of each common area among the plurality of common areas to be partitioned in the character RAMs 321 and 322 is suppressed to the minimum according to the sprite data that can be developed in each common area. Therefore, the character RAMs 321 and 322 can be used efficiently.

D. Example of VDP configuration:
FIG. 4 is a block diagram showing an example of the electrical configuration of the VDP 330. The VDP 330 includes a CPU interface 383 (abbreviated as “CPU I / F” in the figure), a ROM interface 333 (abbreviated as “ROM I / F” in the figure), a bus 382, a VDP controller 331, a line buffer 336, and a color palette register 332c. , A sprite attribute register 332s, a background (abbreviated as “BG” in the figure) attribute register 332b, a built-in RAM 335, and a DMA controller 384. The built-in RAM 335 may be provided outside the VDP 330.

  In the control ROM 325, the above expansion table is managed. This expansion table includes expansion information regarding which common area of the plurality of common areas the sprite data necessary for scene display should be expanded in the character RAMs 321 and 322, and the scheduler (display information) in addition to the expansion information. ) Is included. The scheduler here will be described later, such as the start address of the sprite to be displayed by the VDP 330, the number of sheets to be displayed (vertical and horizontal numbers), the identifier of the sprite (character number, etc.), and the priority order when they are superimposed. It includes display information that stores display data in display order. Note that the control ROM 325 may have a form in which development information is included and stored in the scheduler, or a form in which the scheduler and the development information exist in parallel.

  Further, the CPU 311 refers to the expansion table of the control ROM 325, and displays the scene display related to the combination of scenes necessary for the display operation of the variable display pattern in any common area among the plurality of common areas in the character RAMs 321 and 322. The expansion information regarding whether necessary sprite data is stored is acquired. In other words, the CPU 311 specifies a common area among a plurality of common areas where the sprite data necessary for necessary scene display is developed based on the development information.

  Next, the CPU 311 further refers to the contents of the expansion table, grasps the sprite used for displaying the scene for each type of scene, and identifies a common area group among a plurality of corresponding common areas. The specification here means to grasp an address assigned to a specific common area where sprite data necessary for displaying each scene in the character RAMs 321 and 322 is developed.

  When the CPU 311 grasps an address related to sprite data necessary for displaying a scene necessary for displaying the variable display pattern, the CPU 311 first designates drawing parameters such as an address at which a sprite to be displayed is arranged under the control of the CPU 311. The VDP controller 331 acquires sprite data via the memory interface control circuit 324 under the control of the CPU 311.

  The color palette register 332c, the sprite attribute register 332s, and the BG attribute register 332b shown in FIG. 4 are registers that the VDP controller 331 refers to when controlling the image display operation by the VDP controller 331, respectively. That is, the VDP controller 331 controls the effect display on the display device 16 via the line buffer 336 while referring to the color palette register 332c, the sprite attribute register 332s, and the BG attribute register 332b based on an instruction from the CPU 311. ing.

  Here, the CPU 311 writes the color palette data included in the drawing parameters generated as described above into the color palette register 332c, writes the sprite attribute data into the sprite attribute register 332s, and further converts the background attribute data into the background attribute. Write to register 332b.

  The color palette register 332c is a register for storing in advance color palette data for 256 palettes corresponding to each palette number represented by, for example, 0 to 255. One pallet is composed of, for example, 16 colors. That is, the color palette register 332c provides color palette data corresponding to the designated palette number when a palette number (for example, 0 to 255) is designated when the sprite is set.

  The sprite attribute register 332s stores sprite attribute data related to sprite attributes such as sprite data. The background (BG) attribute register 332b stores background attribute data regarding the attributes of the background image.

  The built-in RAM 335 is a rewritable volatile memory, for example, an SDRAM (Synchronous Dynamic Random Access Memory). Here, the writing of data from the control ROM 325 to the built-in RAM 335 is executed under the control of the CPU 311, for example, but may instead be executed under the control of the DMA controller 384.

  The line buffer 336 has a function of storing the display data generated by the VDP controller 331 in units of scanning lines (lines) of an image to be displayed, and outputs the stored display data in units of scanning lines. It has a function. When outputting the display data, the VDP controller 331 also outputs a synchronization signal SYNC synchronized with the display data. Since the cycle for displaying frames on the display device 16 is fixed, the upper limit value of the time required for outputting display data in units of scanning lines is limited. For this reason, the upper limit value of the number of pixels that can be drawn for each scanning line is determined in the VDP 330, and when the “total number of pixels” at the time of drawing exceeds the upper limit value, the scanning line is thereafter The drawing is interrupted and the display data is output. Hereinafter, this state is referred to as sprite over. In the present embodiment, the number of pixels in the horizontal direction of the display device 16 is 640 dots, whereas the upper limit value causing sprite over is 7000 dots.

E. Display control processing:
FIG. 5 is a flowchart of the display control process. In this process, the CPU 311 outputs a drawing command or the like to the VDP 330 to generate display data. In addition, enlargement / reduction and OSD display control may be performed on the scaler 390. This process is executed as an interrupt process with a period of 16 msec.

  When this process is started, the CPU 311 permits multiple interrupts as preparation for executing the process (step S10), and performs a noise cancellation / determination process (step S12). Then, the terminal level of the interrupt terminal is confirmed (step S14). If the terminal level is abnormal, it is determined that the display control process has been started based on an abnormal trigger due to the influence of noise or the like, and the process is performed as it is. Exit.

  When the terminal level is normal, a drawing command or the like is output to the VDP 330 by the following procedure to generate display data. Here, for the sake of convenience of explanation, the entire display control process is described. However, the following part may be configured as a process different from steps S10 to S14 and executed as an interrupt process with a cycle of 32 msec.

  Next, the CPU 311 initializes the VDP 330 (step S16). This processing includes initialization of values of various registers used by the VDP 330 to generate display data, but initialization of sprite registers and VDP registers that should hold drawing commands from the CPU 311 and the like. I can't. Initialization of the sprite register or the like is performed separately.

  The CPU 311 further initializes the sprite register of the VDP 330 (step S18). Also, a condition setting command is set in the VDP register (step S20). This is a process of writing various settings used when generating display data to the VDP register. When the initialization and the VDP register setting are completed, the CPU 311 analyzes the contents of the display command received from the sub control board 35 (step S22) and specifies screen data to be displayed on the LCD 16. Based on the screen data, an image drawing command is output to the VDP 330 (step S100).

  After outputting the drawing command, the CPU 311 optimizes the sprite and ends the display control process (step S200). This is a process of omitting from the drawing command for sprites that are entirely out of the display area defined in the VDP 330 in the following procedure. At the time of drawing command output, the CPU 311 writes all sprites specified by the screen data in the sprite register of the VDP 330 without determining whether or not the sprite is included in the display area. Each sprite is provided with a flag for switching display / non-display in addition to designating the drawing position. At this stage, all the flags are set to “display”. In the sprite optimization, the CPU 311 determines whether or not the entire sprite register is out of the display area based on the size and position of the written sprite register. The CPU 311 switches the above-mentioned flag and sets it to “non-display” for the sprites that are entirely off.

  As described above, the sprite optimization is a process for avoiding a wasteful process of drawing sprites that are entirely out of the display area. Although it is possible to take a method of determining whether each sprite is out of the display area when outputting the drawing command, in this embodiment, for the output of the drawing command and sprite optimization. By dividing, it is possible to consolidate the same type of processing and improve the processing efficiency. However, since sprite optimization is a process for improving the processing efficiency of the VDP 330, it can be omitted.

F. Drawing process:
FIG. 6 is a flowchart of the drawing process. This process is executed internally by the VDP 330 in response to the display control process (FIG. 5). First, the VDP 330 reads a drawing command output from the CPU 311 (step S302). In this drawing command, designation of display / non-display, display position, etc. is made for many sprites. If the sprite selected in a prescribed order from these is the display target (steps S304 and S306), the VDP 330 draws the sprite (step S308). If it is not a display target (step S306), sprite drawing is skipped.

  The VDP 330 ends the drawing process when the process for all sprites is completed (step S310) or when a sprite over occurs (step S312). If a sprite over occurs, even if there remains a sprite designated as a display target, the VDP 330 interrupts the drawing process, so that the frame is displayed with some sprites missing. If all the sprite processing has not been completed (step S310), and if sprite over has not occurred (step S312), the VDP 330 proceeds to the next sprite processing (step S304).

  FIG. 7 is an explanatory diagram showing a sprite over determination method. As shown in the upper part, the case where the screen is drawn by arranging sprites A to C having 100 dots in the horizontal direction on a display device having 640 dots in the horizontal direction is illustrated. Consider the case of drawing the scanning line L shown in the figure. When drawing the background, as indicated by the scanning line L1, the line buffer is drawn for 640 dots, and the gradation value corresponding to the background is stored. Next, when drawing the sprite A, as shown by the scanning line L2, drawing for 100 dots is performed in the line buffer. For the pixels overlapping with the scanning line L1, the result of combining the gradation value of the background and the gradation value of the sprite A is stored in accordance with the transparency setting for the sprite A. When the sprite A is set to be opaque, the gradation value of the sprite A is stored in these pixels. When the sprite B is drawn, as shown by the scanning line L3, 100 dots are drawn. Further, when the sprite C is drawn, as shown by the scanning line L4, 100 dots are drawn.

  As a result, a total of 940 dots are drawn for the scanning line shown. In this way, the total number of pixels drawn on each scanning line varies depending on the size, number, and position of the sprite. When the total number of pixels thus obtained exceeds the upper limit value that can be drawn by the VDP 330, sprite over occurs. If sprite over occurs when the sprite B is drawn (scanning line L3), the display data of the scanning line L is output without drawing the sprite C. As a result, the sprite C is displayed in a state where the portion of the scanning line L is missing.

  FIG. 8 is an explanatory diagram showing the effect of sprite over. The case where the screen comprised by three layers LA1-LA3 as shown in the figure is displayed is illustrated. A screen PIC with all layers superimposed on the foreground is shown. On the backmost layer LA1, an effect display representing the sea and a start-up memory are displayed. The start memory display is shown in the lower part of the figure. In this example, the number of game balls won in the left and right start winning openings is represented by the number of heart marks and spade marks, respectively.

  In the backmost layer, a rectangular sprite shown in the figure is displayed in front of the start memory. The height MH of the sprite is the same as the height of the start memory. In this embodiment, the rectangular sprite is a transparent rectangle. However, the rectangular sprite may be a sprite that displays the same symbol as the start-up memory. That is, whether or not these rectangles are displayed does not affect the display contents of the start memory. Such a sprite is called a mask sprite in this embodiment. Since the VDP 330 performs the drawing process for the mask sprite as well as other sprites, sprite over may occur depending on the number of areas in which the mask sprite exists. In the example of FIG. 8, it is assumed that enough mask sprites are prepared to cause sprite over. Assuming that the horizontal width of the display device is 640 dots and the upper limit of the total number of pixels that can be drawn by the VDP 330 is 7000 dots, if 10 mask sprites are prepared, the total number of pixels including the start memory is 7000 dots. Therefore, sprite over occurs.

  In the illustrated example, when the VDP 330 starts drawing, no sprite over occurs because there is no mask sprite in the portion above the start-up memory. Therefore, the fish sprite in the layer LA3 is also drawn normally. On the other hand, sprite over occurs in the starting memory portion as described above. For this reason, the fish sprite in the layer LA3 is not drawn. That is, the fish sprite is drawn in a state where only the area MSK portion corresponding to the mask sprite is missing. As a result, when all the layers LA1 to LA3 are overlaid, a display as if the start memory is drawn on the foreground can be easily realized as shown in the image PIC.

G. Drawing command output processing:
FIG. 9 is a flowchart of the drawing command output process. This process corresponds to step S100 of the display control process (FIG. 5), in which the CPU 311 determines whether or not drawing of the mask sprite is necessary and outputs a drawing command to the VDP 330. Here, the case where the screen is composed of a plurality of layers as illustrated in FIG. 8 is illustrated.

  First, the CPU 311 outputs a drawing command for the background layer (step S102). Next, when the mask is specified by the display command from the sub control board 35, that is, when it is specified that the mask sprite should be drawn (step S104), the CPU 311 responds to the display command. The portion where the mask sprite is to be drawn, the height MH of the mask sprite, and the number of mask sprites are set (step S106), and a drawing command for the mask sprite (hereinafter referred to as “mask command”) is output accordingly (step S106). Step S108). When the mask sprite is unnecessary (step S104), the above-described processing (steps S106 and S108) is skipped.

  Whether or not the mask sprite is necessary may be directly specified by a display command output from the sub-control board 35, or specified based on a screen configuration specified based on the display command (the development table described in FIG. 3). You may do it. In the latter case, it may be specified that only the mask sprite is arranged in the screen configuration, and the CPU 311 may determine the position or the like, or all the positions, shapes, and numbers of the mask sprite may be specified. Good. Further, as a simple form, a method may be used in which the development table is represented in a form in which a sufficient number of mask sprites are arranged so as to cause sprite over. In this aspect, the CPU 311 can omit the process of step S106.

  As the number of mask sprites sufficient to cause sprite over, a value obtained by dividing the upper limit value that can be drawn by the VDP 330 by the number of dots in the scanning line direction of the mask sprites may be used. The number of mask sprites may be set smaller than this value. In this way, whether or not sprite over occurs depends on the size and number of sprites drawn other than the mask sprite, and the interest can be enhanced depending on the application site.

  When drawing of the mask sprite is completed, the CPU 311 shifts to drawing command output for the next layer (step S110). The CPU 311 repeatedly executes this processing (step S110) until drawing command output for all layers is completed (step S112), and ends the drawing command output processing.

  In the example of FIG. 9, an example in which mask sprites are output in the background layer is shown. The mask sprite can be output at various timings. For example, in a layer arranged immediately before the background layer, a mask sprite drawing command may be output first, and then other sprite drawing commands may be output.

  According to the gaming machine of the embodiment described above, a part of the sprite can be easily masked by using the mask sprite. By using the mask, as shown in FIG. 8, it is possible to avoid that another sprite overlaps the front surface of a specific sprite. Therefore, in consideration of the overlap state on the screen, the sprite is drawn before and after, or the sprite layout and drawing order are taken into consideration so that sprite over does not occur before drawing the sprite to be displayed. It becomes possible to reduce the load. In addition, when the screen is composed of a plurality of layers as shown in FIG. 8, it is not necessary to draw the start-up memory in the foreground layer, so it is necessary to set the foreground layer to “opaque”. Disappears. As a result, for example, it is possible to realize an effect display that makes the user feel the depth by setting the foremost layer to “translucent” and drawing various sprites.

  In the above-described embodiment, the case where a transparent rectangle is used as a mask sprite has been illustrated. As the mask sprite, various sprites that are substantially invisible, such as a sprite showing the same display content as the background, can be used in addition to the transparent sprite. For example, as described above, an invisible “refresh character” used to refresh the first character RAM 321 and the second character RAM 322 may be used as a mask sprite. By doing so, there is an advantage that refresh and mask can be performed in parallel.

H1. Modification (1):
In the embodiment (FIGS. 8 and 9), the case where a mask sprite having a constant height is used is illustrated. In this embodiment, the height of the mask sprite does not have to be fixed, and mask sprites having different heights may be mixed. Such an example is shown below as a modified example (1).

  FIG. 10 is an explanatory view showing a modification (1) of the mask. Consider a case in which sprites A to C are drawn on the screen as shown in FIG. In the modification, a mask sprite having a height of MH2 is drawn on the front surface of the sprites A and C, and a mask sprite having a height of MH1 (MH1 <MH2) is drawn on the front surface. The region LA1 in which only the mask sprite having the height MH2 is drawn and the region LA2 in which both the mask sprites having the heights MH1 and MH2 are drawn are adjacent to each other. Similarly, an area LA3 in which only a mask sprite having a height MH2 is drawn and an area LA4 in which both mask sprites having a height MH1 and MH2 are drawn are adjacent to each other in front of the sprites A to C. Will be.

  FIG. 10B schematically shows the total number of pixels drawn by the VDP 330 in each of the regions LA1 to LA4 described above. The hatched portion represents the total number of pixels corresponding to the drawing of the mask sprite. In the areas LA1 and LA3 in which only the mask sprite having the height MH2 is drawn, the total number of pixels is smaller than in the areas LA2 and LA4 in which both the mask sprites having the height MH1 and MH2 are drawn.

  In this state, the state in which the number of pixels by drawing of the sprites A to C is added is shown. It is assumed that sprite over occurs when the “upper limit value” in the figure is exceeded. In the areas LA1 and LA2, sprite over does not occur even if sprites A and C are drawn. When the sprites A to C are drawn, sprite over does not occur in the area LA3, but sprite over occurs in the area LA4. As a result, the sprite C is displayed in a state where a portion corresponding to the area LA4 is missing.

  When mask sprites having different heights are mixed, sprite over may or may not occur depending on the height and number of mask sprites and the number and size of sprites drawn on the mask portion. Therefore, the mask is irregularly generated during the effect display, and it is possible to realize an interesting effect display. In the example of FIG. 10, the mask height is set in two ways, but the height may be changed in multiple steps. Also, the same effect as described above can be obtained by shifting the positions of the mask sprites in the vertical direction.

H2. Modification (2):
In the embodiment, after the drawing command for the background layer is output, all mask commands are output, and then the drawing command for the front layer is output. In the present embodiment, it is not always necessary to output all mask commands in a series, and other drawing commands may be sandwiched in the middle of outputting a plurality of mask commands. Such an example is shown as a modified example (2).

  FIG. 11 is a flowchart of the drawing command output process of the modification (2). This is an alternative process to the embodiment (FIG. 9). First, the CPU 311 outputs a background layer drawing command (step S122).

  When the mask is designated (step S124), the CPU 311 sets the mask location, the mask height MH, the number of mask sprites, and each layer switching position (step S128). In the modified example, for example, when a plurality of mask commands are output, a mode in which a part of the mask commands is output in the background layer, and the remaining mask commands are output by switching the layers can be employed. The layer switching position can be set, for example, in the form of the number of mask commands to be output before switching layers. When no mask is specified (step S124), this process is skipped.

  The CPU 311 sequentially outputs a drawing command or a mask command according to the above setting. First, if it is determined from the number of mask commands output previously that the layer switching position is applicable (step S130), a layer drawing command is output (step S134). Otherwise, a mask command is output. (Step S132). The CPU 311 repeatedly executes the above processing until it ends for all layers and all mask commands (step S136).

  FIG. 12 is an explanatory view showing the effect of the modification (2). Consider a case where sprites A to C are drawn on the screen as shown in FIG. A mask sprite MS is drawn in the screen. The sprites A to C are drawn on a layer in front of the background layer.

  FIG. 12B shows the total number of pixels drawn in the mask portion. The hatched portion is the number of pixels by drawing the mask sprite. As shown in the figure, the number of pixels increases as the number of mask sprites increases. The figure shows a state in which layer switching is performed with three mask sprite numbers N1, N2, and N3. When layer switching is performed with the number of mask sprites N1, since the number of pixels drawn by the mask sprite is relatively small, sprite over does not occur even if sprites A to C are drawn. When layer switching is performed at N2, sprite over occurs during sprite B drawing. Accordingly, the sprite A is displayed completely, the sprite B is displayed with a part of the mask MS missing, and the sprite C is displayed with the mask MS part completely removed. When layer switching is performed at N3, sprite over occurs during sprite A drawing. Therefore, the sprite A is displayed with a part of the mask MS missing, and the sprites B and C are displayed with the mask MS part completely missing.

  According to the modification (2), sprite over may or may not occur depending on the setting of the layer switching position. Therefore, the mask is irregularly generated during the effect display, and it is possible to realize an interesting effect display.

  As mentioned above, although the various Example of this invention was described, it cannot be overemphasized that this invention is not limited to these Examples, and can take a various structure in the range which does not deviate from the meaning. The above-described embodiments and modifications can be combined as appropriate. In the embodiment and the modification, the case where the LCD 16 is used as a display device has been illustrated, but the present invention is also applicable to the case where other types of display devices are used.

It is a front view of the pachinko machine 1 as an example. 2 is a block diagram showing a control hardware configuration of the pachinko machine 1. FIG. 3 is a block diagram showing a circuit configuration of a symbol control board 30. FIG. It is a block diagram which shows the electrical structural example of VDP330. It is a flowchart of a display control process. It is a flowchart of a drawing process. It is explanatory drawing which shows the judgment method of a sprite over. It is explanatory drawing which shows the effect by sprite over. It is a flowchart of a drawing command output process. It is explanatory drawing which shows the modification (1) of a mask. It is a flowchart of the drawing command output process of the modification (2). It is explanatory drawing which shows the effect of a modification (2). It is explanatory drawing which shows the example of a screen display in a prior art.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Pachinko machine 3 ... Main control board 4 ... Game board 4a ... Display part 4b ... Operation switch 6 ... Game area 8 ... Launching handle 8 ... Handle 9 ... Starting prize opening 10 ... Grand prize opening 12 ... Panel decoration lamp 15a ... Prize Detector 16 ... Display device (LCD)
DESCRIPTION OF SYMBOLS 18 ... Grand prize opening solenoid 20 ... Dispensing motor 21 ... Prize ball dispensing device 22 ... Dispensing ball detector 24 ... Motor drive sensor 25 ... Dispensing control board 29 ... Speaker 30 ... Symbol decoration board 31 ... Frame decoration lamp 32, 34 ... Lamp Relay board 35 ... Sub-control board 41 ... Special symbol display device 47 ... Launch control board 48 ... Touch detector 49 ... Launch motor 311 ... CPU
312 ... Compressed data memory controller 312a, 327a, 328a, 329a, 315a ... Register 314 ... First character RAM controller 315 ... Expanded data memory controller 317 ... Second character RAM controller 320 ... VDP interface 321 ... First character RAM
322 ... Second character RAM
324 ... Memory interface control circuit 325 ... Control ROM
327: Moving image data expansion controller 328, 329: Sprite data expansion controller 330: VDP
331 ... VDP controller 332c ... Color palette register 332s ... Sprite attribute register 332b ... Background attribute register 333 ... ROM interface 335 ... Built-in RAM
336 ... Line buffer 340 ... Character ROM
382 ... Bus 383 ... CPU interface 384 ... DMA controller 390 ... Scaler 397 ... Frame buffer

Claims (7)

A gaming machine that performs a predetermined effect display during a game,
A display device provided on the game board surface, in which display pixels are two-dimensionally arranged;
Production control means for controlling production display according to the game situation by generating display data for driving the display device and outputting it to the display device;
Have
The production control means includes
A drawing control unit that outputs a drawing command that defines a configuration of a screen to be displayed on the display device according to the state of the game;
A display data generating unit that generates the display data defining the display state of each pixel of the display device based on the drawing command from the drawing control unit, with the row or column of the array as a generation unit;
With
The display data generation unit has an upper limit on the total number of pixels that can be drawn for each generation unit when the display data is generated,
When the drawing control unit outputs a mask command for drawing a predetermined invisible figure as a mask figure for a portion to be masked in the screen, the number of mask commands to be output is generated as the display data generation. By setting the number of pixels to be drawn to the number that can exceed the upper limit value alone or in combination with the drawing command, sprite over is forcibly generated and the background of the portion to be masked in the screen A gaming machine characterized in that an image can be seen through . A gaming machine according to claim 1,
The gaming machine, wherein the drawing control unit outputs the mask command at a timing when the display data generation unit draws at least one of the mask figures before the drawing command. A gaming machine according to claim 1 or 2,
The display data generation unit preferentially generates display data from the back side layer based on a drawing command defined by dividing into a plurality of layers superimposed from the back to the front,
The gaming machine according to claim 1, wherein the drawing control unit outputs a drawing command for a figure to be displayed in the same area as the mask command or a layer on the back side in an area for outputting the mask figure. A gaming machine according to any one of claims 1 to 3,
The gaming machine according to claim 1, wherein the mask figure is a shape in which a plurality of rows or columns as the generation unit are arranged adjacent to each other. A gaming machine according to any one of claims 1 to 4,
The production control means further includes:
A character memory that stores sprite data representing a predetermined sprite displayed on the screen in units of pixels of the display device, using a memory element that requires a refresh operation to hold the memory;
A control device that controls reading of the sprite from the character memory in response to a request from the display data generation unit, and when a predetermined refresh character is requested, a predetermined invisible figure is used as the sprite. A character memory control device that delivers the display data generation unit and executes the refresh operation;
Have
The gaming machine, wherein the drawing control unit outputs a drawing command designating drawing of the refresh character as the mask command. A gaming machine according to claim 1,
The gaming machine performs a predetermined winning action when a game ball enters a predetermined starting winning opening provided on the surface of the game board,
At least a part of the screen includes a start memory display that displays the number of game balls that have not been subjected to the winning action after entering the starting winning opening,
The drawing control unit outputs the drawing command and the mask command so that the mask graphic is drawn on the start storage display until the upper limit value is exceeded after the start storage display is drawn. A gaming machine characterized by A gaming machine that performs a predetermined effect display during a game,
A display device provided on the game board surface, in which display pixels are two-dimensionally arranged;
Production control means for controlling production display according to the game situation by generating display data for driving the display device and outputting it to the display device;
Have
The production control means includes
A drawing control unit that outputs a drawing command that defines a configuration of a screen to be displayed on the display device according to the state of the game;
A display data generating unit that generates the display data defining the display state of each pixel of the display device based on the drawing command from the drawing control unit, with the row or column of the array as a generation unit;
With
The display data generation unit generates the display data preferentially from the back side layer based on a drawing command defined by being divided into a plurality of layers superimposed from the back to the front. There is an upper limit on the total number of pixels that can be drawn,
When the drawing control unit outputs a mask command for drawing a predetermined invisible figure as a mask figure for a portion to be masked in the screen, the number of mask commands to be output is generated as the display data generation. By setting the number of pixels to be drawn to a number that can exceed the upper limit value, a sprite over is forcibly generated so that a background image in a portion to be masked in the screen can be seen through, and the mask A gaming machine, wherein in a region for outputting a graphic, the drawing command for a graphic to be displayed is output on the same layer as the mask command or on a back side layer.