home *** CD-ROM | disk | FTP | other *** search
/ Falcon 030 Power 2 / F030_POWER2.iso / ST_STE / MAGS / ICTARI07.ARJ / ictari.07 / ASSEMBLY / SPRITES / M_SPRITE.DOC < prev    next >
Text File  |  1993-09-03  |  6KB  |  120 lines
  1. SUB-ROUTINE NAME        m_sprite
  2. BRIEF DESCRIPTION       Display moveable sprite
  3. FILENAME                SPRITE.S
  4. OTHER RESOURCES
  5. LANGUAGE                Assembler (Devpac)
  6. AUTHOR                  Peter Hibbs
  7.  
  8. ENTRY PARAMETERS        d0=x co-ordinate of hot spot (0-319)
  9.                         d1=y co-ordinate of hot spot (0-199)
  10.                         d2=sprite number (1-nn)
  11.                         (screen) holds screen start address
  12.                         (spr_buffer..) holds last copy
  13.                         (sprite_tab..) holds sprite info
  14.  
  15. EXIT PARAMETERS         Sprite displayed on screen.
  16.  
  17. DETAILS -
  18.  
  19. This routine moves a sprite to the  co-ordinates defined by d0 and d1 and
  20. restores the screen data beneath the sprite. The sprite data is generated
  21. by the Neochrome Master art program  which  has  a facility to generate a
  22. sprite file. The sprite data is first loaded from disk by the sprite_init
  23. sub-routine which also generates a mask file  and a look-up table for the
  24. sprite addresses,  offsets,  etc.  See  data  sheet  for  sprite_init for
  25. information on setting up the system.
  26.  
  27. The m_sprite sub-routine consists of three  main sections, the code which
  28. restores the old screen area, the  code  which  saves the new screen area
  29. and the code to display the sprite itself.
  30.  
  31. When the  routine  is  called  it  first  restores  the  area  of  screen
  32. underneath the sprite  which  is  stored  in  a  temporary  buffer called
  33. spr_buffer (unless the buffer is empty as  it would be the first time the
  34. sprite is displayed in which case it is skipped).
  35.  
  36. When the screen has been 'repaired' (or  skipped) the screen area for the
  37. new position of the sprite (defined by the x/y co-ords in d0/d1) is saved
  38. in the sprite buffer. The screen data  is stored in the buffer along with
  39. the address and size of the area of  screen saved. The first 4 bytes hold
  40. the screen address of the start  of  the  sprite data, if these bytes are
  41. set to 0000 the routine will assume  the  buffer is empty and not attempt
  42. to copy the data to screen  (the  program  should ensure that these bytes
  43. are set to zero before the sprites  are  used or the program will crash).
  44. The next 4 bytes define the width  and  height of the sprite and are used
  45. to determine the size of area to be copied. The following n bytes are the
  46. screen data, the number will vary depending on the size of the sprite.
  47.  
  48. The routine then displays  the  sprite  on  screen  at  the specified co-
  49. ordinates.
  50.  
  51. The 'hot spot' for a sprite is normally  the top left pixel of the sprite
  52. rectangle (regardless of the shape of the visible area of the sprite) and
  53. this is the  pixel  defined  by  the  d0/d1  registers.  It  is possible,
  54. however, to change the hot spot  (to  the  centre point of the sprite for
  55. example) with the SPR_CHCK.PRG program (see SPRITE.TXT document file).
  56.  
  57. If an invalid co-ordinate is passed to  the routine (i.e. d0 greater than
  58. 319 or d1 greater than  199)  the  screen  area  will be restored but the
  59. sprite image will not be displayed. This option thus allows the sprite to
  60. be erased at any time without corrupting the screen.
  61.  
  62. Clearing the first 4 bytes  of  the  spr_buffer  to zero will effectively
  63. erase the screen data and may be used when changing sprite images.
  64.  
  65. One limitation of the sub-routine is  that  no  'clipping' is done on the
  66. left and right edges of the  sprite.  If  the  sprite is displayed at the
  67. extreme right of the screen, part of it  will appear on the left edge. If
  68. it is displayed at the left edge with  the  hot spot set to the centre of
  69. the sprite, it will disappear since the  x co-ordinate will be a negative
  70. value which is invalid. To add clipping code is extremely complicated and
  71. would slow the sprite display somewhat. If  a sprite is moved by the user
  72. the program could prevent this  problem  by  limiting the movement of the
  73. sprite to avoid the edges.  The  top  and  bottom edges are clipped since
  74. this crashes the program  if  data  is  written  to  an  area outside the
  75. screen.
  76.  
  77. Since there is only one sprite  buffer  available, it is only possible to
  78. have one moveable sprite on screen  at  any  one time. If there were more
  79. than one it would be extremely difficult  to ensure that the correct data
  80. was being redrawn to the  screen  if  the  two  (or more) sprites were to
  81. cross each others paths. If the  program  requires a number of sprites on
  82. screen at the same time, the  s_sprite  sub-routine should be used (which
  83. is much faster) and screen switching  employed  to give the impression of
  84. movement. The sprites should be  copied  to  the  screen during one frame
  85. blanking period and displayed during  the  next  and the screens switched
  86. each period.
  87.  
  88. The size of the spr_buffer can be calculated with the following formula.
  89.  
  90.      buffer size (bytes)=(width in bytes+4)*(height in pixels)+8
  91.  
  92. For example, a sprite of 8 bytes  wide  by 10 pixels high would require a
  93. buffer of (8+4)*(10)+8=128 bytes, say  150  (just  in case). These values
  94. can be obtained by using the  SPR_CHCK.PRG program supplied. Note that if
  95. several different sprites are to be used,  the largest one should be used
  96. to calculate the buffer size.
  97.  
  98. Where a  sprite  is  moved  it  will  almost  certainly  be  necessary to
  99. synchronise the  display  with  the  frame  blanking  signal  to  prevent
  100. flicker. A typical piece of code is shown below.
  101.  
  102.                 bsr     sprite_init     set up table and buffers
  103.                 tst.l   d0              check for error
  104.                 bmi     error_label     branch if load error
  105.                 clr.l   spr_buffer      ensure buffer is clear
  106.  
  107.         label   bsr     ms_posn         fetch x/y co-ords from mouse
  108.                 move    d2,d3           button state copied to d3
  109.                 bsr     vsync           wait for frame blanking signal
  110.                 move    #10,d2          use sprite number 10
  111.                 bsr     m_sprite        display sprite
  112.                 tst     d3              check if button pressed
  113.                 beq     label           loop if no button pressed
  114.                 ..      ..
  115.  
  116. (ms_posn sub-routine returns immediately with the current x co-ord in d0,
  117. the y co-ord in d1 and the mouse button state in d2).
  118.  
  119.  
  120.