AU2008203482B2 - Gaming machine transitions - Google Patents

Abstract

A graphics system for changing images on a gaming machine display, having a transition library of transition types, a graphics engine and a control means. The graphics engine applies a selected transition type from the transition library to at least one of at least two images for determining the way in which a substitution of one of the images by the other of the images occurs and initialises transition data for effecting an incremental substitution of the one image by the other image. The control means modifies the transition data such that, when the selected transition type is being effected, an incremental substitution of at least a part of the one image by the other image occurs serially until the one image has been substituted by the other image on the gaming machine display.

Description

P/00101i1 Regulaton 3.2 AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Invention Title: Gaming machine transitions The following statement is a full description of this invention, including the best method of performing it known to us: I laiing Machine Transitions Field of Invention This invention relates to gaming machines. More particularly, the invention s relates to a system and method for changing images on a gaming machine display. Background of the Invention When replacing one on-screen image with another in a gaming machine, the 10 options available to perform this action in an interesting or aesthetically pleasing manner are limited. In fact, other than an instantaneous change, the only way is to use some form of pre-generated animation. This method, apart from consuming a large amount of EPROM space, is unwieldy and cumbersome given that the starting and end images must be known before run-time. 15 In filmmaking, when going from one scene to another, filmmakers have used a number of techniques. These techniques range from fading from a scene to black, and then fading from black into the next scene. Other options are fading directly from one scene to another, shrinking a scene to reveal another "behind it", or sliding one scene off the screen to the left whilst simultaneously sliding another onto the screen from the 20 right. All these techniques are generated post-filming and are fixed. Summary of the Invention According to an aspect of the invention there is provided a graphics system for 25 displaying images on a gaming machine display, the system comprising: a transition library having transition types, each type corresponding to related display control data; a graphics engine configured to select a transition type from the transition library for substituting a first of the images by a second of the images, initialise the 30 corresponding display control data for effecting an incremental substitution on a part of the first image by a part of the second image with the display control data, selectively attach display control data corresponding to the selected transition type to the first of the images, and determine if display control data is present at the first of the images; and 35 a controller in response to display control data being present, configured to update the attached display control data during the incremental substitution, and effects the incremental substitution on another part of the first image serially until the first 35449951 (GHMaUeU)P557]LAU. 25/07112 2 innge has been iihftitited by the second image on the gaming machine uing tho updated display control data. In one embodiment the second of the images is initially placed behind said first of the images. 5 In one embodiment, the first image is incrementally removed by the transition type to reveal or expose at least a part of the second image until the first image has been entirely removed to reveal the second image. In one embodiment, the selected transition type is drawn using any one or more of pixel operations, scaling operations, microclipping operations or OpenGL operations, 10 In one embodiment, at least one of the first and second images is an animation of a plurality of transitional images, The second image may be an animation of a plurality of transitional images. Brief Description of the Drawings 15 An example of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a block diagram of the graphics system. Figure 2 is a process flow diagram of a 3D transition using 3D callback. 20 Figure 3 is a process flow diagram of adding a transition image to the Display Manager. Figure 4 is a process flow diagram of a 3D transition not using 3D callback. Figure 5 is a process flow diagram of a 2D transition. Figure 6 is a process flow diagram of a diagonal wipe 3D callback. 25 Figure 7 is a process flow diagram of a 2D diagonal wipe transition. Figure 8 illustrates how the scatter transition separates an image. Figure 9 is a process flow diagram for the drawing procedure of the Scatter transition. Figures 1Oa - c are a series of images illustrating the Wipe transition. 30 Figures 11 a - c are a series of images illustrating the Fade transition. Figures 12a - c are a series of images illustrating the Iris transition, Detailed Description of the Drawings 35 Referring to Figure 1, a graphics system 10 for a gaming machine 20 comprises a transition library 12 which stores various types of transitions, for example, slide, wipe, scatter, fade, iris, shrink, curtain and rotate transitions. The graphics system 10 35449981 (GHMater)PU817LAU.I 2507/12 3 also provides a graphics engine 14 to apply a selected transition type from the transition library 12 to one of two images for determining the way in which a substitution of a first image by a second image occurs. The graphics engine 14 also initialises transition data (t data) for effecting an incremental removal of the first image to reveal the 5 THE NEXT PAGE IS PAGE 6 35449981 (GHMtters) P3617LAU.] 25/07Y2 6 -second image. A control means 16 modifies the transition data (t_data) such that when . the selected transition type is being effected, an incremental removal of at least a part of the first image by the second image occurs serially until the first image has been removed in its entirety to reveal the second image on a display 18 of the gaining 5 machine 20. Referring to Figure 2, the graphics engine 14 executes an application code thread 25, sceneupdatetask thread 30 and scene3dupdatetask thread 40. There are three main functions to facilitate image transitions. Firstly, the application code thread 25 has an _addtransition0 function 26 which selects a transition and initialises its 10 transition data (tdata) structure and attaches it to an image. Secondly, the scene update_task thread 30 has an _updatesceneo function 31 which interrogates images within the scene list to determine whether they have transition data (t~data). Thirdly, if transition data (tLdata) is found, the transitionactionso function 32 of the scene .updatetask thread 30 is called to maintain and/or update the selected transition. 15 The scene3dupdate task thread 40 is used for 3D images and is provided with functions including: scenerendero 41, _refreshDMEx0 42, _refreshDMO 43 and a 3D transition callback function, diag wipe3d_cb_DMO 44. The scene3dupdatetask thread 40 calls _refreshDMO 43 to call the 3D transition callback function 44. The callback function 44 uses the transition data (t data) attached to the image to draw the 20 selected transition via OpenGL calls. For any individual transition, the application code 25 and scene updatetask 30 threads cannot run concurrently. Also, the scene3dupdatetask 40 and sceneupdate_task 30 threads cannot run concurrently. addtransitiono 25 Referring to Figures 2, 4 and 5, the application code thread 25 calls the _addtransition0 function 26 to attach the selected transition to an image. Applying a transition to an image requires the name and position of the subject image to be known. Unless these are correct, the transition command is ignored. The command itself both identifies the subject image and specifies the transition parameters as shown in the code 30 below: Transitionsceneid= addtransition image identifier, screen position x, 35 screen position y, transition type, 7 direction, duration 5 The variable "Transition-scene id" is used with the existing graphics commands to both start and reset the transition at desired times. Resetting a transition is useful to reveal several consecutive images, or if the transition has been interrupted by another gaming machine event. When _addtransitiono 26 is called, the selected transition assumes that the 10 image already exists in the scene list and DM (Display Manager). An example of calling the _addtransitionO function 26 is shown below: OBJECT Imp; tmp = getobjecthandle("IMGSYM_TEN", _IMAGE); 15 s_id1 = addscene(tmp, 100, 100, 0, 0, HIGHER._PRI); t_id1 = addtransition(tnp, 100, 100, SLIDE, TOP_LEFT, 3200); _controlscene(s_id, SCENESTART); 20 _controlscene(t_id1, SCENESTART_TRANS); The transition (t idl) is added in the same position that the image exists in for the scene (s~id1). If this procedure is not met, then _addtransitionQ 26 will fail. The following code extract shows how _addtransitionO 26 searches for the resource in the 25 DM (Display Manager) and checks if the resource is in the same location that the user wants to attach the transition to. DmItem= FindResourceDM(pImage->hDc, -1); getitempositionDM(Dmlten, &Rect); 30 while (DmItem 1= -1) { if (Rect.top = yPos && Rect.left xPos) { _getscenedataDM(DmItem, &scene id) 35 break;

}

8 else { Dmltem= FindResourceDM(pImage->hDc, DmItem); getitempositionDM(Dmltern, &Rect); 5 )} Could not find the object at that spot. if (DnItem -1) 10 return GRERROR; Next, _addtransitiono 26 adds a duplicate of the image to the scene list so that it can modify the duplicate image for the transition. _addtransitionO 26 also initialises all transition data datat) variables for the 15 associated duplicate image. Below is a code extract that details the initialisation of the transition data datata. scene list[newsceneindex].t data (TRANSrTEM *) avImalloc(sizeof(TRANS_1TEM)) scenejlist[newsceneindex].tdata->swansong = swansong; 20 scene list[newsceneindex]j.tdata->direction= dir; scene list[new_scene_index].t data->duration = dur, scene list[newsceneindex].t data->status =NOT_YETSTARTED; scene listinew_scene_index].tdata->curr_x = 0; scene listrnew_scene_index].tdata->curr y=0; 25 scene listinewsceneindex].tLdata->generic1 =0; scene list[newscene_index].t data->generic2 =0; scene list[newsceneindex].tLdata->generic3 =0; scene listfnewsceneindex].t data->generic4 =0; scenejlist[new_sceneindex].t data->generic5 =0; 30 scene-list[newsceneindex].t data->generic6 =0; scene list[newscene index).tLdata->cllbckDMitem= -1; scene list[newsceneindex].t data->randomlist = (NLIST *) 0; scene list[newscene_index].t_data->randomlist3D =(int *)0; 9 Many of the variables within the tdata structure are dependent on the type of transition chosen, however some are present for all transitions. Below is a table explaining the variables of the tdata structure. T data variable Meaning swansong Type of transition direction Depends on transition chosen -as different transitions have different subtypes/directions duration Length of transition status Current state of the transition generic - generic6 All these variables are different for each transition cUbckDMitem This refers to the callback function that is attached to the transition in 3D mode when a window is created. randomlist This is the list of squares to be removed. Specific for the SCATTER transition in 2D mode. randomlist3D This is the list of squares to be removed. Specific for the SCATTER transition in 3D mode. 5 If the selected transition requires modification of the original image, for example, the "Iris Wipe" transition, an offscreen DC (Device Context) is created for a duplicate transition image. Below is a list of transitions that do not require an offscreen DC (Device Context) to be created. 10 10 Transition .2D/3D ROTATE 3D SHRINK ANY SLIDE ANY FADE 3D WIPE ANY, wipes in left, right, up and down do not need to create a DC either as we are doing micro clipping and this does not affect the original image. IRIS 3D SCATTER 3D CURTAIN 3D Referring to Figure 3, when an offscreen DC (Device Context) has been created for a duplicate transition image,- the original image is removed. In 3D mode after the 5 offscreen DC has been created, cloneimageitemDMO 51 is called which adds the transition image DC to the DM (Display Manager). However, in 2D mode, a _bitbitO 52 is done to copy the duplicate image to the DC. Next, _additemDMO 53 is called to add the transition image DC to the DM (Display Manager). For error handling purposes, applying a transition to a resource other than an 10 image results in addtransitionO 26 returning an error. updatesceneO In the image transition process, the updatescene( function 31 is called for each refresh of the gaming display 18. Also, each image to be displayed is checked to see if 15 it contains any transition data. If the image contains transition data datat) and the transition is in progress, transitionactionsO 32 is called as shown in the code extract below: if (scene listi].t_data != 0 && scenelist[i].tdata->status IN_PROGRESS) 20 transition actions(i,&callbackreqd); transition actionsO Transitions are maintained and updated by the transition actions function 32. Transitions can be updated using pixel operations or whole image operations, for 11 example, scaling. The transition actionsO function 32 modifies all the transition.data (tdata) for the next refresh of the display 18. Each individual transition contains unique algorithms and procedures to remove parts of the image from the display 18. However, some of the transitions within transitionactionsO 32 only have a 2D 5 implementation. Other transitions have a 2D and 3D implementation. The transitions that are only available in 2D use a specific 3D callback function 44 to cater for those transitions in 3D mode. If in 3D mode, the first time transitionactionso 32 is called, a DM (Display Manager) window is created at the location of the image and attaches a 3D callback 10 function 44 to this window. At every refresh, transition_actionsO 32 modifies all the t_data. Also, the 3D callback function 44 attached to this window processes the tdata structure and implements the transition using OpenGL calls. The code extract below illustrates the initialisation of the DM (Display Manager). window with a scatter_3D-cbDMO callback 44. 15 scenisti].t-data->clibckDMitem= addwindowDM Rect.Ief, Recttop; 20 scatter 3DcbDM, DIALPHA, getjpriority(i), Rect.top>=ODMBOIToMSCREEN:DM_TOP_SCREEN 25 Below is a list of the associated 3D callback functions 44 for each transition. Transition 3D Callback WIPE (any diagonal direction) diag wipe 3D cbDM SCATTER scatter 3D cbDM IRIS iris 3D cbDM CURTAIN (type 2) curtain2 3D cbDM CURTAIN (type 1) curtains 3D cbDM 30 12 Referring to Figures 4 to 6, not all transitions require their own callbacks 44 in 3D mode. This is determined according to the implementation or specification of individual transitions. For example, the Wipe transition in any non-diagonal direction uses micro clipping. Thus for this transition there is no need for OpenGL operations. 5 Referring to Figure 4, _refreshDMO 43 does not call a 3D transition callback 44 since transitionactionsO 32 has ensured that the transition data (tLdata) has been updated or modified for the next refresh of the display 18. This is .different*to the scenario shown in Figure 2. Also, in this scenario, the application code 25 and the scene updatetask 30 threads do not run concurrently and the scene3dupdatetask 10 thread 40 also does not run concurrently. Referring to Figure 5, _refreshDMO 43 is called in the context of the scene updatetask thread 30. There are also no 3D callbacks in 2D mode and transitionactionsO 32 has ensured that the transition data (tdata) is updated and modified for the next refresh. Also, the application code 25 and scene_update taskO 30 15 threads do not run concurrently. Referring to Figure 6, _refreshDMO 43 is called in the stream of execution for the diagonal wipe transition. When _refreshDMO 43 is called, each DM (Display Manager) item is drawn and checked to see if it has a draw handler attached 60. If the image has a transition attached to it then the attached draw handler is initiated 61. In the 20 diagonal wipe transition, diag_ wipe_3DcbDMO is called 61. The Wipe transition is drawn using OpenGL calls 62. The code extract below* illustrates the operation of _refreshDMO 43 with draw handlers. for (i = 1; i <DmItemsUsed; i++) 25 { if (pItem->pDrawHnd && (pItem->WhichScreen & DMBOTI'OMSCREEN)) { (pItem->pDrawHnd) (hBack, 30 pItem->Rect.left, pItem->Rect.top, pItem->DrawMode, pItem->Val); continue; 35 ) 13 Referring to Figure 7 , the original image is copied into temporary memory 71 for a diagonal wipe transition in 2D mode. The duplicate image is added to the display 18 over the original image 72 and the original image is removed 73 from the display 18. The wipe increment is calculated according to the formula shown at step 74. The 5 amount of the image that has been "wiped" is stored in the variable wipe dist, and is incremented at step 75. Then, pixel commands cause successive lines to disappear from the temporary image 76 on the gaming machine display 18. When waiting 77 for the next refresh of the display 18, the variable wipe dist is compared with the variable.img width to determine if more "wiping" is necessary 78. If the value of wipe dist is not 10 equal to the img width variable, steps 75 to 78 are repeated. However, if wipe dist is equal to img width, the temporary image is -removed and the temporary memory is released 79 ending the transition 80. In 3D mode, different commands are used for step 76 instead of pixel commands to draw the transition. For example, OpenGL triangle commands could be 15 used. Scatter Transition Example The Scatter transition receives a value (direction parameter) from the _addtransitiono function 32. The direction parameter value is the size of the individual 20 scattered squares, which is represented as a 1000t of a percent of the image area. For example, a value of 2500 is a square size that is 25% of the image area. The Scatter transition then determines the number of squares needed for the transition and calculates the position of the top left corner of each square 81 and assigns this value to each square. Figure 8 illustrates the separation of the image by the Scatter transition. 25 The lists of squares (1-n) are randomly selected so that a random square is deleted from the image. The tdata structure for the Scatter transition has eight variables that are used for cumulative transition calculations. It is not known until the implementation of the transition algorithm is complete whether more variables are required. 30 TransitionactionsO 32 is modified for the Scatter transition. This modification includes the transition algorithm and the correct timing, so that the transition is completed within a user specified time. Below is an excerpt of the initialisation of the scatter transition in transitionactionsO 32. 35 case SCATTER

{

14 if (t data->genericl 0 && t data->generic2 0)

{-

/* get square size based on area of image */ img-area = width * height; 5 square size = img area 4 t data->direction 10000; generici5 is the square size. square size = tdata->generic5 = mborg isqrt((ong)squaresize); // generic3 is the number of x divisions. generic4 is the number of y divisions t_data->generic3 (width % square-size 1=0) ? width /squaresize + I width/ 10 squaresize; t-data->generic4 = (height % squaresize 1=0) ? height / squaresize + 1 height / squaresize; no-of squares = tdata->generic3 * t_data->generic4; 15 /* allocate space for rand numbers */ t_data->randomlist = avlmalloc(sizeof(NST)*no-of squares); makerand anay(squaresize, no-of squares, t data->randomlist, width, t data >generic3); if (Is3D) 20 { RECT Rect; _getitempositionDM(scenelst[i].imagelist[O], &Rect); scene list[i].t data->cllbckDMitem addwindowDM 25 Rectleft, Rect.top, scatter_3DcbDM, DIALPHA, i, 30 get-priority(i), Recttop>=0 ?DMBOITOMSCREEN:DMTOPSCREEN _invalidateitemDM(scenelist[i].t data->cllbckDMitem, 0); uninvalidateitemDM(scenelist[i].imagelist[0]); 35 tdata->randomlist3D = avhnalloc(sizeof(int) * no-of squares); 15 for (j 0; j < no of squares; j++) t_data->randomlist3DOj]= 1; } 5 ... To illustrate the process of initialisation, the code above is executed once at the start of the transition to split up the image into numbered squares as shown in Figure 8. Also, during initialisation, a Display Manager window is created for a 3D callback 44. 10 Generally, each transition has a shape that.is derived from the transition. For example, the iris wipe transition has a circle and the wipe has a line. For the Scatter transition, this is a square. In relation to timing, the number of squares to remove per refresh period is based on the duration value passed from _addtransitionO 26. The code extract below illustrates the number of squares to remove per refresh period (spf). 15 /* timing */ lpf_1000 =((noof squares * fbp) / t_data->duration); tdata->generic2 + lpf_1000; spf= t data->generic2 /1000; 20 tdata->generic2 O/= 1000; The.lpf_1000 variable holds the squares to remove per refresh period x1000 to reduce rounding errors. The lpf_1000 variable is added to the tLdata->generic2 variable which is divided by 1000 to produce the final value for the number of squares to be 25 removed for the current refresh period (spf). The remaining lines are stored in t data >generic2 for the next refresh period. Once the spf is calculated, a for loop is executed to remove a certain number of squares from the image per refresh period. The following code segment illustrates this. 30 forj=oj<spfj++) { /* create random rectangle to clear */ area.left = tdata->randomlistft data->genericl].x - x-offset; area.top = t data->randomlist[t data->genericl].y - offset; 35 area.right= tdata->randomlist[tdata->generic].x + tdata->generic5 - x_ofset; area.bottom = tdata->randomlist[tdata->generic].y + tdata->generic5 - offset; 16 /* for squares that fal off the DC */ area.left= (area.left <0) ? O: area.lef; area.top = (area.top <0) ? 0 : area.top; area.right = (area.right > width) ? width area.right; 5 area.bottom -(area.bottom > height) ?height: area.bottom; SoftFill(scene->playDc[0],&areaO); t_data->generic++; 10 if(tdata->genericl = no-of squares) { remove=TRUE; /* free all dynamic allocated memory * _avlfree(tdata->randomlist); 15 tdata->randomlist =(NLIST *) 0; break; ) } 20 Referring to Figure 9, there are different drawing procedures depending on whether the transition is in 2D mode or 3D mode. In 2D mode, SoftFillo 90 is called to fill a rectangle. Figure 8 illustrates the division of the image into many smaller squares. A random number is chosen and the rectangle coordinates are calculated and put into a RECT structure. The SoftFillo function 90 is called in the following way: 25 SoftFill(scene->playDc[0],&area,O); SofIFillO 90 instructs the current DC (Device Context) to set each pixel to '0' in the given rectangle 'area'. The for loop may get executed n times per refresh period. In 30 this case, SoftFill0 90 fills n rectangles that are chosen randomly at each refresh period. In 3D mode, a specific 3D callback, scatter _3DcbDM 44 is called 91 via _refreshDMO 43. This function 44 which performs its own OpenGL operations and divides the image into little triangles forming squares. To draw the transition image, 35 less and less of the image is drawn each refresh period.

17 When the transition has ended it is removed from the DM (Display Manager). In 2D mode, tLdata->genericl is incremented each time the SofiFillO function 90 is called in the for loop. The t data->genericl variable indicates the number of squares that have been removed already. When the tdata->genericl -variable reaches the number of 5 squares that exist, the image is removed. The code extract below illustrates this: if(tdata->genericl noof squares) remove=TRUE; 10 /* free all dynamic allocated memory */ _avlfree(tdata->randomlist); t-data->randomlist= (NLIST *) 0; break; } 15 Once the remove variable is set to true, transition actionsO 32 removes the transition from the DM (Display Manager) and cleans up the code. The user may also want their own clean up code, as shown in the code extract above. The clean up code also frees the memory that was allocated for the random list of integers. 20 Although the Scatter transition has been described, it will be appreciated that other transitions are also envisaged. New transitions can be added by: * modifying the tdata structure to add additional tdata variables, * adding the transition algorithm and timing to the transition.actionsO function 32, and 25 e if necessary, creating a 3D callback 44 with the transition algorithm and timing. Referring to Figures 1 Oa - c, the Wipe transition is shown. A landscape image is gradually removed line by line from the bottom of the image, gradually exposing the underlying graphics. 30 Referring to Figures 1 la - c, the Fade transition is shown. The image gradually fades until it is no longer visible. Referring to Figures 12a - c the Iris transition is shown. The landscape image is gradually removed by the appearance of a "hole" in the middle of the image. The hole grows until the entire image is replaced and the underlying graphics wholly exposed. 35 It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific 18 embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (6)

1. A graphics system for displaying images on a gaming machine display, the system comprising: 5 a transition library having transition types, each type corresponding to related display control data; a graphics engine configured to select a transition type from the transition library for substituting a first of the images by a second of the images, initialise the corresponding display control data for effecting an incremental substitution on a part of 10 the first image by a part of the second image with the display control data, selectively attach display control data corresponding to the selected transition type to the first of the images, and determine if display control data is present at the first of the images; and a controller in response to display control data being present, configured to is update the attached display control data during the incremental substitution, and effects the incremental substitution on another part of the first image serially until the first image has been substituted by the second image on the gaming machine using the updated display control data. 20

2. A graphics system according to claim 1, wherein said second of the images is initially placed behind said first of the images.

3. A graphics system according to claim 2, wherein the first image is incrementally removed by the transition type to reveal or expose at least a part of the 25 second image until the first image has been entirely removed to reveal the second image.

4. A graphics system according to claim 2 or claim 3, wherein the selected transition type is drawn using any one or more of pixel operations, scaling operations, 30 microclipping operations or OpenGL operations,

5. A graphics system according to any one of claims 2 to 4, wherein at least one of the first and second images is an animation of a plurality of transitional images. 35

6. A graphics system according to claim 5, wherein the second image is an animation of a plurality of transitional images. 35449981 (GHMatsn)P8171 AU. 26/07/12