Sprite8.hsf 5.3 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
  1. [Main]
  2. Name=Sprite8
  3. Type=Function
  4. Subtype=tigcc.a
  5. Header Files=sprites.h
  6. Definition=void Sprite8 (short x, short y, short height, const unsigned char *sprite, void *vm_addr, short mode);
  7. [Description]
  8. Draws a sprite with a width of 8 pixels or less on the screen.
  9. [Explanation]
  10. Sprite8 draws a sprite with a width of 8 pixels or less on the screen.
  11. Use <A HREF="$$LINK(sprites.h/Sprite16)">Sprite16</A> or <A HREF="$$LINK(sprites.h/Sprite32)">Sprite32</A> for wider sprites.
  12. This routine is many times faster than TIOS routines like
  13. <A HREF="$$LINK(graph.h/DrawIcon)">DrawIcon</A>, <A HREF="$$LINK(graph.h/BitmapPut)">BitmapPut</A>, etc.
  14. <I>x</I> and <I>y</I> are the coordinates of the upper left corner of the sprite.
  15. <I>height</I> is the height of the sprite. <I>sprite</I> is a pointer to the array of
  16. unsigned characters which define the shape of the sprite (line by line). <I>vm_addr</I> is the pointer
  17. to the video plane; it should be <A HREF="$$LINK(graph.h/LCD_MEM)">LCD_MEM</A> if you are not using
  18. grayscale or the <A HREF="$$LINK(graph.h/PortSet)">PortSet</A> function. <I>mode</I> is the drawing
  19. mode, and it may have one of the following values (these constants are defined in the enum
  20. <A HREF="$$LINK(sprites.h/SprtModes)">SprtModes</A>):
  21. <BR><BR>
  22. <TABLE BORDER CELLPADDING="3">
  23. <TR>
  24. <TD VALIGN="TOP">SPRT_XOR</TD>
  25. <TD>XOR the sprite into a background. This is used only for non-masked sprites.
  26. XOR mode switches every pixel with a corresponding '1' bit in the <I>sprite</I> array from white to black and verse vica.</TD>
  27. </TR>
  28. <TR>
  29. <TD VALIGN="TOP">SPRT_OR</TD>
  30. <TD>OR the sprite into a background. This is mainly used for masked sprites together with SPRT_AND.
  31. OR means that every pixel with a corresponding '1' bit in the <I>sprite</I> array will be set to black, but all other pixels stay the same.
  32. If you want to turn all other pixels to white instead, use SPRT_RPLC.</TD>
  33. </TR>
  34. <TR>
  35. <TD VALIGN="TOP">SPRT_AND</TD>
  36. <TD>AND the sprite into a background. This is used for masked sprites together with SPRT_OR.
  37. AND turns off every pixel with a corresponding '0' bit in the <I>sprite</I> array, but all other pixels remain untouched.
  38. If you want to turn all other pixels to black instead, use SPRT_RPLC.</TD>
  39. </TR>
  40. <TR>
  41. <TD VALIGN="TOP">SPRT_RPLC</TD>
  42. <TD>RePLaCe the sprite into a background.
  43. RPLC sets every pixel with a corresponding '1' bit to black and every pixel with a corresponding '0' bit to white.
  44. This is equivalent to calling <CODE>Sprite8(x,y,h,sprite,plane,SPRT_AND); Sprite8(x,y,h,sprite,plane,SPRT_OR);</CODE>.</TD>
  45. </TR>
  46. </TABLE>
  47. <BR>
  48. In fact, you can use one of two techniques to draw sprites:
  49. <UL>
  50. <LI>
  51. <B>Non-masked sprites.</B> Using this method, the sprites are simply XORed into the background. This
  52. technique was popular in many games on old 8-bit computers. To erase the sprite, it is
  53. enough to call the routine again on the same position.
  54. </LI>
  55. <LI>
  56. <B>Masked sprites.</B> This is the more advanced method, which needs more programming practice,
  57. but produces much better results. Using this method, you first need to erase a
  58. part of the background which occupies a space where the sprite need to be displayed,
  59. then to draw the actual sprite shape. To do this, AND the inverse of the sprite mask
  60. to the background, then OR the sprite at the same location. However, it is not so
  61. easy to restore the background later. For solving this problem, a lot of advanced
  62. methods are developed (like "double-buffering", etc.). These methods are quite
  63. common in advanced ASM games, and they are explained in many ASM tutorials.
  64. </LI>
  65. </UL>
  66. Here is a simple example (called "Masked Sprite"), which first draws a simple "background", then draws a "masked"
  67. sprite (which is a simple 8x8 square with solid edges and blank interior) at (30,30):
  68. $$EXAMPLE(Masked Sprite.c)
  69. Here the sprite mask is <CODE>{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}</CODE>, but it needs to
  70. be inverted before passing it to the Sprite8 function. For this purpose, the operator '~' may be
  71. very useful. Note that '~' is "bitwise NOT". Of course, ~0xFF is the same as 0x00, but this notation
  72. makes the program more clear (and it does not increase the code size, because the inverting will
  73. be performed at compilation time). And if you want to use <A HREF="$$LINK(sprites.h/Sprite16)">Sprite16</A> or
  74. <A HREF="$$LINK(sprites.h/Sprite32)">Sprite32</A>, the notation ~0xFF will still be valid in a short int array, or in a long int array
  75. if you add the <B>'L'</B> suffix (see the respective info about <A HREF="$$LINK(sprites.h/Sprite32)">Sprite32</A>).
  76. Without this notation, you must use 0x00 in Sprite8, but 0xFF00 in <A HREF="$$LINK(sprites.h/Sprite16)">Sprite16</A>, and
  77. 0xFFFFFF00 in <A HREF="$$LINK(sprites.h/Sprite32)">Sprite32</A>. This is why a notation like ~0xFF is more universal.
  78. <BR><BR>
  79. Starting from TIGCC v0.91, you can use binary numbers to define your sprites. On the one hand,
  80. it makes the program incompatible with other C dialects as well as previous (ancient) versions of
  81. TIGCC. On the other hand, it makes designing a sprite much easier
  82. and also allows for editing the sprite at a later time without having to reconvert it.
  83. The binary representation of the sprite presented above would look like this:
  84. <PRE>static const unsigned char sprite[]={
  85. 0b11111111,
  86. 0b10000001,
  87. 0b10000001,
  88. 0b10000001,
  89. 0b10000001,
  90. 0b10000001,
  91. 0b10000001,
  92. 0b11111111};
  93. </PRE>