123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201 |
- SPRITE DOC
- ------------------------------------------------------------
- if you haven't already obtained "yoshi doc", get it and read it before you
- read this doc....
- Part I - the bitplane representation of a 16 color 8x8 pixel tile
- -----------------------------------------------------------------
- sprites are made of tiles, in particular 4-bitplane tiles, 4-bitplane
- tiles, means that the tiles are made of 4-bit color values, so this means
- that the tiles can have a maximum of 16 colors.
- in many graphics formats, this type of data would be stored as follows
- (assuming a 8 pixel by 8 pixel tile)
- $1 $0 $2 $8 $2 $4 $5
- $2 $0 $6 $1 $f $e $1
- $a $2 $2 $2 $6 $7 $0
- $1 $0 $2 $8 $2 $4 $5
- $1 $0 $2 $8 $2 $4 $5
- $1 $0 $2 $8 $2 $4 $5
- $1 $0 $2 $8 $2 $4 $5
- $1 $0 $2 $8 $2 $4 $5
- where each hex number represents a color, so pixel (0,0) would be color
- number "1", and pixel (4,2) would be color "6"....this is <not> the case
- on the super nintendo....for reasons having to do with the implementation
- of the graphics engine, the super nintendo represents its image data in
- the "bitplane" format, assuming and 8 pixel by 8 pixel tile with 16
- colors, this data would have four bitplanes (0-3) of monochrome, binary
- image data:
- 0 0 0 0 0 0 0 0
- 0 0 0 0 0 0 0 0 1
- 0 0 0 0 0 0 0 0 1 2
- 0 0 0 0 0 0 0 0 1 2 3
- 0 0 0 0 0 0 0 0 1 2 3
- 0 0 0 0 0 0 0 0 1 2 3
- 0 0 0 0 0 0 0 0 1 2 3
- 0 0 0 0 0 0 0 0 1 2 3
- 1 1 1 1 1 1 1 1 2 3
- 2 2 2 2 2 2 2 2 3
- 3 3 3 3 3 3 3 3
- four monochrome 8x8 pixel images stacked on top of each other. if you
- wanted pixel (4,2) to have the color "6" you would have to put a "1" in
- bitplane one, and a "1" in bitplane two, with the bitplane zero and three
- having "0"'s. this is because the binary representation of "6" is "0110".
- ok, so it is obviously possible to store each monochrome bitplane in 8
- bytes, each byte representing a row in the bitplane. so a single tile
- takes up 32 bytes (8 bytes per row * 8 rows * 4 bitplanes) of memory.
- Part II - the way tiles are stored in vram for sprite data
- ---------------------------------------------------------
- in vram you store a tile 16 bits at a time as follows:
- <-------2 bytes at a time------>
- <--1 byte wide-><--1 byte wide->
- [plane 0, row 0][plane 1, row 0]
- [plane 0, row 1][plane 1, row 1]
- [plane 0, row 2][plane 1, row 2]
- ..
- ..
- ..
- [plane 0, row 7][plane 1, row 7]
- [plane 2, row 0][plane 2, row 0]
- [plane 2, row 1][plane 2, row 1]
- [plane 2, row 2][plane 2, row 2]
- ..
- ..
- ..
- [plane 2, row 7][plane 2, row 7]
- the super nintendo can have two different sizes of sprite on the screen
- at one time, you can choose from the following combinations:
-
- [value] [sprite size 0][sprite size 1]
- 000 8x8 pixel 16x16 pixel
- 001 8x8 pixel 32x32 pixel
- 010 8x8 pixel 64x64 pixel
- 011 16x16 pixel 32x32 pixel
- 100 16x16 pixel 64x64 pixel
- 101 32x32 pixel 64x64 pixel
- it is set in the upper three bits of address $2101....so to use 8x8 pixel
- sprites, and 32x32 pixel sprites, you would load $2101 with the value
- "001xxxxx" (where x is don't care)
- the lower five bits of address $2101 are also very important, these bits
- tell the super nintendo where in vram your sprites are located. the
- lowest three bits are the "name base", and the fourth and fifth bits are the
- "name". the "name" bits specify the upper 4k word of the sprite address,
- and the "name base" specfies the offset. so if put you tile data in vram
- $0000 you would set these bits all to zero.
- suppose you want to have four 32 pixel by 32 pixel sprites; each would be
- composed of 16 tiles, each tile is numbered, tiles $0-$3f
- [sprite 0]
- 0 1 2 3
- 4 5 6 7
- 8 9 a b
- c d e f
-
- ..
- ..
- [sprite 3]
- 30 31 32 33
- 34 35 36 37
- 38 39 3a 3b
- 3c 3d 3e 3f
-
- in vram, these tiles, $0 through tile $3f would be store in an interlaced
- fashion as follows:
- $0 $1 $2 $3 $10 $11 $12 $13 $20 $21 $22 $23 $30 $31 $32 $33
- $4 $5 $6 $7 $14 $15 $16 $17 $24 $25 $26 $27 $34 $35 $36 $37
- do you see the pattern? you must store the first row (four tiles) of each
- sprite, and then the second row, then the third, etc....
- if you were dealing with 8x8 sprites, you would have to store the first
- row of 16 sprites, then the second row of the 16 sprites, etc....
- if you were dealing with 16x16 sprites, you have to store the first row
- of 8 sprites, then the second, then the third, etc...
- with 64x64, yep, you guessed it, the first row of two sprites, then the
- second row, etc....
- Part III - setting up the OAM table for your sprites
- -----------------------------------------------------
- for each sprite in the sprite table (maximum of 128 sprites, numbered 0-127)
- you must have four bytes of information, the first byte is the low 8 bits of
- the horizontal position of the sprite, the second byte is the vertical
- position of the sprite, the third byte is the "address" of the sprite...
- it is not the actual vram address, it is the tile number, that is to say,
- the physical vram address of the sprite can be obtained by the following:
- multiply the sprite "address" by 32 (because each tile is 32 bytes) and add it
- to the starting vram address that you set in the $2101 register.
- this tile number points to the first tile in the sprite...the snes expects the
- rest of tiles to follow in the order described in the previous section...
- the next byte containes the 9th bit of the tile "address" and a few attributes
- bit 0 = 9th bit
- bit 1-3 = palette number
- bit 4,5 = playfield priority
- bit 6 = horizontal flip
- bit 7 = horizonal flip
- the palette number is not a 4 bit number, so obviously, you can only choose
- between 8 of the 16 palettes....if you set these bits to all 0, you will be
- selecting the eigth palette (palette 7), if you set them to "001" it is the
- ninth palette etc...it was trial and error, and some <serious> frustration
- before i figured this one out :)
- to set these bytes in the OAM table, you must first setup the OAM "address"
- on the 16 bit register $2102 (and $2103). again this is not a real address,
- you use the 7 lowest bits of this address to select which sprite you
- would like to set the data for (sprite 0 to sprite 127)
- then you can write the four bytes discussed above to the register $2104, its
- like the color register, auto incrementing...
- so....what are all the other bits for??? (the remaining 9) well, i know about
- only two others, the highest bit (bit 15) is a sprite priority bit, it is
- basically the bit you set to "turn on" the sprite, and keep it being redrawn
- on the screen...its a little more than this, but thats all i know about its
- behavior. so when you setup your table, (and periodically throughout the
- sprites' display lifecycle) you must set this bit high....(for any sprite being
- displayed)
- there is another small table (32 bytes) that you must load into the OAM, these
- consist of two bits for every sprite, one of the bits being the 9th horizontal
- position bit, and the other is the size select bit (remember we can pick from
- two different size sprites on the screen at once) the first bit is the
- most significant horizontal location, and the second is the size toggle
- bit...
- to write this table the OAM, you must set the 9th bit of the "address" in $2103
- to one....then write the bytes, again it is an auto incrementing register
- make sure that you have enabled the sprites to be on a particular plane (see
- the yoshi doc, on $212C....and make sure that you have set your palette
- correctly (remember sprite palette 0 is the 8th palette!!!)
- good luck....
|