SPRITE.DOC 7.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201
  1. SPRITE DOC
  2. ------------------------------------------------------------
  3. if you haven't already obtained "yoshi doc", get it and read it before you
  4. read this doc....
  5. Part I - the bitplane representation of a 16 color 8x8 pixel tile
  6. -----------------------------------------------------------------
  7. sprites are made of tiles, in particular 4-bitplane tiles, 4-bitplane
  8. tiles, means that the tiles are made of 4-bit color values, so this means
  9. that the tiles can have a maximum of 16 colors.
  10. in many graphics formats, this type of data would be stored as follows
  11. (assuming a 8 pixel by 8 pixel tile)
  12. $1 $0 $2 $8 $2 $4 $5
  13. $2 $0 $6 $1 $f $e $1
  14. $a $2 $2 $2 $6 $7 $0
  15. $1 $0 $2 $8 $2 $4 $5
  16. $1 $0 $2 $8 $2 $4 $5
  17. $1 $0 $2 $8 $2 $4 $5
  18. $1 $0 $2 $8 $2 $4 $5
  19. $1 $0 $2 $8 $2 $4 $5
  20. where each hex number represents a color, so pixel (0,0) would be color
  21. number "1", and pixel (4,2) would be color "6"....this is <not> the case
  22. on the super nintendo....for reasons having to do with the implementation
  23. of the graphics engine, the super nintendo represents its image data in
  24. the "bitplane" format, assuming and 8 pixel by 8 pixel tile with 16
  25. colors, this data would have four bitplanes (0-3) of monochrome, binary
  26. image data:
  27. 0 0 0 0 0 0 0 0
  28. 0 0 0 0 0 0 0 0 1
  29. 0 0 0 0 0 0 0 0 1 2
  30. 0 0 0 0 0 0 0 0 1 2 3
  31. 0 0 0 0 0 0 0 0 1 2 3
  32. 0 0 0 0 0 0 0 0 1 2 3
  33. 0 0 0 0 0 0 0 0 1 2 3
  34. 0 0 0 0 0 0 0 0 1 2 3
  35. 1 1 1 1 1 1 1 1 2 3
  36. 2 2 2 2 2 2 2 2 3
  37. 3 3 3 3 3 3 3 3
  38. four monochrome 8x8 pixel images stacked on top of each other. if you
  39. wanted pixel (4,2) to have the color "6" you would have to put a "1" in
  40. bitplane one, and a "1" in bitplane two, with the bitplane zero and three
  41. having "0"'s. this is because the binary representation of "6" is "0110".
  42. ok, so it is obviously possible to store each monochrome bitplane in 8
  43. bytes, each byte representing a row in the bitplane. so a single tile
  44. takes up 32 bytes (8 bytes per row * 8 rows * 4 bitplanes) of memory.
  45. Part II - the way tiles are stored in vram for sprite data
  46. ---------------------------------------------------------
  47. in vram you store a tile 16 bits at a time as follows:
  48. <-------2 bytes at a time------>
  49. <--1 byte wide-><--1 byte wide->
  50. [plane 0, row 0][plane 1, row 0]
  51. [plane 0, row 1][plane 1, row 1]
  52. [plane 0, row 2][plane 1, row 2]
  53. ..
  54. ..
  55. ..
  56. [plane 0, row 7][plane 1, row 7]
  57. [plane 2, row 0][plane 2, row 0]
  58. [plane 2, row 1][plane 2, row 1]
  59. [plane 2, row 2][plane 2, row 2]
  60. ..
  61. ..
  62. ..
  63. [plane 2, row 7][plane 2, row 7]
  64. the super nintendo can have two different sizes of sprite on the screen
  65. at one time, you can choose from the following combinations:
  66. [value] [sprite size 0][sprite size 1]
  67. 000 8x8 pixel 16x16 pixel
  68. 001 8x8 pixel 32x32 pixel
  69. 010 8x8 pixel 64x64 pixel
  70. 011 16x16 pixel 32x32 pixel
  71. 100 16x16 pixel 64x64 pixel
  72. 101 32x32 pixel 64x64 pixel
  73. it is set in the upper three bits of address $2101....so to use 8x8 pixel
  74. sprites, and 32x32 pixel sprites, you would load $2101 with the value
  75. "001xxxxx" (where x is don't care)
  76. the lower five bits of address $2101 are also very important, these bits
  77. tell the super nintendo where in vram your sprites are located. the
  78. lowest three bits are the "name base", and the fourth and fifth bits are the
  79. "name". the "name" bits specify the upper 4k word of the sprite address,
  80. and the "name base" specfies the offset. so if put you tile data in vram
  81. $0000 you would set these bits all to zero.
  82. suppose you want to have four 32 pixel by 32 pixel sprites; each would be
  83. composed of 16 tiles, each tile is numbered, tiles $0-$3f
  84. [sprite 0]
  85. 0 1 2 3
  86. 4 5 6 7
  87. 8 9 a b
  88. c d e f
  89. ..
  90. ..
  91. [sprite 3]
  92. 30 31 32 33
  93. 34 35 36 37
  94. 38 39 3a 3b
  95. 3c 3d 3e 3f
  96. in vram, these tiles, $0 through tile $3f would be store in an interlaced
  97. fashion as follows:
  98. $0 $1 $2 $3 $10 $11 $12 $13 $20 $21 $22 $23 $30 $31 $32 $33
  99. $4 $5 $6 $7 $14 $15 $16 $17 $24 $25 $26 $27 $34 $35 $36 $37
  100. do you see the pattern? you must store the first row (four tiles) of each
  101. sprite, and then the second row, then the third, etc....
  102. if you were dealing with 8x8 sprites, you would have to store the first
  103. row of 16 sprites, then the second row of the 16 sprites, etc....
  104. if you were dealing with 16x16 sprites, you have to store the first row
  105. of 8 sprites, then the second, then the third, etc...
  106. with 64x64, yep, you guessed it, the first row of two sprites, then the
  107. second row, etc....
  108. Part III - setting up the OAM table for your sprites
  109. -----------------------------------------------------
  110. for each sprite in the sprite table (maximum of 128 sprites, numbered 0-127)
  111. you must have four bytes of information, the first byte is the low 8 bits of
  112. the horizontal position of the sprite, the second byte is the vertical
  113. position of the sprite, the third byte is the "address" of the sprite...
  114. it is not the actual vram address, it is the tile number, that is to say,
  115. the physical vram address of the sprite can be obtained by the following:
  116. multiply the sprite "address" by 32 (because each tile is 32 bytes) and add it
  117. to the starting vram address that you set in the $2101 register.
  118. this tile number points to the first tile in the sprite...the snes expects the
  119. rest of tiles to follow in the order described in the previous section...
  120. the next byte containes the 9th bit of the tile "address" and a few attributes
  121. bit 0 = 9th bit
  122. bit 1-3 = palette number
  123. bit 4,5 = playfield priority
  124. bit 6 = horizontal flip
  125. bit 7 = horizonal flip
  126. the palette number is not a 4 bit number, so obviously, you can only choose
  127. between 8 of the 16 palettes....if you set these bits to all 0, you will be
  128. selecting the eigth palette (palette 7), if you set them to "001" it is the
  129. ninth palette etc...it was trial and error, and some <serious> frustration
  130. before i figured this one out :)
  131. to set these bytes in the OAM table, you must first setup the OAM "address"
  132. on the 16 bit register $2102 (and $2103). again this is not a real address,
  133. you use the 7 lowest bits of this address to select which sprite you
  134. would like to set the data for (sprite 0 to sprite 127)
  135. then you can write the four bytes discussed above to the register $2104, its
  136. like the color register, auto incrementing...
  137. so....what are all the other bits for??? (the remaining 9) well, i know about
  138. only two others, the highest bit (bit 15) is a sprite priority bit, it is
  139. basically the bit you set to "turn on" the sprite, and keep it being redrawn
  140. on the screen...its a little more than this, but thats all i know about its
  141. behavior. so when you setup your table, (and periodically throughout the
  142. sprites' display lifecycle) you must set this bit high....(for any sprite being
  143. displayed)
  144. there is another small table (32 bytes) that you must load into the OAM, these
  145. consist of two bits for every sprite, one of the bits being the 9th horizontal
  146. position bit, and the other is the size select bit (remember we can pick from
  147. two different size sprites on the screen at once) the first bit is the
  148. most significant horizontal location, and the second is the size toggle
  149. bit...
  150. to write this table the OAM, you must set the 9th bit of the "address" in $2103
  151. to one....then write the bytes, again it is an auto incrementing register
  152. make sure that you have enabled the sprites to be on a particular plane (see
  153. the yoshi doc, on $212C....and make sure that you have set your palette
  154. correctly (remember sprite palette 0 is the 8th palette!!!)
  155. good luck....